Author: Adam Back 2016-02-06 17:01:49
Published on: 2016-02-06T17:01:49+00:00
In this email thread, Gavin Andresen discusses various aspects of the proposed hard fork to increase block size in the Bitcoin network. One concern raised is the need for a security considerations section, as well as a list of which exchange, library, wallet, pool, stats server, hardware have been tested against the change. Another issue discussed is the need for a rollback plan in case the hard fork triggers false voting or some other unforeseen issue arises. Monitoring and managing security through the hard fork is also discussed. Responding to claims that 28 days is not long enough for individuals to download and restart their bitcoind or patch and re-run it, Andresen argues that there is no evidence to support this claim. He surveyed several infrastructure providers and the btcd lead developer, all of whom agreed that 28 days is plenty of time. Andresen believes that there are a significant percentage of un-maintained full nodes, losing those nodes would not be a problem for three reasons: 1) The network could shrink by 60% and still have plenty of open connection slots; 2) People are committing to spinning up thousands of supports-2mb-nodes during the grace period; 3) Waiting a year would only pick up an additional 10-20%. Andresen also responds to Luke Dashjr's message, renaming the BIP's Rationale section and expanding it slightly. He explains that accurate/dynamic counting/limiting is quick, simple, and completely safe. Making scripts commit to a total accurate sigop count is seen as a bad idea, as it would make multisignature signing more complicated. Andresen notes that the amount of data hashed to compute signature hashes is limited to 1,300,000,000 bytes per block, which is slightly more hashing than was required to validate block number 364,422. Regarding miners and the economy's support for the hard fork, Andresen believes that "the economy" does support it. He is happy to add words about economic majority and suggests rephrasing the version bits to trigger the hard fork such that miners should only enable the bit when they have independently confirmed economic support. Finally, Andresen discusses SPV wallets, noting that they are compatible with this change. However, Dashjr prefers if this is corrected to "Light clients" or something, as actual SPV wallets do not exist at this time and would not be compatible with a hard fork. Dashjr also suggests that any hard fork should address simple tasks on the hard fork wishlist and be deployed as a soft-hardfork so as not to leave old nodes entirely insecure.
Updated on: 2023-06-11T03:41:03.587454+00:00