Published on: 2013-03-15T19:52:18+00:00
On March 13, 2013, Bitcoin developers engaged in discussions regarding various issues and proposals. Benjamin Lindner expressed his opinion on software behavior not described by the source code, stating that it should not be considered part of the rule set. Cameron Garnham brought up the topic of Bitcoin's block size limit, arguing that it should be removed as it was not described in the source code. The discussion highlighted concerns about technical complications and risks associated with making such changes.There were discussions about client detection and warning in the case of non-trivial forking. Roy Badami suggested implementing a warning system to notify users during forks, which could help address incidents like the bug affecting Bitcoin users using version 0.8. Luke-Jr proposed that end-user clients should warn about such situations when possible, even if they are not always aware of the fork.The issue of assurance to users that their transactions were confirmed was raised. Andy Parkins expressed concern about the failure to provide this assurance, while Luke-Jr proposed changing the definition of "6 confirmations" to account for potential chain failures. The discussions emphasized the need for improved monitoring and warning systems in Bitcoin clients.Matthew Mitchell raised concerns about difficulties in getting people to update their systems from older versions. The development community explained the challenges involved in updating and upgrading Bitcoin software, including the need for integration and testing. The community also emphasized the importance of careful consideration of the risks and benefits when updating or upgrading.Mark Friedenbach proposed solutions to prevent hard forks and ensure consensus. However, there were debates about the definitions of hard forks and how to handle client divergence from consensus. Pieter Wuille pointed out that some proposed solutions still resulted in nodes accepting blocks they previously considered invalid.The urgency to increase the lock count in the blockchain was discussed to avoid potential crises. The proposal included patching pre-0.8 branches and coordinating with miners to remove the patch once widespread adoption was achieved. Luke-Jr also proposed a solution involving block size limits and soft and hard forks at specific block numbers.There were discussions about increasing the block size limit to accommodate transaction volume growth. While some developers, like Luke-Jr, believed a 2 MB increase over the next few years was uncontroversial, others, like Gregory Maxwell, urged caution to avoid controversial changes. Peter Todd noted concerns about the controversy surrounding the issue, including receiving threatening messages from opponents of the block size increase.In a proposal sent by Luke-Jr on March 13th, 2013, he suggested three rules for Bitcoin block sizes. The first rule applied before block 262144 and aimed to make older clients safe under most circumstances. It stated that no block should have over 4500 transaction modifications when combined with the previous four blocks. Additionally, no block should include more than 4500 transaction modifications on its own.The second rule applied between block 262144 and block 393216, which was referred to as hard fork #1. This rule stated that no block should include more than 24391 transaction modifications on its own, which was thought to be equivalent to 1MB. However, this rule could make older client backports safe unless a reorg was more than six blocks deep.The third and final rule applied from block 393216 onward, which was referred to as hard fork #2. This rule stated that no block should include more than 48781 transaction modifications on its own, which was thought to be equivalent to 2MB. Additionally, it allowed blocks up to 2MB in data size. The proposal aimed to discontinue support for clients prior to 0.8.1.Peter Todd replied to the proposal suggesting the need for a separate limit for how much the UTXO set can be grown by each block. He proposed setting the UTXO growth limit fairly low, at 1/4th of the block limit, given the uncertainty around limiting the creation of txouts that cannot be spent economically.In an email conversation, Luke-Jr proposed a hard fork from block 262144 to block 393216, where any block that includes more than 24391 transaction modifications on its own will be rejected. This change would ensure that older client backports remain safe unless there is a reorg deeper than six blocks.Another participant disagreed with the two-stage proposal and suggested choosing a number closer to 4911, which would still be less than what pre-0.8 accepts but need not be small. This participant argued that this approach would halve the complexity of the change by avoiding two hard forks. However, it would involve accepting some risk of "backport" clients getting stuck after large reorgs, which would require manual intervention to resolve.The participant further emphasized the importance of a separate process for the size change once a low-risk/low-controversy hardforking change has been proven.
Updated on: 2023-08-01T04:33:18.326691+00:00