Bitcoin 2014 // 15-17 May // Amsterdam Register


Core Development Update #3

Gavin Andresen    Mar 08 2013

Steady Progress

Looking back on what has happened since my last update, the big news was the 0.8 release. If you are using bitcoind or Bitcoin-Qt and you haven’t upgraded yet, you should: the new release is much faster and is more gentle on your disk drives. You can get it from SourceForge.

Steady progress is also being made on a project that, I’m happy to say, I had very little to do with: redesigning the website. Foundation member Saivann Carignan decided that he didn’t like the current homepage, but instead of doing what most people do (complain about it and ask when somebody else will fix it), he took a leap of faith and redesigned it himself. He has also been doing the hard work of getting rough consensus on what the design and content should be, starting with a very civilized conversation in the Foundation forums.

If you see some piece of common Bitcoin infrastructure that needs to be created or fixed, I hope you’ll feel inspired by Saivann and work to make it happen.

Scaling Up

Looking forward, scaling up to handle increased transaction traffic on the network is very high on the development priority list. Scaling up is painful, but I always remind other developers that scaling up problems are the best kind of problem– they mean people want to use your product.

This week transaction volume reached the voluntary, easy-to-change, 250,000 bytes-per-block limit — and that caused some pain for people. I got a few emails from people concerned that their transactions weren’t confirming after an hour or three, so I sent this email to a dozen or so of the big mining pool operators:

I’m writing to remind you of the bitcoin.conf settings that control
the size of blocks created, and the transaction fee policies. I’m not
going to recommend any particular settings– I really think we need to
move beyond centralized decision making.

blockmaxsize=<n>      Set maximum block size in bytes (default: 250000)
blockprioritysize=<n>  Set maximum size of high-priority/low-fee
transactions in bytes (default: 27000)
blockminsize=<n>       Set minimum block size in bytes (default: 0)

Related: I did some back-of-the-envelope, order-of-magnitude
calculations on orphan rates and block sizes:

My conclusion is that creating larger blocks with transactions that
follow the current default fee rules is the smart thing to do; I
estimate you’ll earn more in fees than you will lose in a (very
slightly) higher orphan rate.

And if you think that accepting more zero-fee transactions will help
Bitcoin long-term, I estimate that 100K of free transactions costs you
something like $1 for every block found.

At least a couple of the big pools have decided to increase the size of the blocks they create, but I suspect that hitting the “soft” limit will make some services using the block-chain start to increase the fees they pay. People creating lots of small-value transactions are affected most. To them, I’ll just say that scaling problems are good problems to have, and if you think something needs fixing then “I hope you’ll feel inspired by Saivann and will work to make it happen.”

One Megabyte

There is a non-voluntary, hard-to-change, 1,000,000-bytes-of-transactions-per-block limit that needs to be raised.

And there is… uhh, “vigorous”… debate over when and how to change it. There are always debates over changing things; after the huge kerfuffle last year over multisignature transactions I had to step back and take a break when it was all over, I was so burned out from trying to respond to all the fear, uncertainty, and doubt.

I think a consensus on what to do is starting to emerge; I expect by my next development update we’ll have a plan.

The good news is we all learned a lot from that experience, so I’m confident that raising the 1MB limit will be only slightly painful for most people– you’ll just have to upgrade old Bitcoin software (which you should be doing regularly anyway).