It’s Time to Take Another Look at the BIP100 Miner-Based Scaling Plan
Once upon a time there was a Bitcoin scaling proposal called BIP100. It appeared in 2015 with a stated goal of taking power away from a few developers and handing it to economic stakeholders (namely miners).
Two years later, the proposal is still very active and presents another option for the Bitcoin community to consider. Bitsonline continues its series looking at various Bitcoin scaling proposals, to help readers form their own educated opinions.
Jeff Garzik first wrote the proposal for Bitcoin Improvement Proposal (BIP) number 100. Garzik continues to maintain the project, along with lead developer Tom Harding and Dagur Valberg.
Speaking to Bitsonline, Harding said: “Events since BIP100 was introduced have made it more attractive than before, so it’s a good time to take another look.”
What’s the Deal With BIP100 Then?
BIP100 is similar to Bitcoin Unlimited’s favored “emergent consensus” technique, and is compatible with it. To explain, that means bitcoin miners can determine and alter transaction block sizes by “voting,” based on free market principles.
For the record, it’s also compatible with SegWit. The developers say if the ecosystem wants both, it can have them simultaneously or in any order.
Under BIP100, miners would vote by adding a string to a block’s coinbase scriptSig, eg: “/BIP100/B8/” to vote for 8MB blocks. Like the difficulty level now, this would be reassessed every 2016 blocks (around two weeks) and adjusted accordingly.
The two-week adjustments would be around 5% higher or lower than previous, and would not require a hard or soft fork to change.
To activate, the proposal requires a 75% miner supermajority to trigger a one-time hard fork.
Seemed Like a Radical Idea at the Time
Calculating block sizes this way is something one can do directly from the blockchain, without guessing or referencing other data sources, said Harding. But when Jeff Garzik first introduced the proposal in 2015, many in Bitcoin weren’t ready to consider it. Harding was actually one of them.
“Miners liked BIP100 because they would collectively determine the max block size (more than 50% of hash power signaled for BIP100 at one point), but others like myself thought it was a non-starter, because miners would surely make blocks too big.”
Then came BIP101 later that year, from Gavin Andresen. That proposal was more radical, increasing the block size to 8MB and growing it algorithmically to 8GB over 20 years. (Yes, you read correctly, that’s gigabytes).
Miners balked at the BIP101 growth curve, Harding continued. They were concerned about block propagation times and orphan risk, and measurements across the great firewall of China validated this concern.
“At the same time, miners would rather see lower fees, not higher. Hence they want bigger blocks. That’s curious because miners are the direct recipients of Bitcoin fees! There are two reasons for this preference. One reason is demand for block space now outstrips supply, and miners expect higher total fees from larger blocks. Another is that miners still benefit from valuable BTC even more than they benefit from fees, so they are keen to grow the ecosystem.”
These are counterbalancing incentives, but miners will always get paid in bitcoin. So BIP100 called on them to “safely evolve” the block size.
Compatible with Core, Unlimited, Even XT
Harding stressed that BIP100 is not an alternative client or an alternative developer team (as Bitcoin Unlimited is). In fact his group has published implementations for three separate clients so far: Bitcoin Core, Bitcoin XT, and Bitcoin Unlimited. These will all inter-operate with each other.
He described 100 as working “like an optional autopilot” that sets the BU emergent consensus parameters depending on the votes in the blockchain. The BU vision is to not lock users into this kind of choice, he added, so it’s a mode that can be turned on and off using a “-bip100” option.
Harding pointed out other improvements to block propagation that are already deployed. Since 2015, there have been at least four: xthin blocks, compact blocks, FIBRE network, and Falcon network.
“Blocks now propagate in less than two seconds — as fast as transactions did three years ago, even though blocks are now 2000 times bigger than transactions!”
BIP100, he said, would permanently resolve the max block size debate with a single hard fork. This would allow Bitcoin to grow to accommodate the technological growth in the six years since the 1MB limit’s establishment.
Harding continued that another scaling proposal, Extension Blocks, lacks the ability to constantly evolve maximum block size in the future. However it would be possible to combine the two proposals if the ecosystem will not deploy a hard fork.
BIP100 is still under active development, with its most recent update in March 2017. There is a website that explains the proposal in detail, and is also ready to track supporting blocks live.
Is the proposal a sensible idea? Could it overcome problems between other rivals? Let us know your thoughts.
Images via Pixabay