How can an output commit to several ways of spending?

Evidence

Each numbered marker in the text points here, and the ↩ links lead back to every place that cites an entry. Quotes are verbatim from the BIP files at commit 3a10b5b, including their wiki markup; links open the exact lines; the quoted text sits under each entry. Labels say what kind of statement each is: a rule, the author’s rationale, history, a test vector, or our own inference.

1. ↩ a b Author’s rationale The authors aim to minimize how much information about an output's spending conditions is revealed on chain, when it is created or spent.

   BIP 341 L31

   Quoted source text (1)

   Specifically, it seeks to minimize how much information about the spendability conditions of a transaction output is revealed on chain at creation or spending time

2. ↩ Author’s rationale In the authors' design, Merkle branches let a spend reveal only the executed part of the script rather than every way it could have been executed.

   BIP 341 L40

   Quoted source text (1)

   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.

3. ↩ History BIP 341 is a consensus soft-fork proposal assigned in 2020; its preamble records the status Deployed and that it requires BIP 340.

   BIP 341 L3 BIP 341 L10 BIP 341 L12 BIP 341 L16

   Quoted source text (4)

   Layer: Consensus (soft fork)

   Status: Deployed

   Assigned: 2020-01-19

   Requires: 340

4. ↩ History The BIP records that the deployment activated at height 709632 on Bitcoin mainnet, alongside BIP 342.

   BIP 341 L347 BIP 341 L312

   Quoted source text (2)

   The deployment did activate at height 709632 on Bitcoin mainnet.

   This BIP is deployed concurrently with [[bip-0342.mediawiki|BIP342]].

5. ↩ Rule BIP 341 proposes a SegWit version 1 output type whose spending rules are based on Taproot, Schnorr signatures and Merkle branches.

   BIP 341 L23

   Quoted source text (1)

   This document proposes a new SegWit version 1 output type, with spending rules based on Taproot, Schnorr signatures, and Merkle branches.

6. ↩ a b c d Rule Informally, the output is a point Q = P + hash(P||m)G for a public key P and the root m of a Merkle tree of (version, script) leaves; it is spent with a signature for Q, or by revealing P, the script and leaf version, inputs that satisfy the script, and a Merkle path proving Q committed to that leaf. All hashes are tagged.

   BIP 341 L48 BIP 341 L48

   Quoted source text (2)

   ''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.

   are tagged to guarantee domain separation.

7. ↩ a b Rule The witness program q is called the taproot output key and p the taproot internal key.

   BIP 341 L83

   Quoted source text (1)

   ''q'' is referred to as ''taproot output key'' and ''p'' as ''taproot internal key''.

8. ↩ a b Rule If no script path is needed, the BIP says the output key should still commit to an unspendable script path, Q = P + int(hash_TapTweak(bytes(P)))G, instead of having none; the authors explain that with some key-aggregation schemes a party could otherwise hide a script path, though MuSig's randomized aggregation does not have this issue.

   BIP 341 L158 BIP 341 L159 BIP 341 L161

   Quoted source text (3)

   If the spending conditions do not require a script path, the output key should commit to an unspendable script path instead of having no script path. This can be achieved by computing the output key point as ''Q = P + int(hash_TapTweak(bytes(P)))G''.

   If the taproot output key is an aggregate of keys, there is the possibility for a malicious party to add a script path without being noticed by the other parties.

   MuSig key aggregation does not have this issue because it already causes the internal key to be randomized.

9. ↩ a b Test vector Vector 0 has no script tree; its tweak hashes the internal key alone, as the BIP's no-script recommendation describes, and its output key still differs from the internal key.

   BIP 341 (wallet-test-vectors.json) L7

   Quoted source text (1)

   "scriptTree": null

10. ↩ a b c d e f Test vector This site's model reproduces every published value in BIP 341's wallet vectors: for all 7 scriptPubKey vectors the leaf hashes, Merkle root, tweak, output key, scriptPubKey and control blocks, and for all 7 key-path inputs the internal key, tweak, tweaked secret key, SigMsg, sighash and witness signature; every control block passes the BIP's commitment check.

    BIP 341 L298

    Quoted source text (1)

    Test vectors for wallet operation (scriptPubKey computation, key path spending, control block construction) can be found [[bip-0341/wallet-test-vectors.json|here]].

11. ↩ a b c d Rule The verifier computes t = hash_TapTweak(p || k_m), fails if t is not below the curve order, computes Q = P + int(t)G, and fails unless q equals x(Q) and the control block's low bit equals the parity of Q's y coordinate.

    BIP 341 L77 BIP 341 L79–80

    Quoted source text (2)

    Let ''t = hash_TapTweak(p || k_m)''.

    Let ''Q = P + int(t)G''. ** If ''q ≠ x(Q)'' or ''c[0] & 1 ≠ y(Q) mod 2'', fail

12. ↩ Rule A Taproot output is a native SegWit version 1 output with a 32-byte witness program; other version 1 outputs, including other lengths and P2SH-wrapped ones, remain unencumbered by these rules.

    BIP 341 L58 BIP 341 L59 BIP 341 L59

    Quoted source text (3)

    A Taproot output is a native SegWit output (see [[bip-0141.mediawiki|BIP141]]) with version number 1, and a 32-byte witness program.

    Any other outputs, including version 1 outputs with lengths other than 32 bytes, or P2SH-wrapped version 1 outputs

    remain unencumbered.

13. ↩ Rule Non-upgraded nodes treat every SegWit version 1 program as anyone-can-spend.

    BIP 341 L354

    Quoted source text (1)

    Non-upgraded nodes, however, will consider all SegWit version 1 witness programs as anyone-can-spend scripts.

14. ↩ Rule A key path spend is a BIP 340 signature made with the internal secret key tweaked by the same hash as the output key.

    BIP 341 L250

    Quoted source text (1)

    a [[bip-0340.mediawiki|BIP340]] signature on the signature hash as defined above, with the secret key tweaked by the same <code>h</code> as in the above snippet.

15. ↩ a b c Rule The control block holds the internal key p in bytes 1–32 and the leaf version in the first byte (c[0] & 0xfe); the leaf hash is hash_TapLeaf(v || compact_size(size of s) || s).

    BIP 341 L69 BIP 341 L70 BIP 341 L71

    Quoted source text (3)

    Let ''p = c[1:33]'' and let ''P = lift_x(int(p))''

    Let ''v = c[0] & 0xfe'' and call it the ''leaf version''

    Let ''k₀ = hash_TapLeaf(v || compact_size(size of s) || s)''; also call it the ''tapleaf hash''.

16. ↩ a b Rule Each path step hashes the running hash k with the next control-block hash e using hash_TapBranch, putting the lexicographically smaller first; the authors sort so that spends need not reveal left/right directions.

    BIP 341 L75–76 BIP 341 L76 BIP 341 L74

    Quoted source text (3)

    If ''k_j < e_j'': ''k_j+1 = hash_TapBranch(k_j || e_j)''

    If ''k_j &ge; e_j'': ''k_j+1 = hash_TapBranch(e_j || k_j)''.

    By doing so, it is not necessary to reveal the left/right directions along with the hashes in revealed Merkle branches.

17. ↩ a b Rule Scripts go in the leaves of a binary tree, which can be balanced if conditions are equally likely or built as a Huffman tree if their probabilities are known.

    BIP 341 L170

    Quoted source text (1)

    The remaining scripts should be organized into the leaves of a binary tree. This can be a balanced tree if each of the conditions these scripts correspond to are equally likely. If probabilities for each condition are known, consider constructing the tree as a Huffman tree.

18. ↩ a b Rule The construction and spending guidance is for wallets and is not consensus critical; every Taproot output combines one key condition (the internal key) with zero or more scripts in a tree, and satisfying any one suffices.

    BIP 341 L148–149 BIP 341 L151–152

    Quoted source text (2)

    This section discusses how to construct and spend Taproot outputs. It only affects wallet software that chooses to implement receiving and spending, and is not consensus critical in any way.

    Conceptually, every Taproot output corresponds to a combination of a single public key condition (the internal key), and zero or more general conditions encoded in scripts organized in a tree. Satisfying any of these conditions is sufficient to spend the output.

19. ↩ a b c d Test vector In scriptPubKey vector 5, leaf A sits one level below the root and leaves B and C two levels down, so their control blocks are 65, 97 and 97 bytes; input 4 of the key-path vector spends this same output with a 64-byte SIGHASH_DEFAULT signature that verifies against its output key.

    BIP 341 (wallet-test-vectors.json) L139 BIP 341 (wallet-test-vectors.json) L351–354 BIP 341 (wallet-test-vectors.json) L354

    Quoted source text (3)

    "internalPubkey": "e0dfe2300b0dd746a3f8674dfd4525623639042569d829c7f0eed9602d263e6f"

    "txinIndex": 4

    "hashType": 0

20. ↩ a b c Author’s rationale In the BIP's Security section, only the satisfied condition is published. Key path spends prevent observers from learning the spending conditions; a script path spend leaks that a script path exists and that the key path was not used, and the leaf's depth leaks information about the tree and suggests which wallet software created the output.

    BIP 341 L280 BIP 341 L281 BIP 341 L284–285

    Quoted source text (3)

    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 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.

21. ↩ Rule A spend with no witness elements fails; after removing an annex, one remaining element means key path spending, two or more mean script path spending.

    BIP 341 L62 BIP 341 L64 BIP 341 L66

    Quoted source text (3)

    * Fail if the witness stack has 0 elements.

    If there is exactly one element left in the witness stack, key path spending is used:

    If there are at least two witness elements left, script path spending is used:

22. ↩ Rule If there are at least two witness elements and the last begins with 0x50, it is the annex, reserved for future extensions; until a soft fork defines it, users SHOULD NOT include one, or risk permanent fund loss.

    BIP 341 L63 BIP 341 L63 BIP 341 L63 BIP 341 L63

    Quoted source text (4)

    If there are at least two witness elements, and the first byte of the last element is 0x50

    this last element is called ''annex'' ''a''

    The annex is a reserved space for future extensions

    Until the meaning of this field is defined by another softfork, users SHOULD NOT include <code>annex</code> in transactions, or it may lead to PERMANENT FUND LOSS.

23. ↩ Rule In a key path spend the single witness element is a signature that must be valid for the output key q.

    BIP 341 L65

    Quoted source text (1)

    The single witness stack element is interpreted as the signature and must be valid (see the next section) for the public key ''q''

24. ↩ a b Rule A 64-byte key-path signature is checked with BIP 340 Verify against q and the message hash_TapSighash(0x00 || SigMsg(0x00, 0)); a 65-byte signature whose last byte is 0x00 is invalid.

    BIP 341 L142 BIP 341 L143

    Quoted source text (2)

    If the ''sig'' is 64 bytes long, return ''Verify(q, hash_TapSighash(0x00 || SigMsg(0x00, 0)), sig)''

    If the ''sig'' is 65 bytes long, return ''sig[64] &ne; 0x00

25. ↩ Rule In a script path spend the second-to-last element is the script s and the last is the control block c, which must be 33 + 32m bytes long for an integer m from 0 to 128.

    BIP 341 L67–68

    Quoted source text (1)

    ** Call the second-to-last stack element ''s'', the script. ** The last stack element is called the control block ''c'', and must have length ''33 + 32m'', for a value of ''m'' that is an integer between 0 and 128

26. ↩ Author’s rationale The authors include the parity bit because lifting q to a unique point is needed for batch verification.

    BIP 341 L80

    Quoted source text (1)

    The parity of the Y coordinate is necessary to lift the X coordinate ''q'' to a unique point. While this is not strictly necessary for verifying the taproot commitment as described above, it is necessary to allow batch verification.

27. ↩ Test vector With vector 5's published control block for one leaf, the commitment check fails for any other leaf's script, for a flipped parity bit, and against another vector's output key.

    BIP 341 L80

    Quoted source text (1)

    If ''q &ne; x(Q)'' or ''c[0] & 1 &ne; y(Q) mod 2'', fail

28. ↩ Rule After the commitment check the script is executed under the rules for its leaf version, which BIP 342 specifies for leaf version 0xc0; script inputs are the remaining witness elements.

    BIP 341 L81 BIP 341 L81 BIP 341 L81

    Quoted source text (3)

    Execute the script, according to the applicable script rules

    [[bip-0342.mediawiki|BIP342]] specifies validity rules that apply for leaf version 0xc0

    using the witness stack elements excluding the script ''s'', the control block ''c'', and the annex ''a'' if present, as initial stack.

29. ↩ Rule In the wallet vectors, hex values are byte arrays written first byte first, unlike the reversed convention for txids.

    BIP 341 L302

    Quoted source text (1)

    In all cases, hexadecimal values represent byte arrays, not numbers. In particular, that means that provided hash values have the hex digits corresponding to the first bytes first.

30. ↩ Author’s rationale Taproot makes outputs spendable by a key or, optionally, a script, indistinguishable from each other; as long as the key path is used, it is not revealed whether a script path was permitted.

    BIP 341 L41

    Quoted source text (1)

    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

31. ↩ Author’s rationale The authors argue, assuming most applications involve outputs all parties could agree to spend, that most can use the key path because Schnorr signatures permit key aggregation: a key built from several participants' keys, which needs all of them to sign, and looks like a single-party key.

    BIP 341 L42 BIP 341 L42 BIP 341 L42

    Quoted source text (3)

    Taproot's advantages become apparent under the assumption that most applications involve outputs that could be spent by all parties agreeing.

    This means that with taproot most applications can use the key-based spending path, which is both efficient and private.

    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.

32. ↩ Rule For several required signers the BIP points to aggregation techniques such as MuSig, whose details it leaves out of scope; it recommends making the most likely single-key condition the internal key.

    BIP 341 L156 BIP 341 L157

    Quoted source text (2)

    When a single condition requires signatures with multiple keys, key aggregation techniques like MuSig can be used to combine them into a single key. The details are out of scope for this document

    If one or more of the spending conditions consist of just a single key (after aggregation), the most likely one should be made the internal key.

33. ↩ Editorial inference Simply summing participants' keys is open to key cancellation and related attacks; the BIP's own example uses MSDL-pop, where a plain sum is made safe by proofs of possession, and points to MuSig, whose aggregation randomizes the key.

    BIP 341 L164–165 BIP 341 L161

    Quoted source text (2)

    In order to prevent key cancellation and related attacks they use [https://eprint.iacr.org/2018/483.pdf MSDL-pop] instead of MuSig. The MSDL-pop protocol requires all parties to provide a proof of possession of their corresponding secret key and the aggregated key is just the sum of the individual keys.

    MuSig key aggregation does not have this issue because it already causes the internal key to be randomized.

34. ↩ Rule The BIP says taproot outputs should never reuse keys, for privacy, including in every leaf.

    BIP 341 L288–289

    Quoted source text (1)

    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.

35. ↩ a b Rule A Taproot signature is a 64-byte BIP 340 signature, optionally followed by a sighash byte; without it, SIGHASH_DEFAULT (0x00), which signs the whole transaction like SIGHASH_ALL, is implied.

    BIP 341 L139 BIP 341 L93

    Quoted source text (2)

    A Taproot signature is a 64-byte Schnorr signature, as defined in [[bip-0340.mediawiki|BIP340]], with the sighash byte appended in the usual Bitcoin fashion. This sighash byte is optional. If omitted, the resulting signatures are 64 bytes, and a SIGHASH_DEFAULT mode is implied.

    We define a new ''hashtype'' <code>SIGHASH_DEFAULT</code> (value ''0x00'') which results in signing over the whole transaction just as for <code>SIGHASH_ALL</code>.

36. ↩ a b Rule Unless ANYONECANPAY is set, the signature message commits to the amounts and scriptPubKeys of all outputs the transaction spends; the authors say this stops lying to offline signers about the fee and about the outputs being spent.

    BIP 341 L133 BIP 341 L133 BIP 341 L132 BIP 341 L132

    Quoted source text (4)

    If the <code>SIGHASH_ANYONECANPAY</code> flag is not set, the message commits to the amounts of ''all'' transaction inputs.

    This eliminates the possibility to lie to offline signing devices about the fee of a transaction.

    if the <code>SIGHASH_ANYONECANPAY</code> flag is not set, the message commits to the ''scriptPubKey''s of ''all'' outputs spent by the transaction.

    This prevents lying to offline signing devices about output being spent

37. ↩ Rule SigMsg is at most 206 bytes, not counting sub-hashes that can be cached across signatures.

    BIP 341 L128

    Quoted source text (1)

    The total length of ''SigMsg()'' is at most ''206'' bytes