Author: Alphonse Pace 2017-03-28 17:53:11
Published on: 2017-03-28T17:53:11+00:00
In an email conversation among members of the Bitcoin development community, Juan Garavaglia expressed his opinion that if a 1MB block size limit was sufficient in 2010, an 8MB limit is adequate in 2016 and a 32MB limit may be valid after the next halving. He acknowledges that the topic of whether it is safe or even possible to raise the block size limit is separate. Alphonse Pace responded to Wang Chun's hard fork proposal from a previous meeting, asking for clarification about the participants and purpose of the meeting. Alphonse also argued against an unbound block size limit, stating that it could lead to differing consensus if alternative layers for relaying are used and could remove many small miners from the network. He suggested waiting until SegWit activates before committing to any additional increases. Wang Chun proposed a hard fork approach to increase the block size limit by removing the 1MB limit and only limiting the block size to 32MiB until spring 2020. This would give third-party services, libraries, wallets, and exchanges enough time to prepare for the scheduled fork. Various proposals for increasing the block size limit would become soft forks with this patch already in Core's release. The developers must code something now before it becomes too late. A paper linked by Juan shows that even a 4MB block size is unsafe, while SegWit provides some safety up to this limit. An 8MB block size is considered unsafe today.
Updated on: 2023-06-11T22:43:38.675259+00:00