Why Silbert’s Segwit + 2Mb HF Compromise for the Scaling Debate is Bitcoin’s Best Shot — A Simulations Approach
The TL;DR of this analysis: The Bitcoin network today with 1Mb blocks has roughly 120 days left before the memory pool will increase infinitely. Compromise at this point is necessary, or we all risk facing the consequences. The difference between Segwit, Segwit+2Mb HF and Bitcoin Unlimited (BU) will be negligible in terms of final blockchain size, and capacity being reached (would take 7 years with Segwit alone, 17 years with Silbert’s compromise); however, Segwit allows off-chain solutions to also be developed simultaneously, making Segwit absolutely superior to BU.
I believe Silbert’s compromise has the greatest chance of reaching consensus, whether or not it is the best technical solution, making it the best plausible solution in my opinion at the moment. I hereby support Silbert’s compromise. If this still does not work, I will also ultimately support a User Activated Soft Fork (UASF) given the urgency of the situation.
Intro
For those who need to be caught up, whenever an individual on the Bitcoin network broadcasts a new transaction, it must be queued in the “memory pool” before it is added to the Blockchain immutably. In the current protocol, a new block of transactions is processed and appended to the Blockchain every 10 minutes, with the maximum allowable size of each block being capped at 1Mb. Around October 2016, the average block size begun to regularly hit this cap, which has resulted in periodic spikes of the memory pool size, transaction delays, and a polarizing debate that has fragmented the community to a degree.
The scaling debate mainly consists of two opposing parties with philosophically different approaches to scaling: those in favor of increasing the maximum allowable block size from 1Mb to unlimited, and those who propose that scaling should be done by implementing a technology called Segwit, which effectively increases the block size to 3.7Mb. Recently, Barry Silbert, a prominent figure in the Bitcoin community, proposed a compromise that Segwit is first implemented, and after 12 months, a hard fork would be performed to double capacity again (effectively making the maximum block size 7.2Mb).
In an effort to provide more objective data for the Bitcoin scaling debate, I have performed a basic simulation in order to analyze the effects that Segwit, BU and Silbert’s compromise may have on the Bitcoin network.
Methodology
SIGMA simulation software was used to develop a basic model. SIGMA is free software, and I have uploaded the completed models to my GitHub for those who want to run the simulation locally.
Essentially the simulation performs the following:
- Transactions are assumed to be 500 bytes in size on average. The initial memory pool is set to 1000. The initial Blockchain size is set to 110Gb.
- Transactions are added to the memory pool at about 173 transactions/minute initially, and increases by 0.000132 transactions/minute². This assumption is based on extrapolating the linear growth that has been observed over the past 2 years:
- Blocks are found using an exponential distribution with a mean of 10 minutes. Blocks are assumed to be at most, 95% full. The effective size of a found block is either the number of transactions in the memory pool, multiplied by 500 bytes, or the current allowable maximum block size, whichever is smaller.
- For the 1Mb simulation, the maximum allowable block size remains at 1Mb perpetually. For Segwit, it is set to 3.7Mb. For BU, it is uncapped. For Silbert’s compromise, after 12 months of simulated time, the maximum block size will increase from 3.7Mb to 7.2Mb.
- To be able to later extract some data for miner revenues, I assume each transaction will have a fee of roughly 0.000273 BTC. Halving of the block reward will occur after 144,000 blocks in the simulation, and every 210,000 blocks afterwards.
Results and Discussion
The key results are provided in the table below. This is based on the simulation running for 20 years.
No matter what, if Segwit is implemented, or BU, the blockchain will be expected to exceed 1Tb after 10 years. There is no large observable difference here. After 20 years, Segwit alone would be ~2Tb while BU and Silbert’s proposal would be ~4.5Tb. I do not view these to be large enough differences to cause contention. We also see that Segwit alone buys us 7.7 years, while Silbert’s proposal buys us 17 years. Once again, I don’t believe this to be a contentious difference.
I may add additional information related to miner revenues later to this analysis, but I do not believe it is pertinent to this discussion. Some have argued that allowing off-chain scaling through Segwit will result in decreased miner revenues since users will opt to perform their transactions off-chain. I disagree and would argue that the primary factor that will affect miner revenues will be Bitcoin price. Ultimately, I think this will be a separate issue that should be addressed in a separate manner when the time comes (several several years from now). No reason to convolute the current situation further.
Silbert’s compromise would effectively allow for up to ~24 tps (assuming 500 byte tx size). Supporting on-chain transactions to the point of 100tps+ is simply not viable in my opinion without a ridiculous increase to the block size. Thus, Segwit and off-chain is our quickest way to scale short-term.
There is much more that can be said on this topic, but I wanted to keep this somewhat short. I’m happy to answer any questions people may have, and sincerely appreciate any criticism of the methodology.
