Published on: 2015-08-28T15:27:23+00:00
A proposed solution has been suggested to address the problem with minimal changes to the current softfork logic. This solution allows for all features described in sipa's Version bits BIP. The solution involves setting the xVersion equal to nVersion AND 0b10000000000000000000000000011000, and miners supporting BIP65 will set xVersion to 8 or greater. If a sufficient number of blocks have an xVersion greater than or equal to 8, invalid blocks with xVersion 8 or greater will be rejected. Alternatively, if a higher percentage of blocks have an xVersion greater than or equal to 8, all blocks with xVersion will be rejected. However, it was noted that the proposed solution still uses up a version bit unnecessarily, as it rejects blocks with nVersion=0b001...000. Alternative solutions were also discussed, including Peter Todd's stateless nVersion bits w/ time-expiration proposal and the implementation of the original stateful nVersion bits proposal. The former only leads to a hard-fork if a soft-fork is rejected by the deadline, while the latter carries higher risk due to the complexity of tracking soft-fork state.Btc Drak has made updates to BIP 113 and credited Gregory Maxwell. He also made changes to BIPS 112 and 113 to reflect the amended deployment strategy. There is a discussion about the issue caused by Bitcoin XT, which produces blocks with nVersion=0b001...111. One suggestion is to apply a mask and trigger the soft-fork on nVersion >= 0b0...100 == 4, with miners producing blocks with nVersion=0b0...1000. However, this approach still uses up a version bit and rejects blocks with nVersion=0b001...000, resulting in a hard-fork. Another proposal is Peter Todd's stateless nVersion bits w/ time-expiration, which only leads to a hard-fork if a soft-fork is rejected by the deadline. Another alternative is to implement the original stateful nVersion bits proposal, but this carries higher risk due to the complexity of tracking soft-fork state.In a discussion in 2013, concerns were raised about miners manipulating nLockTime with time-based locks. Several solutions were proposed, including using the last block's ntime instead of the current one or enforcing nLockTime based on the previous block timestamp. However, these solutions had their own drawbacks. The idea of timestamping was seen as the best solution, as it allowed all users to set their clocks to what the majority of hashing power thinks nTime is, avoiding manipulation. BIP 113 was assigned number 113 and updated accordingly with credits given to Gregory Maxwell. In another conversation, developers discussed the trade-offs between setting nLockTime to the minimum time or adding a constant offset. It was noted that without timestamping, nodes can experience consensus failures. The conclusion was that minimum time is likely the best option if hash power is well-distributed. This conversation took place on July 16th, 2013.A discussion in July 2013 focused on the issue of nLockTime and time-based locks creating negative incentives for miners. Various proposals were put forth, including using the last block's ntime instead of the current one or enforcing nLockTime based on the previous block timestamp. However, these solutions had their own drawbacks. Timestamping was seen as a potential solution, but it introduced new risks such as an inflation attack. Ultimately, there was no good incentive to set nTime accurately other than miners rejecting blocks, which sabotages the purpose of nLockTime. Another conversation discussed the use of "min" as a potential solution to consensus failure, provided that hashpower is well distributed. The context also includes an email signature and attachment that cannot be further analyzed or contextualized.A user has submitted a pull request for the median-past timelock BIP on GitHub and asks for a link to the related discussion. Peter Todd responds, acknowledging Gregory Maxwell for the idea and giving credit to Mark Friedenbach for designing and authoring the reference implementation. Thomas Kerin is credited as the author of the BIP document. The email also includes a PGP signature.In an email thread on the bitcoin-dev mailing list, Peter Todd acknowledges an oversight in editing and requests a link to a discussion about incentives related to nTime. He states that Gregory Maxwell should receive credit for the idea discussed between him and Luke-Jr. Todd offers to search for the link for historical interest.The email thread discusses a Bitcoin Improvement Proposal authored by Thomas Kerin and with Mark Friedenbach designing and authoring the reference implementation. However, Peter Todd clarifies that Gregory Maxwell actually came up with the idea during a discussion about incentives related to nTime on #bitcoin-dev or #bitcoin-wizards.
Updated on: 2023-08-01T15:29:05.658834+00:00