Gavin Andresen

Bitcoin developer. All-around geek.

Page 3


When the block reward goes away…

Discussions of raising the maximum block size often turn into discussions of Bitcoin’s very-long-term future – “but what about when the block reward goes to zero” or “but how, exactly, will it all work if Bitcoin is used by billions of people per day…”

I’m going to upset a lot of engineers, but I think it is a mistake to try to predict what is going to happen that far in the future, and an even bigger mistake to spend a lot of time now worrying about what might happen ten or twenty years from now.

I’m inspired by F.A. Hayek’s “The Fatal Conceit”:

The curious task of economics is to demonstrate to men how little they really know about what they imagine they can design.

To the naive mind that can conceive of order only as the product of deliberate arrangement, it may seem absurd that in complex conditions order, and adaptation to the unknown, can be achieved more effectively by...

Continue reading →


Analysis Paralysis

I’ve been accused of being too flippant about increasing the block size limit. This series of blog posts is meant to show that I’m not, that I have carefully thought about risks and benefits. I stepped back from the role of lead committer exactly so I would have the time to think about bigger-picture issues like this one. Today I’d like to address, head-on, this argument against changing the one-megabyte blocksize limit:

Larger-than-one-megabyte blocks have had insufficient testing and/or insufficient research into economic implications and/or insufficient security review of the risks versus benefits.

This is tough to respond to– there can always be more testing or research, especially for a security-critical project like Bitcoin. It is easy to suffer from “analysis paralysis,” and I think the Core Bitcoin project has been suffering from analysis paralysis over the block size issue for...

Continue reading →


Are bigger blocks better for bigger miners?

After taking a break to help review some pull requests and take a trip to New York, I’m ready to continue tackling objections to increasing the block size:

Bigger blocks give bigger miners an economic advantage

This is a hard blog post to write; the arguments for why bigger blocks give bigger miners an economic advantage over smaller miners are highly technical (whenever I use the term “miner” in this post I really mean “solo miner or mining pool”).

To start: think about what happens when a miner gets lucky and finds a new block. They send it to their peers and immediately start working on finding another block on top of that new block.

Their peers will receive and validate the block, and, assuming validation passes, they then relay the block to their peers and start mining on top of the new block. The original miner is busy working during this whole validate-then-relay process; they...

Continue reading →


UTXO uh-oh…

I’m adding entries to my list of objections to raising the maximum block size as I run across them in discussions on reddit, in IRC, etc.

This is the technical objection that I’m most worried about:

More transactions means more memory for the UTXO database

I wasn’t worried about it yesterday, because I hadn’t looked at the trends. I am worried about it today.

But let me back up and explain briefly what the UTXO database is. UTXO is geek-speak for “unspent transaction output.” Unspent transaction outputs are important because fully validating nodes use them to figure out whether or not transactions are valid– all inputs to a transaction must be in the UTXO database for it to be valid. If an input is not in the UTXO database, then either the transaction is trying to double-spend some bitcoins that were already spent or the transaction is trying to spend bitcoins that don’t exist.

...

Continue reading →


The myth of “not full” blocks

I’m going to take a break from addressing objections to raising the maximum block size because in discussions I’m seeing people claim that “blocks aren’t full” or “we don’t yet have a functioning fee market.”

It is true that not every single block is one-megabyte big. But it is not entirely true that “blocks aren’t full” – many blocks are full, either because miners are deciding to create blocks smaller than one megabyte or because sometimes it takes a long time to find a block. Here is a graph I created (from Jameson Lopp’s excellent statoshi.info website) showing the memory pool– transactions waiting to be confirmed– over time:
Mempool.png

Every peak on that graph corresponds to a block being found, and you can see that many blocks don’t clear out the memory pool.

The biggest triangle on that graph, near the beginning, has a peak of about 4,500 transactions waiting to be confirmed. Near the...

Continue reading →


Big blocks and Tor

I think I first heard this objection to a larger maximum block size from Peter Todd, Chief Scientist of ViaCoin:

More transactions makes it more difficult to keep Bitcoin activity private from oppressive governments.

That is hard to argue with– obviously the more you do something, the more likely you will get noticed. But engineering is about tradeoffs, so how much more likely is somebody to get noticed by their oppressive government if they are using a Bitcoin system that supports sixty, rather than three, transactions per second?

Well, if they are just transacting with Bitcoin using a lightweight wallet, there is no difference. Lightweight wallets (meaning any wallet except for Bitcoin Core or Armory) only download transactions relevant to them. They are unaffected by changes to the maximum block size.

But what if you want to be a miner in some oppressive country?

Well, if you...

Continue reading →


Will a 20MB max increase centralization?

Continuing with objections to raising the maximum block size:

More transactions means more bandwidth and CPU and storage cost, and more cost means increased centralization because fewer people will be able to afford that cost.

I can’t argue with the first part of that statement– more transactions will mean more validation cost. But how much? Is it significant enough to worry about?

I’ll use ChunkHost’s current pricing to do some back-of-the-envelope calculations. I’m not affiliated with ChunkHost– I’m using them for this example because they accept Bitcoin and I’ve been a happy customer of theirs for a while now (I spun up some ‘chunks’ to run some 20 megabyte block tests earlier this year).

CPU and storage are cheap these days; one moderately fast CPU can easily keep up with 20 megabytes worth of transactions every ten minutes.

Twenty megabytes downloaded plus twenty megabytes...

Continue reading →


Block size and miner fees… again

I’m still seeing variations on this argument for keeping the one-megabyte block limit:

The network will be more secure with one megabyte blocks, because there will be more competition among transactions, and, therefore, higher transaction fees for miners.

I’ve written before about the economics of the block size (and even went to the trouble of having Real™ Economists review it), but I’ll come at that argument from a different angle.

Miner rewards expressed in BTC are:

block reward + ( number of transactions x average fee )

In the currencies that most miners care about right now (dollars or euros or yuan) rewards are:

(reward + number transactions x average_fee) x exchange rate

The fear is that as the block reward diminishes, either the number of transactions or the average transaction fee will not rise enough to replace the block reward. So miners will drop out, and the network...

Continue reading →


It must be done… but is not a panacea

There are two related arguments I hear against raising the maximum block size:

There is no need to raise the maximum block size because the Lightning Network / Sidechains / Impulse / Factom solves the scaling problem.

If the maximum block size is raised, there will be little incentive for other scaling solutions to emerge

The first is easy to address: if any of the other proposed scaling solutions were tested, practical and already rolling out onto the network and being supported by all the various Bitcoin wallets then, indeed, there would be no hurry to schedule a maximum block size increase.

Unfortunately, they’re not; read Mike Hearn’s blog post for details. We are years away from a time when we can confidently tell a wallet developer “use this solution to give your users very-high-volume, very-low-cost, very-low-minimum-payment instant transactions.”

The second is also easy to...

Continue reading →


Why increasing the max block size is urgent

Perhaps the most common objection I hear to raising the maximum block size from one megabyte is that “blocks aren’t full yet, so we don’t have to do anything (yet).”

It is true that we’re not yet at the hard-coded one megabyte block size limit; on average, blocks are 30-40% full today.

There is a very good blog post by David Hudson at hashingit.com analyzing what will happen on the network as we approach 100% full blocks. Please visit that link for full details, but basically he points out there is a mismatch between when transactions are created and when blocks are found– and that mismatch means very bad things start to happen on the network as the one megabyte limit is reached.

Transactions are created steadily over time, as people spend their bitcoin. There are daily and weekly cycles in transaction volume, but over any ten-minute period the number of transactions will be roughly...

Continue reading →