Author: Vincent Truong 2015-12-08 21:02:55
Published on: 2015-12-08T21:02:55+00:00
In a discussion among Bitcoin developers regarding the implementation of soft forks, hard forks or new features, it was suggested that wallet developers need only indicate their readiness for the change rather than actually implementing it. The proposal to split the version field in two - with the first four bytes dedicated to the version number and the second four bits set aside for transaction type - was also discussed. While the BIP9 mechanism may apply to voting on blocks, it does not necessarily apply to transactions, which essentially affect at most two parties. The nature of soft forks means that wallets can choose whether to implement a new feature or not. Any new transaction feature should get a new "type" number and cannot happen until the nodes support it. The idea of extending/copying isSupermajority() for non-critical functions to look for a similar BIP 9 style version bit in transactions was also explored. This would allow wallet developers and exchanges to signal their readiness for changes, making sure they aren't going to break or introduce security flaws for users. Miners can watch for the readiness flagged by wallets before they themselves flag ready. However, it was acknowledged that this could be computationally expensive for Bitcoin Core to run, and therefore enthusiasts outside the network may need to monitor transactions instead. Overall, the discussion revolved around finding ways to make the implementation of new features as politically correct as possible while ensuring readiness for change.
Updated on: 2023-06-11T01:52:20.357822+00:00