BIP 0341 - Revision history

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/04a965681049ee77/bip-0341.mediawiki

2023-06-29T18:04:44Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/04a965681049ee77/bip-0341.mediawiki

← Older revision		Revision as of 18:04, 29 June 2023
Line 156:		Line 156:
	* When deciding between scripts with conditionals (<code>OP_IF</code> etc.) and splitting them up into multiple scripts (each corresponding to one execution path through the original script), it is generally preferable to pick the latter.		* When deciding between scripts with conditionals (<code>OP_IF</code> etc.) and splitting them up into multiple scripts (each corresponding to one execution path through the original script), it is generally preferable to pick the latter.
	* 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, but note that this may complicate the signing procedure.		* 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, but note that this may complicate the signing procedure.
	* 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. If no such condition exists, it may be worthwhile adding one that consists of an aggregation of all keys participating in all scripts combined; effectively adding an "everyone agrees" branch. If that is inacceptable, pick as internal key a point with unknown discrete logarithm. One example of such a point is ''H = lift_x(~~0x0250929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0~~)'' which is [https://github.com/ElementsProject/secp256k1-zkp/blob/11af7015de624b010424273be3d91f117f172c82/src/modules/rangeproof/main_impl.h#L16 constructed] by taking the hash of the standard uncompressed encoding of the [https://www.secg.org/sec2-v2.pdf secp256k1] base point ''G'' as X coordinate. In order to avoid leaking the information that key path spending is not possible it is recommended to pick a fresh integer ''r'' in the range ''0...n-1'' uniformly at random and use ''H + rG'' as internal key. It is possible to prove that this internal key does not have a known discrete logarithm with respect to ''G'' by revealing ''r'' to a verifier who can then reconstruct how the internal key was created.		* 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. If no such condition exists, it may be worthwhile adding one that consists of an aggregation of all keys participating in all scripts combined; effectively adding an "everyone agrees" branch. If that is inacceptable, pick as internal key a "Nothing Up My Sleeve" (NUMS) point, i.e., a point with unknown discrete logarithm. One example of such a point is ''H = lift_x(0x50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0)'' which is [https://github.com/ElementsProject/secp256k1-zkp/blob/11af7015de624b010424273be3d91f117f172c82/src/modules/rangeproof/main_impl.h#L16 constructed] by taking the hash of the standard uncompressed encoding of the [https://www.secg.org/sec2-v2.pdf secp256k1] base point ''G'' as X coordinate. In order to avoid leaking the information that key path spending is not possible it is recommended to pick a fresh integer ''r'' in the range ''0...n-1'' uniformly at random and use ''H + rG'' as internal key. It is possible to prove that this internal key does not have a known discrete logarithm with respect to ''G'' by revealing ''r'' to a verifier who can then reconstruct how the internal key was created.
	* 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<sub>TapTweak</sub>(bytes(P)))G''. <ref>'''Why should the output key always have a taproot commitment, even if there is no script path?'''		* 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<sub>TapTweak</sub>(bytes(P)))G''. <ref>'''Why should the output key always have a taproot commitment, even if there is no script path?'''
	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.		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.

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/a8a0191978b451aa/bip-0341.mediawiki

2023-03-24T05:46:47Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/a8a0191978b451aa/bip-0341.mediawiki

← Older revision		Revision as of 05:46, 24 March 2023
Line 109:		Line 109:
	** If the ''hash_type & 0x80'' does not equal <code>SIGHASH_ANYONECANPAY</code>:		** If the ''hash_type & 0x80'' does not equal <code>SIGHASH_ANYONECANPAY</code>:
	*** ''sha_prevouts'' (32): the SHA256 of the serialization of all input outpoints.		*** ''sha_prevouts'' (32): the SHA256 of the serialization of all input outpoints.
	*** ''sha_amounts'' (32): the SHA256 of the serialization of all ~~spent output~~ amounts.		*** ''sha_amounts'' (32): the SHA256 of the serialization of all input amounts.
	*** ''sha_scriptpubkeys'' (32): the SHA256 of all spent outputs' ''scriptPubKeys'', serialized as script inside <code>CTxOut</code>.		*** ''sha_scriptpubkeys'' (32): the SHA256 of all spent outputs' ''scriptPubKeys'', serialized as script inside <code>CTxOut</code>.
	*** ''sha_sequences'' (32): the SHA256 of the serialization of all input ''nSequence''.		*** ''sha_sequences'' (32): the SHA256 of the serialization of all input ''nSequence''.

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/aa5b0a1009bcb903/bip-0341.mediawiki

2023-02-27T02:47:09Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/aa5b0a1009bcb903/bip-0341.mediawiki

← Older revision		Revision as of 02:47, 27 February 2023
Line 11:		Line 11:
	Comments-Summary: No comments yet.		Comments-Summary: No comments yet.
	Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0341		Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0341
	Status: ~~Draft~~		Status: Final
	Type: Standards Track		Type: Standards Track
	Created: 2020-01-19		Created: 2020-01-19

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/2361582f0b921977/bip-0341.mediawiki

2023-01-05T01:01:24Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/2361582f0b921977/bip-0341.mediawiki

← Older revision		Revision as of 01:01, 5 January 2023
Line 253:		Line 253:
	<source lang="python">		<source lang="python">
	def taproot_sign_key(script_tree, internal_seckey, hash_type, bip340_aux_rand):		def taproot_sign_key(script_tree, internal_seckey, hash_type, bip340_aux_rand):
	_, h = taproot_tree_helper(script_tree)		if script_tree is None:
			h = bytes()
			else:
			_, h = taproot_tree_helper(script_tree)
	output_seckey = taproot_tweak_seckey(internal_seckey, h)		output_seckey = taproot_tweak_seckey(internal_seckey, h)
	sig = schnorr_sign(sighash(hash_type), output_seckey, bip340_aux_rand)		sig = schnorr_sign(sighash(hash_type), output_seckey, bip340_aux_rand)

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/79bb53dde55e94eb/bip-0341.mediawiki

2023-01-04T03:04:42Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/79bb53dde55e94eb/bip-0341.mediawiki

← Older revision		Revision as of 03:04, 4 January 2023
Line 252:		Line 252:

	<source lang="python">		<source lang="python">
	def taproot_sign_key(script_tree, internal_seckey, hash_type):		def taproot_sign_key(script_tree, internal_seckey, hash_type, bip340_aux_rand):
	_, h = taproot_tree_helper(script_tree)		_, h = taproot_tree_helper(script_tree)
	output_seckey = taproot_tweak_seckey(internal_seckey, h)		output_seckey = taproot_tweak_seckey(internal_seckey, h)
	sig = schnorr_sign(sighash(hash_type), output_seckey)		sig = schnorr_sign(sighash(hash_type), output_seckey, bip340_aux_rand)
	if hash_type != 0:		if hash_type != 0:
	sig += bytes([hash_type])		sig += bytes([hash_type])

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/c6725580c53f6478/bip-0341.mediawiki

2023-01-04T01:37:03Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/c6725580c53f6478/bip-0341.mediawiki

← Older revision		Revision as of 01:37, 4 January 2023
Line 186:		Line 186:
	if t >= SECP256K1_ORDER:		if t >= SECP256K1_ORDER:
	raise ValueError		raise ValueError
	Q = ~~point_add(~~lift_x(~~int~~(pubkey)), point_mul(G, t))		P = lift_x(int_from_bytes(pubkey))
			if P is None:
			raise ValueError
			Q = point_add(P, point_mul(G, t))
	return 0 if has_even_y(Q) else 1, bytes_from_int(x(Q))		return 0 if has_even_y(Q) else 1, bytes_from_int(x(Q))

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/e76137c32ddefbd5/bip-0341.mediawiki

2022-09-30T00:26:55Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/e76137c32ddefbd5/bip-0341.mediawiki

← Older revision		Revision as of 00:26, 30 September 2022
Line 190:		Line 190:

	def taproot_tweak_seckey(seckey0, h):		def taproot_tweak_seckey(seckey0, h):
	P = point_mul(G, ~~int_from_bytes(~~seckey0))		seckey0 = int_from_bytes(seckey0)
			P = point_mul(G, seckey0)
	seckey = seckey0 if has_even_y(P) else SECP256K1_ORDER - seckey0		seckey = seckey0 if has_even_y(P) else SECP256K1_ORDER - seckey0
	t = int_from_bytes(tagged_hash("TapTweak", bytes_from_int(x(P)) + h))		t = int_from_bytes(tagged_hash("TapTweak", bytes_from_int(x(P)) + h))
	if t >= SECP256K1_ORDER:		if t >= SECP256K1_ORDER:
	raise ValueError		raise ValueError
	return (seckey + t) % SECP256K1_ORDER		return bytes_from_int((seckey + t) % SECP256K1_ORDER)
	</source>		</source>

Line 354:		Line 355:
	== Acknowledgements ==		== Acknowledgements ==

	This document is the result of discussions 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.		This document is the result of discussions 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 authors wish the 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 [https://github.com/ajtowns/taproot-review structured reviews].		The authors wish the 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 [https://github.com/ajtowns/taproot-review structured reviews].

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/52f68fecd8ec9604/bip-0341.mediawiki

2022-08-25T08:05:59Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/52f68fecd8ec9604/bip-0341.mediawiki

← Older revision		Revision as of 08:05, 25 August 2022
Line 186:		Line 186:
	if t >= SECP256K1_ORDER:		if t >= SECP256K1_ORDER:
	raise ValueError		raise ValueError
	Q = point_add(lift_x(pubkey), point_mul(G, t))		Q = point_add(lift_x(int(pubkey)), point_mul(G, t))
	return 0 if has_even_y(Q) else 1, bytes_from_int(x(Q))		return 0 if has_even_y(Q) else 1, bytes_from_int(x(Q))

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/8530c16c3bb12a46/bip-0341.mediawiki

2022-01-16T00:26:54Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/8530c16c3bb12a46/bip-0341.mediawiki

← Older revision		Revision as of 00:26, 16 January 2022
Line 142:		Line 142:
	To validate a signature ''sig'' with public key ''q'':		To validate a signature ''sig'' with public key ''q'':
	* If the ''sig'' is 64 bytes long, return ''Verify(q, hash<sub>TapSighash</sub>(0x00 \|\| SigMsg(0x00, 0)), sig)''<ref>'''Why is the input to ''hash<sub>TapSighash</sub>'' prefixed with 0x00?''' This prefix is called the sighash epoch, and allows reusing the ''hash<sub>TapSighash</sub>'' tagged hash in future signature algorithms that make invasive changes to how hashing is performed (as opposed to the ''ext_flag'' mechanism that is used for incremental extensions). An alternative is having them use a different tag, but supporting a growing number of tags may become undesirable.</ref>, where ''Verify'' is defined in [[bip-0340.mediawiki#design\|BIP340]].		* If the ''sig'' is 64 bytes long, return ''Verify(q, hash<sub>TapSighash</sub>(0x00 \|\| SigMsg(0x00, 0)), sig)''<ref>'''Why is the input to ''hash<sub>TapSighash</sub>'' prefixed with 0x00?''' This prefix is called the sighash epoch, and allows reusing the ''hash<sub>TapSighash</sub>'' tagged hash in future signature algorithms that make invasive changes to how hashing is performed (as opposed to the ''ext_flag'' mechanism that is used for incremental extensions). An alternative is having them use a different tag, but supporting a growing number of tags may become undesirable.</ref>, where ''Verify'' is defined in [[bip-0340.mediawiki#design\|BIP340]].
	* If the ''sig'' is 65 bytes long, return ''sig[64] ≠ 0x00<ref>'''Why can the <code>hash_type</code> not be <code>0x00</code> in 65-byte signatures?''' Permitting that would enable malleating (by third parties, including miners) 64-byte signatures into 65-byte ones, resulting in a different `wtxid` and a different fee rate than the creator intended</ref> and Verify(q, hash<sub>TapSighash</sub>(0x00 \|\| SigMsg(sig[64], 0)), sig[0:64])''.		* If the ''sig'' is 65 bytes long, return ''sig[64] ≠ 0x00<ref>'''Why can the <code>hash_type</code> not be <code>0x00</code> in 65-byte signatures?''' Permitting that would enable malleating (by third parties, including miners) 64-byte signatures into 65-byte ones, resulting in a different `wtxid` and a different fee rate than the creator intended.</ref> and Verify(q, hash<sub>TapSighash</sub>(0x00 \|\| SigMsg(sig[64], 0)), sig[0:64])''.
	* Otherwise, fail<ref>'''Why permit two signature lengths?''' By making the most common type of <code>hash_type</code> implicit, a byte can often be saved.</ref>.		* Otherwise, fail<ref>'''Why permit two signature lengths?''' By making the most common type of <code>hash_type</code> implicit, a byte can often be saved.</ref>.

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/3693cdfd192dacda/bip-0341.mediawiki

2022-01-07T03:43:21Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/3693cdfd192dacda/bip-0341.mediawiki

← Older revision		Revision as of 03:43, 7 January 2022
Line 82:		Line 82:
	** Let ''Q = P + int(t)G''.		** Let ''Q = P + int(t)G''.
	** If ''q ≠ x(Q)'' or ''c[0] & 1 ≠ y(Q) mod 2'', fail<ref>'''Why is it necessary to reveal a bit in a script path spend and check that it matches the parity of the Y coordinate of ''Q''?''' 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. Alternatively, ''Q'' could be forced to have an even Y coordinate, but that would require retrying with different internal public keys (or different messages) until ''Q'' has that property. There is no downside to adding the parity bit because otherwise the control block bit would be unused.</ref>.		** If ''q ≠ x(Q)'' or ''c[0] & 1 ≠ y(Q) mod 2'', fail<ref>'''Why is it necessary to reveal a bit in a script path spend and check that it matches the parity of the Y coordinate of ''Q''?''' 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. Alternatively, ''Q'' could be forced to have an even Y coordinate, but that would require retrying with different internal public keys (or different messages) until ''Q'' has that property. There is no downside to adding the parity bit because otherwise the control block bit would be unused.</ref>.
	** Execute the script, according to the applicable script rules<ref>'''What are the applicable script rules in script path spends?''' [[bip-0342.mediawiki\|BIP342]] specifies validity rules that apply for leaf version 0xc0, but future proposals can introduce rules for other leaf versions.</ref>, using the witness stack elements excluding the script ''s'', the control block ''c'', and the annex ''a'' if present, as initial stack.		** Execute the script, according to the applicable script rules<ref>'''What are the applicable script rules in script path spends?''' [[bip-0342.mediawiki\|BIP342]] specifies validity rules that apply for leaf version 0xc0, but future proposals can introduce rules for other leaf versions.</ref>, using the witness stack elements excluding the script ''s'', the control block ''c'', and the annex ''a'' if present, as initial stack. This implies that for the future leaf versions (non-''0xC0'') the execution must succeed.<ref>'''Why we need to success on future leaf version validation''' This is required to enable future leaf versions as soft forks</ref>.

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