In my last development update, I reported slow but steady progress on core development.
Then just three days later, a “perfect storm” of events caused a block chain split (see the post-mortem write-up for details), and switched our focus for a few weeks from steady progress to moving quickly to identify and fix the problem, then figuring out what we can to do make it less likely a similar problem will happen in the future.
It would be nice to say “make sure it will never happen again,” and I am confident that the particular set of bugs and circumstances that caused the March 11′th chain fork will never happen again; but another set of bugs and circumstances could cause another chain fork in the future. There is still some work to be done to minimize the consequences of any future chain forks (again, see the post-mortem for details).
Diversity is a good thing. Diverse, inter-operating implementations of the Bitcoin protocol make the network more robust against software bugs, denial-of-service attacks, and vulnerabilities. There are several projects re-implementing Bitcoin; if you are a Java or Go or Python or C programmer who wants to see Bitcoin succeed, you should consider helping them out by reviewing, testing, or contributing patches:
I apologize in advance if I forgot, or don’t know about, your favorite Bitcoin implementation.
There will likely be a 0.8.3 release of the reference implementation to fix a denial-of-service attack that affects some network nodes (details will be released after the fix), but most development effort is working towards a 0.9 release. We have over sixty pull requests waiting for review and testing and merging, with changes large and small, so a lot of effort is going into processing that backlog of work. Too many pull requests is a good problem to have.
On top of all that is a long list of new features and improvements I’d like to see get into a 0.9 release; the highest priorities on my wish list are:
- “First double-spend” relay and detection. Detecting attempted double-spends as soon as possible is great for low-value, in-person transactions, and we should do more to support that use case.
- Smarter fee estimation in the client. The fees you pay should be based on the median fees being paid on the network around the time you send the transaction.
- Payment Protocol support in Bitcoin-Qt.
- Wallet redesign / reimplementation. This is a big, incredibly sensitive area of the code, and might be too much to bite off for the 0.9 release. But I would really like to move to “hierarchical deterministic” wallets that are not stored in a Berkeley DB database and are much easier to back up and are designed with some built-in redundancy so they can survive a corrupt sector on your hard disk.
San Jose, Washington DC, and Australia
The Bitcoin 2013 conference in San Jose was a great opportunity for developers to get together, talk tech, and get to know each other better socially. I suspect some of the 60+ waiting pull requests are from conference attendees who were inspired to contribute to the project for the first time.
I also spent a couple of days in Washington, DC, educating policymakers about Bitcoin and trying to dispel some common myths (like “Bitcoin is completely anonymous”). If you are a member, you’ll find a thread about it in the Foundation forums; if you’re not a Foundation member, you should join.
I will be writing the next development update from Australia; my family will be living in Far North Queensland for six months. I expect to get a lot of code written while I’m there, because I’ll get fewer interruptions since Australians are awake when most of the rest of the English-speaking world is asleep.