Summary: Reducing the block size and block weight limits in Bitcoin
Recently, there has been a lot of controversy happening on Twitter regarding the current block size and block weight limits in Bitcoin. The main source of this controversy is from iconic Bitcoin core developer Luke-Jr. The discussion is essentially about decentralization in relation to:
- Initial Block Download (IBD): This is the initial synchronization that peers use to download and validate the blockchain from peers. Users download all blocks and validate all of the transactions & UTXOs in them. Users running full nodes have full sovereignty as they not only have the entire history, but also can use that history to empower themselves to run the consensus rules that conform to both that history and to the network. They can thus preserve their wealth no matter what in a trustless manner.
- Bandwidth: Users need significant amount of bandwidth to trustlessly download blocks during the IBD as well as maintaining synchronization with the network
- CPU: Users need processing power to perform both the IBD validation as well as maintain synchronization and process the transactions and blocks in a reasonable amount of time. On small devices, the CPU power required to validate the blocks can become a huge bottleneck.
- I/O: Data stored in memory correlating to the amount of read/writes to disk. Largely negligible on most devices but becomes more relevant on very small devices (IoT).
Reasons to reduce the block weight limit:
- Less costs and faster for users to perform the Initial Block Download of a Bitcoin full node and maintain synchronization to the Bitcoin network. Eventually, it will be so cumbersome to download the entire blockchain that users simply won’t do so, and will resort to SPV/Neutrino or trusted third party solutions to interface with the blockchain
- Potentially allow users to run full nodes on mobile phones and low bandwidth and low power devices that have limited bandwidth
- Increase the number of nodes using TOR, where bandwidth is even more limited
- There is already too much block space, so transaction fees might not be high enough in the future due to the Lightning Network if we don’t reduce the block size and force a fee market to form
Reasons NOT to reduce the block weight limit:
- Less controversy: community could focus on getting more users running full nodes through education rather than arguing on Twitter
- Decentralization is better increased by improving the UX for users running Full Nodes such as adding native hardware wallet signing support (PSBT) to the Bitcoin Core client and wallet GUI
- Access to more powerful CPUs and higher bandwidth continues to increase globally
- Full nodes are not that important unless the user is actually using them
- We don’t have enough data to inform the discussion
- There’s less reason to be concerned because companies are now offering Bitcoin full node hardware: @nodl_it @CasaHODL @lightninginabox
@BitseedOrg @SamouraiWallet
Block weight limit reduction proposal:
- Reduce the block weight temporarily. This would be a 3–6 month reduction from the current theoretical block weight limit of 4mb, which is actually about 2.1mb in practice.
- 300kb would mean a theoretical block weight limit of ~1.2mb, resulting in maximum block capacity of about 700kb
- 600kb block size would mean a theoretical block weight limit of ~ 2.4mb, resulting in maximum block capacity of about 1.4mb
What does the current data tell us?
The number of reachable full nodes is up 78.57% in the last 2 years. The fluctuation in full node counts also seems to correlate with bull markets and bear markets as we see a peak around Nov 1st 2017 sustained through spring of 2018. By November 2019, it seems that node counts start to grow again slowly, perhaps correlating with increased number of people buying full nodes from hardware providers.
Don’t believe me? See for yourself: https://bitnodes.earn.com/dashboard/?days=730
My current opinion is that the people advocating for this change simply don’t have the data to backup their assertions that reducing the block size / weight limit will increase the number of full nodes. I have repeatedly asked for more data but it apparently does not exist.
So, how do we get the data that we need?
I would like to see how various devices and locations are impacted. I feel like there’s a good opportunity to extrapolate some data out and visualize it in a way that communicates the total costs across a few different scenarios (mobile phone, vs. laptop wifi vs. hi-end desktop)
Please let me know if I missed anything, or if there is something that needs correction.
