Protocol documentation - Bitcoin Wiki
5 stars based on
65 reviews
It's well described how Bitcoin has a one Megabyte block limit; it's defined in the Bitcoin Core source code. Turns out bitcoin 80 bytes in a megabyte I was wrong; in practice this limit is actually quite a lot smaller! Back in " Bitcoin Traffic Bulletin " we saw how first transaction confirmation times were highly dependent on how full mined blocks were.
Bitcoin 80 bytes in a megabyte was a slight puzzle for me; the older data seemed more erratic than I'd have expected, but at the time I'd presumed that this was down to changes in hashing rates and that the older versions of the network had had longer latencies and more jittery propagation.
A couple of days ago, however, I spotted something very odd while watching a series of blocks block heights to ; they were all the same size kbytesbut that size wasn't anywhere near 1 Mbyte. The kbytes size seemed bitcoin 80 bytes in a megabyte weird too, until I realized that this was a classic computer science numerology problem.
The Bitcoin block size limit is 1, 1M bytes, but typically memory sizings aren't done in powers of 10, but instead in powers of 2, so 1 Mbyte of memory is actually bytes. For anyone old enough to remember PC floppy drives I leave you to actually work out the capacity of a 1.
Given this puzzle I generated some new data. It looks at the theoretical block usage vs the mean first confirmation time. Let's look at it:. Correlation and causation are two different things but, even so, this is pretty surprising! If our actual maximum block size limit was actually somewhat less than 1M bytes, though, the estimate block usage numbers would be incorrect and would need to be scaled up!
Why would k bytes be being used instead of 1M bytes? If one or more miner was systematically generating smaller blocks than the theoretical maximum then that would definitely affect all of my earlier bitcoin 80 bytes in a megabyte on block utilization, mean confirmation times and block scarcity for mining fees.
A little digging around in the Bitcoin Core git repository turns out to be very useful! The Bitcoin protocol implements a hard consensus limit of 1M bytes on blocks, but actually has a default size for miners that is actually smaller than this. Individual transaction selectors generally mining pool operators can set the value to anything up to 1M bytes, but there are some defaults.
A little more investigation also showed that v0. If we were mining, why might we want to use smaller block sizes? Well, if we need to announce bitcoin 80 bytes in a megabyte mined block to the network it takes time.
If our miner had a DSL line with only a 1 Mbps uplink then by the time we've added network protocol overheads then this block will take about 20 seconds to transmit! That's a very long time, especially in situations where two blocks are found at almost the same time.
If the block had been 1M bytes then it would have taken 80 seconds! In practice large mining pools will have much faster network connections than this now, but network bandwidth still plays an effect. Back to our original problem, however! The problem with miners selecting a smaller maximum block size is that if the network is heavily loaded then our miner is bitcoin 80 bytes in a megabyte leaving transactions waiting when they declare a block "full" at some level below 1M bytes.
Far from the 3. With good historical data we can estimate the actual block size limit for various miners. If we look at the largest block mined by specific pools in given weeks we can estimate the upper limits that they were actually using. If we multiply these by the fractions of the numbers of blocks each found then we can estimate the actual block size capacity of the network over time:.
This isn't a perfect approach. Smaller pools will see their results skewed because they don't find enough blocks, but the effect is interesting. Over the last two years the effective block size has steadily been growing, and if anything has, until a few months ago, slightly outpaced the growth in actual block usage. The raw data is also a source of some interesting discoveries. Individual pool operators sometimes try to optimize things in interesting and quite different ways.
Here are some examples for some of the larger pools:. This is quite striking, bitcoin 80 bytes in a megabyte more so if we realize that in late and early we were seeing huge hash rate expansions which in turn reduce the confirmation times as blocks were being found much more quickly than one per 10 minutes. The implications of these results are intriguing.
We can certainly see that the current network can't actually handle even the modest transaction rates we originally assumed, although it's easy for mining pool operators to adjust for this. That this is up to the majority of mining pool operators is potentially the most interesting realization.
In practice, bitcoin 80 bytes in a megabyte a risk seems unlikely as that would damage the very ecosystem that supports mining. A subtlety, however, is that GHash were only actually allowing k bytes per transaction. The jump when they switched to k byte transactions is actually quite marked in the second chart! The confirmation time statistics suggest that even if, midthey had tried to use relative scarcity to select higher fee transactions bitcoin 80 bytes in a megabyte probably would have had little impact.
The next large pool, if in a position to dictate block scarcity, has the potential to be much more disruptive as a result of transaction selection.
There is also an interesting implication for Gavin Andresen's proposed protocol fork that would allow larger blocks. If the majority of mining pools by total capacity choose to ignore some new upper limit then the effect will be to retain a much smaller overall cap. Miners may, indeed, want to do exactly this as block scarcity is the only thing that has any reasonable prospect of helping them achieve higher transaction fees.
For observers of the Bitcoin network we do seem to have a new health indicator: A periodic report on the mean, minimum and maximum block sizes mined by various pools and their associated statistical likelihoods could be very interesting. After I spotted the trends that led me to speculate about block size limits he generated the raw data that I needed to perform my analysis. The source code, and the source CSV data files can be found on github:
