Published on: 2016-02-01T19:29:32+00:00
On February 1, 2016, Pieter Wuille proposed a second number push in the coinbase scriptSig, which would point to a 32-byte hash H. This push was accepted as it provided a more flexible and compact system than the current one. Concerns were raised about adding arbitrary data, so it was suggested that the data in the coinbase witness stack have a fixed number of entries depending on the block version number. This would allow for soft-forks to add new entries in the stack.Peter Todd discussed upgrade procedures related to segregated witnesses, suggesting the addition of a new service bit or bumping the protocol version. However, this solution did not address the issue of relaying more block data in the future, requiring another soft-fork upgrade. To solve this problem, Todd proposed making the witness data more extensible by using unvalidated block extension data. This involved a backward-incompatible change to the current segwit change, where the coinbase scriptSig would receive a second number push pointing to a 32-byte hash H. Todd also addressed concerns about miners using arbitrary data by suggesting a merkelized key:value mapping with collision-resistant IDs as keys.Pieter Wuille's segwit branch was discussed on the Bitcoin developers mailing list. It was suggested to add a new service bit or bump up the protocol version to only connect to peers with segwit support. The branch had a fHaveWitness flag for each connection, but BIP144 proposed changing this to a service bit. A pull request to change this to a NODE_WITNESS service bit has been made on GitHub.Peter Todd suggested adding a new service bit, NODE_SEGWIT, and/or bumping the protocol version to ensure outgoing peers only connect to peers with segwit support. He also proposed solutions for future upgrades adding new block data, such as removing the restriction on the coinbase witness containing exactly one 32-byte value. Another proposal involved hashing the contents of the coinbase witness as a merkle tree and committing them in place of the current nonce commitment. These proposals were discussed in a pull request on the segwit branch, including the idea of including the merkle path to the segwit data in the coinbase witness.The deployment of segregated witness poses a problem as nodes need witness data to function after activation. If full node adoption lags behind miner adoption, the segwit-supporting P2P network may partition and lose consensus. The issue is not yet fixed in Pieter Wuille's segwit branch, but one solution is to add a new service bit or bump the protocol version to only connect to peers with segwit support. However, if full node operators do not widely adopt segwit, the network could become more vulnerable. Future upgrades will require the relay network to upgrade, and BIP141 suggests an Extensible Commitment Structure to address this. This structure consists of a hashed linked list of consensus-critical commitments, with a redefinable nonce for future soft-forks. To allow for additional data in future soft-forks, the proposal is to remove the restriction on the coinbase witness, hash its contents as a merkle tree, and include that data in the blocksize limit. This allows all nodes to validate the data came from the miner and propagate it without risk of attack. This method is efficient as most future upgrades are expected to be additional commitments, and the additional data for each commitment is just 32 bytes.
Updated on: 2023-08-01T17:39:45.031342+00:00