Published on: 2015-06-03T20:42:44+00:00
On May 26, 2015, Pieter Wuille proposed a plan for coordinating future soft-forking consensus changes on Bitcoin. The proposal supports multiple parallel changes and changes that get permanently rejected without obstructing the rollout of others. Wuille suggested using the mailing list for commenting as the gist does not support notifying participants of new comments. This joint work was done with Peter Todd and Greg Maxwell. The plan received feedback, and Wuille plans to address it and work on an implementation next week.The email conversation is a discussion on the use of the median time and nVersion soft-fork mechanisms for Bitcoin Improvement Proposals (BIPs). The median time mechanism allows hashing power to show what time they think it is, while the nVersion soft-fork mechanism enables hashing power to indicate which features they want to support. The deadline for BIPs need not be set accurately; a roughly six-month deadline should suffice, and a majority of miners are needed to abuse the median time. Increasing the number of blocks used in the median could reduce "noise". Each bit is assigned to a particular BIP for a specific range of times or blocks, and if block numbers were used for the deadline, one only needs to check the block index for the deadline block. The block at height deadline would indicate whether the BIP was locked in. Block time could still be used as long as the block height was set after that. For each block height, there is a set of known BIP bits that are allowed, and once the final deadline passes, the expected mask is zeros. There was some ambiguity in phrasing regarding changing the 95% rule, where 75% is needed to start applying it, and 95% to start rejecting blocks that do not apply it.In a discussion about manipulating the merkle tree in Bitcoin, Christian Decker and Patrick Strateman agree that there is no need to misuse the version field. Decker states that there is enough variability in the merkle tree, including and excluding transactions, and even the scriptSig of the coinbase transaction, which influences the merkle root. He has a fundamental dislike of retroactively changing semantics and thinks that the version field should only be used for that purpose. Strateman argues that any reasonable micro-controller can build merkle tree roots significantly faster than necessary, with an RPi 1 model B doing 2451050 SHA256 ops/second. Sergio Lerner likes the idea but suggests leaving at least 16 bits of the version fixed as an extra-nonce to avoid miners using them as a nonce and interfering with the soft-fork voting system. In this way, miners could permute transactions in the block by permuting the internal merkle tree nodes at increasing depths, making the tree manipulations maximum depth independent and possibly even transaction-independent, depending on how much depth in the tree of hashes are permutation safe.In a discussion on the Bitcoin-development mailing list, Chris expressed his dislike of retroactively changing semantics and proposed that the version field should only be used for its intended purpose. He also voiced support for Sipa's proposal to flag support for a fork in the version field, although he did not particularly like this solution. The discussion also included Patrick Strateman's argument that there is no need to misuse the version field, as micro-controllers can build merkle tree roots faster than necessary. Sergio Lerner suggested leaving at least 16 bits of the version fixed as an extra-nonce to prevent miners from using them as a nonce and disrupting the soft-fork voting system. Lerner's original proposal can be found on GitHub.The context discusses the efficiency of building merkle tree roots using micro-controllers. The writer argues that any reasonable micro-controller can perform this task much faster than necessary. For instance, a controller with 1 Th/s walks the nonce range in just 4.3ms. The largest valid merkle trees are 14 nodes high, which means that translating them to SHA256 operations would require 28 ops per 4.3 ms or 6511 ops/second. However, for reference, an RPi 1 model B performs 2451050 SHA256 ops/second. In response to this context, Sergio Lerner suggested leaving at least 16 bits of the version fixed as an extra-nonce. He believes that if not done, miners may use them as a nonce and interfere with the soft-fork voting system. The writer provided a link to their original proposal on Github.The author of the context suggests leaving 16 bits of the version fixed as an extra-nonce to prevent miners from using them as a nonce and interfering with the soft-fork voting system. The author provides a link to their original proposal in a GitHub pull request. It is unclear what exactly the proposal entails, but it may provide more details on how the extra-nonce would work.
Updated on: 2023-08-01T12:50:48.992239+00:00