BIP proposal: Reserved nversion bits in blockheader [combined summary]



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

Published on: 2018-03-07T15:48:00+00:00


Summary:

On March 7, 2018, Btc Drak proposed a new Bitcoin Improvement Proposal (BIP) to reserve 16 bits of the block header nVersion field for general-purpose use and remove their meaning for version bits soft-fork signaling. The purpose of this proposal was to allow miners to utilize some of the nVersion bits for other purposes without generating false warnings about unknown soft forks. By implementing this change, the number of parallel soft-fork activations using version bits would be reduced from 29 to 13, while preventing node software from emitting false warnings. It should be noted that this proposal does not assign specific bits for specific purposes, allowing flexibility for version-rolling AsicBoost or nonce rolling to reduce CPU load on mining controllers.Luke Dashjr responded to Btc Drak's proposal by questioning the necessity of it and pointing out that similar proposals were made years ago by Timo and Sergio. He suggested that the current draft should integrate their work without attempting to take credit for it. Furthermore, Dashjr emphasized that it would be inappropriate to implement a draft BIP on the mainnet before any discussion or consensus had been reached, describing such actions as malicious.Jan Čapek criticized the reasoning behind the choice of the new method for miner configuration, arguing that defining the response type would have been a better solution than reinventing it incompatibly for no reason. This criticism was directed at the mining.configure proposal, which aimed to address issues with the existing method, mining.capabilities. The decision to adopt mining.configure was based on the expectation of a deterministic response. Additional information regarding the rationale for this new method can be found on Github.In summary, the email thread discusses two proposals related to Bitcoin mining. The first proposal involves a new miner configuration method called mining.configure, chosen for its expected deterministic response. The second proposal aims to reserve 16 bits of the block header nVersion field for general-purpose use and remove their meaning for version bits soft-fork signaling. This proposal would reduce the number of parallel soft-fork activations using version bits and prevent false warnings from node software. Luke Dashjr expressed concerns about the necessity and proper procedure of implementing these proposals, while Jan Čapek criticized the reasoning behind the choice of the new miner configuration method.


Updated on: 2023-08-01T22:47:00.850446+00:00