Published on: 2017-05-03T19:41:07+00:00
BIP XXXX proposes a change to the usage of the 'OP_RETURN' script opcode in Bitcoin transactions, allowing multiple changes (features) to be deployed in parallel. The proposal relies on interpreting the output field as a bit vector, where each bit can be used to track an independent change. BIP9 introduced a mechanism for doing soft-forking changes relying on measuring miner support indicated by version bits in block headers.However, any change which may conflict with miners but is acceptable to users may be difficult to deploy. BIP XXXX can be used in conjunction with BIP 9 to more safely deploy soft-forking changes that do not require a supermajority of miners but do require a large percentage of active users. Alternatively, BIP XXXX signalling can be used to gauge user support for "features" - independent of its use as a direct deployment mechanism. Each "feature" is specified by the same set of per-chain parameters as in BIP9, with the same usage and meaning (name, bit, starttime and timeout).If the outputs contain a zero valued OP_RETURN, and the length of the key is 2 bytes, and if the first byte (prefix) of that OP_RETURN's key parameter is 0x012, then the remaining byte is to be interpreted as an 8-bit little-endian integer, and bits are selected within this integer as values. The alternative to flag-day deployment can cause issues for users of a feature that has failed to achieve adequate miner support. BIP XXXX proposes a solution to this problem.In a bitcoin-dev thread, Christian Decker proposed the extension of signaling capabilities to end-users, which would give stakeholders a voice in network decisions. He suggested using output scripts as the best field for signaling since they are specified by the recipient of funds and are already stored in the UTXO. The last 4 bits of the pubkey/pubkeyhash could be used to opt-in, with the vote (0/1) depending on the stakeholders' desired signal.However, unlike the OP_RETURN proposal, users who do not intend to signal will also be included in the tally. To ensure voluntary votes, the opt-in should be adjusted accordingly, but too many opt-in bits may exacerbate existing problems with HD Wallet lookahead. Tim Ruffing added that using addresses creates vulnerabilities, so an OP_RETURN signal seems the safest way to go for UA signaling. He suggested modeling a BIP after BIP9, with some discussion of how to properly collect statistics and the ability for nodes to activate features based on an "economic majority" defined in this way.One member of the bitcoin-dev mailing list, Tim, doesn't have a general opinion on signaling, but does express concern about using addresses for signaling, citing privacy implications. Christian Decker responds to Tim's concerns, suggesting that extending signaling capabilities to end-users would give stakeholders a voice in network decisions and provide data for informed decisions. Decker suggests several fields that could be used for signaling, including OP_RETURN, locktime, and output scripts, but ultimately decides that output scripts are likely the best option due to their easy tallying and the fact that they are already stored in the UTXO.The writer is in favor of extending signaling capabilities to the end-users. While exploring various signaling ideas, the writer suggests that fields such as OP_RETURN and locktime may not be suitable for this purpose due to issues related to data transfer, storage, and tagging. The output script field is suggested as the best option for signaling as it is specified by the recipient of funds and is already stored in UTXO. The writer also suggests using the last 4 bits of the pubkey/pubkeyhash to opt-in and vote.A proposal has been made to tag fee-paying transactions with information about the capabilities of the node that created it. The tagging would occur on the addresses, and the weighting would be by value, so it's a measure of economic significance. This could be useful in gauging economic support for certain upgrades, especially if excluding long transaction chains.A suggestion was made on the Bitcoin-dev mailing list about adding a signal to OP_RETURN that would allow users to tag validated input addresses. With this information, nodes could activate new features after a certain percentage of tagged input addresses is reached within a specific time period. This tagging may provide a better indication of economic support for certain upgrades than simply counting reachable nodes.The proposal suggests using a signal added to OP_RETURN to tag all validated input addresses. This would allow a node to activate a new feature after a certain percentage of tagged input addresses are reached within a specified time period. The idea is to use this in addition to a flag day to trigger feature activation with some reassurance of user uptake.
Updated on: 2023-08-01T20:30:08.114536+00:00