ReddCoin (RDD) 4.22 Taproot: SegWit version 1 spending rules (BIP0341)

A complex description of BIP0341 adapted to ReddCoin’s bespoke PoSVv2 staking protocol. Includes initial activation of SegWit (Segregated Witness) network and address support. Content adapted from BTC’s wiki

A number of related ideas for improving ReddCoin’s scripting capabilities have been previously proposed: Schnorr signatures (BIP340), Merkle branches (“MAST”, BIP114, BIP117), new sighash modes (BIP118), new opcodes like CHECKSIGFROMSTACK, Taproot, Graftroot, G’root, and cross-input aggregation.

Mind your p’s and q’s…

Combining all these ideas in a single proposal would be an extensive change, be hard to review, and likely miss new discoveries that otherwise could have been made along the way. Not all are equally mature as well. For example, cross-input aggregation interacts in complex ways with upgrade mechanisms, and solutions to that are still in flux. On the other hand, separating them all into independent upgrades would reduce the efficiency and privacy gains to be had, and wallet and service providers may not be inclined to go through many incremental updates. Therefore, we’re faced with a tradeoff between functionality and scope creep. In this design we strike a balance by focusing on the structural script improvements offered by Taproot and Merkle branches, as well as changes necessary to make them usable and efficient. For things like sighashes and opcodes we include fixes for known problems, but exclude new features that can be added independently with no downsides.

As a result we choose this combination of technologies:

• Merkle branches let us only reveal the actually executed part of the script to the blockchain, as opposed to all possible ways a script can be executed. Among the various known mechanisms for implementing this, one where the Merkle tree becomes part of the script’s structure directly maximizes the space savings, so that approach is chosen.
• Taproot on top of that lets us merge the traditionally separate pay-to-pubkey and pay-to-scripthash policies, making all outputs spendable by either a key or (optionally) a script, and indistinguishable from each other. As long as the key-based spending path is used for spending, it is not revealed whether a script path was permitted as well, resulting in space savings and an increase in scripting privacy at spending time.
• Taproot’s advantages become apparent under the assumption that most applications involve outputs that could be spent by all parties agreeing. That’s where Schnorr signatures come in, as they permit key aggregation: a public key can be constructed from multiple participant public keys, and which requires cooperation between all participants to sign for. Such multi-party public keys and signatures are indistinguishable from their single-party equivalents. This means that with taproot most applications can use the key-based spending path, which is both efficient and private. This can be generalized to arbitrary M-of-N policies, as Schnorr signatures support threshold signing, at the cost of more complex setup protocols.
• As Schnorr signatures also permit batch validation, allowing multiple signatures to be validated together more efficiently than validating each one independently, we make sure all parts of the design are compatible with this.
• Where unused bits appear as a result of the above changes, they are reserved for mechanisms for future extensions. As a result, every script in the Merkle tree has an associated version such that new script versions can be introduced with a soft fork while remaining compatible with BIP 341. Additionally, future soft forks can make use of the currently unused annex in the witness (see BIP341).
• While the core semantics of the signature hashing algorithm are not changed, a number of improvements are included in this proposal. The new signature hashing algorithm fixes the verification capabilities of offline signing devices by including amount and scriptPubKey in the signature message, avoids unnecessary hashing, uses tagged hashes and defines a default sighash byte.
• The public key is directly included in the output in contrast to typical earlier constructions which store a hash of the public key or script in the output. This has the same cost for senders and is more space efficient overall if the key-based spending path is taken. [2]

Informally, the resulting design is as follows: a new witness version is added (version 1), whose programs consist of 32-byte encodings of points Q. Q is computed as P + hash(P||m)G for a public key P, and the root m of a Merkle tree whose leaves consist of a version number and a script. These outputs can be spent directly by providing a signature for Q, or indirectly by revealing P, the script and leaf version, inputs that satisfy the script, and a Merkle path that proves Q committed to that leaf. All hashes in this construction (the hash for computing Q from P, the hashes inside the Merkle tree’s inner nodes, and the signature hashes used) are tagged to guarantee domain separation.

Easy stuff.

Security

Taproot improves the privacy of ReddCoin (RDD) because instead of revealing all possible conditions for spending an output, only the satisfied spending condition has to be published. Ideally, outputs are spent using the key path which prevents observers from learning the spending conditions of a coin. A key path spend could be a “normal” payment from a single- or multi-signature wallet or the cooperative settlement of hidden multiparty contract.

A script path spend leaks that there is a script path and that the key path was not applicable — for example because the involved parties failed to reach agreement. Moreover, the depth of a script in the Merkle root leaks information including the minimum depth of the tree, which suggests specific wallet software that created the output and helps clustering. Therefore, the privacy of script spends can be improved by deviating from the optimal tree determined by the probability distribution over the leaves.

Just like other existing output types, taproot outputs should never reuse keys, for privacy reasons. This does not only apply to the particular leaf that was used to spend an output but to all leaves committed to in the output. If leaves were reused, it could happen that spending a different output would reuse the same Merkle branches in the Merkle proof. Using fresh keys implies that taproot output construction does not need to take special measures to randomizing leaf positions because they are already randomized due to the branch-sorting Merkle tree construction used in taproot. This does not avoid leaking information through the leaf depth and therefore only applies to balanced (sub-) trees. In addition, every leaf should have a set of keys distinct from every other leaf. The reason for this is to increase leaf entropy and prevent an observer from learning an undisclosed script using brute-force search.

This BIP is deployed concurrently with BIP342 (article here).

For ReddCoin mainnet and testnet3, these BIPs are deployed by “version bits” with the name “taproot” and bit 2, using BIP9 modified to use a lower threshold, with an additional min_activation_height parameter and replacing the state transition logic for the DEFINED, STARTED and LOCKED_IN states.

As a soft fork, older software will continue to operate without modification. Non-upgraded nodes, however, will consider all SegWit version 1 witness programs as anyone-can-spend scripts. They are strongly encouraged to upgrade in order to fully validate the new programs.

Non-upgraded wallets can receive and send RDD from non-upgraded and upgraded wallets using SegWit version 0 programs, traditional pay-to-pubkey-hash, etc. Depending on the implementation non-upgraded wallets may be able to send to Segwit version 1 programs if they support sending to BIP350 Bech32m addresses.

Acknowledgements

This document is the result of ReddCoin’s team adapting directly technology, rationale, code and discussions from the BTC community and dev team around script and signature improvements with many people, and had direct contributions from Greg Maxwell and others. It further builds on top of earlier published proposals such as Taproot by Greg Maxwell, and Merkle branch constructions by Russell O’Connor, Johnson Lau, and Mark Friedenbach.

The ReddCoin team acknowledges the work of the authors who themselves wish tho thank Arik Sosman for suggesting to sort Merkle node children before hashes, removing the need to transfer the position in the tree, as well as all those who provided valuable feedback and reviews, including the participants of the structured reviews.

Source material may be found at: https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki

See also ReddCoin pub on BIP0342 deployed together with this work.

About Redd

Redd is a global social movement that allows anyone, anywhere, the power to tip, support, donate and fund social causes, independent content creators, and humanitarian programs. The platform utilizes ReddCoin (RDD), a reliable and versatile decentralized cryptocurrency launched in 2014 that allows for seamless payments across borders and social networks. All Redd Partners are expected to adhere to the project’s high standards of openness, accountability, and user experience as we strive to be an example of not only the stated ideals of love, support and inclusion, but also integrity, transparency, and honor.

Feel free to visit us at Redd.Love, Reddcoin.com or email info@reddcoin.com. You can also follow us on YouTube, Twitter and Telegram Love to all of our Reddheads, new and old, and welcome!