Published on: 2015-08-29T21:21:05+00:00
A discussion thread on GitHub regarding a draft BIP (Bitcoin Improvement Proposal) has been moved to the mailing list due to GitHub not being specified for high-level discussions in BIP001. The original poster raises concerns about the structure and wording of the proposal, suggesting it be slimmed down and simplified, with some history lessons removed. The author of the proposal requests more specific suggestions before taking action. There is a question about a separate BIP for "code forks," clarified as beyond the scope of this BIP. It is noted that spell checking has not been followed for any BIP. The current label of the proposal is "informational | process" but may change based on appropriateness. The proposal contains code for an uncontroversial hard fork example to set a precedent. However, a proposal for a "patch into core as a module that hard forks can use in the future" requires further clarification.On July 31, 2015, Thomas Kerin via bitcoin-dev expresses the belief that a document should exist prior to assigning a BIP number. While there was an initial document, alterations were made after the BIP number was assigned. The author apologizes for breaking the previous link and provides a new one. The code is also available on Github. A separate mailing list discussion is ongoing regarding activation thresholds related to this BIP. The assumption of the BIP is that miners will upgrade after a defined starting block height, and once a 95% threshold is reached, the hard fork takes effect. After the first block is buried, the check can be replaced by redefining the threshold height instead of the height when miners started voting.Jorge Timón requests a BIP number from Greg Maxwell on the bitcoin-dev mailing list for discussions about deploying uncontroversial hard forks in one place. The proposed timewarp fix could be coded as a soft fork instead of a hard fork, requiring all blocks to be within one day of the median of the previous 11 blocks. Tier Nolan suggests this would protect against the exploit. Another proposal suggests that the two blocks in question should have the same timestamp, forcing the off by 1 and correct value to give the same result. Nolan believes a hard fork is necessary to fix the issue "right," especially for demonstrating a non-controversial hard fork.Discussions revolve around obtaining miner confirmation on uncontroversial hard forks and whether to use nHeight, nMedianTime, or just nTime. A BIP number is requested to concentrate discussions on deploying uncontroversial hard forks in one place. One proposal for a timewarp fix suggests all blocks should be within 1 day of the median of the previous 11 blocks, adding a condition at the other end. Another proposal suggests the two blocks in question should have the same timestamp, forcing the off by 1 and correct value to give the same result. Fixing the issue "right" would likely require a hard fork, particularly for demonstrating a non-controversial hard fork.In an email conversation, Jorge Timón suggests a soft fork solution to the timewarp exploit, proposing that all blocks should be within one day of the median of the previous 11 blocks, with a condition added at the other end. While not a total fix, it would protect against the exploit. A stricter soft fork would require the two blocks in question to have the same timestamp, ensuring the off by 1 and correct value yield the same result. Timón believes a hard fork is necessary to fix the issue "right," especially when demonstrating a non-controversial hard fork.Tier Nolan suggests fixing the "off by 1 bug" through a soft fork in an email thread on June 21, 2015. This suggestion is made in the context of demonstrating how a non-controversial hard fork works. The timewarp fix discussed in the thread could potentially be coded as a soft fork instead of a hard fork. However, it is unclear if there were any other candidates for addressing the issue.There is a discussion about an off by 1 bug and its potential fix through a soft fork. The focus is primarily on demonstrating how a non-controversial hard fork operates, with the bug solution being of lesser importance.The author seeks feedback to create an informational BIP on deploying hard forks. It is specified that the discussion only pertains to hard forks and soft forks in an abstract manner, excluding block size issues. Block size changes are used as examples due to lack of alternatives, but non-blocksize-related examples for the same cases are welcomed. The author encourages suggestions and input on terminology. The full text can be found on the author's Github page at https://github.com/jtimon/bips/blob/bip-forks/bip-forks.org.
Updated on: 2023-08-01T13:27:52.323460+00:00