BIP 102 [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2015-07-24T09:43:00+00:00


Summary:

In a discussion on the Bitcoin developer mailing list, developers debated the merits of using block height versus median time for determining maximum block size. Some argued that block height was simpler, while others suggested median time would be more "human-schedule-friendly." The conversation ended with a request to move the discussion to a separate thread regarding an uncontroversial hardfork.Peter Todd criticized Jeff Garzik's proposed 2MB hard fork patch, accusing him of pushing for better solutions with a bad patch. Garzik defended his proposal, stating that 2MB had the most consensus and could provide valuable field data. He also mentioned that the 2MB cap could serve as a fallback option if consensus couldn't be reached on a larger solution.Another discussion focused on the security implications of a supermajority of miners not supporting a proposed block size increase. Peter Todd warned that without miner support, the chain would be insecure and susceptible to attacks. He proposed a solution to prevent reorg by requiring the first block after a predetermined time to be version 0 or larger than 1MB. This approach wouldn't require additional exceptions in consensus rules but might be troublesome in coding.Peter Todd accused Jeff Garzik of proposing a bad patch to motivate others to write better solutions, but others disagreed, suggesting that Garzik may be proposing the change to spur discussion. The discussion focused on whether preventing bad patches from being proposed was beneficial or detrimental to Bitcoin's development.Peter Todd discussed concerns about the allocation of BIP numbers and expressed concerns about allocating them for "stupid ideas" to avoid gatekeeping. The discussion also touched on using block height versus time in the Bitcoin protocol, with some arguing for simplicity and others advocating for predictability through the median time mechanism. BIP102, which proposed a block size limit increase, was criticized for its design and potential risks.Luke Dashjr expressed his opinion that hard forks should require consensus among nodes rather than a majority vote among miners. Another member agreed and suggested that new hard fork proposals using a voting system may not want to establish the precedent of relying on a vote.Jeff Garzik proposed a new Bitcoin Improvement Proposal (BIP) as a backup plan to his preferred proposal (BIP 100). The BIP aimed to provide a minimum viable alternative plan if an agreement couldn't be reached on a more comprehensive solution. Chris Wardell proposed a dynamic solution to increase the block size every 100k blocks (~2 years) as a backup plan, with Ross Nicoll supporting the idea. There was also support for a temporary solution of increasing the block size to 2MB while a permanent solution is sought.In an email conversation, Tier Nolan mentioned that the block and transaction sizes are no longer linked together, allowing for greater flexibility in the Bitcoin network.Overall, there are various discussions and proposals regarding hard forks and block size increases in Bitcoin, aiming to find a solution that allows for organic growth and scalability while considering factors such as privacy, security, centralization, and transaction throughput.


Updated on: 2023-08-01T14:23:51.505430+00:00