From 24421925193cc2b702829dc92a3367ca28fe568e Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Mon, 3 Jan 2022 22:32:57 +0000 Subject: [PATCH 01/13] ZIP 244: Change semantics of `sequence_sig_digest` Co-authored-by: Daira Hopwood --- zip-0244.rst | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/zip-0244.rst b/zip-0244.rst index f210c98e1..230cc1b9f 100644 --- a/zip-0244.rst +++ b/zip-0244.rst @@ -531,8 +531,7 @@ S.2b: sequence_sig_digest This is a BLAKE2b-256 hash initialized with the personalization field value ``ZTxIdSequencHash``. -If the ``SIGHASH_ANYONECANPAY`` flag is not set, and the sighash type is neither -``SIGHASH_SINGLE`` nor ``SIGHASH_NONE``:: +If the ``SIGHASH_ANYONECANPAY`` flag is not set:: identical to the value of ``sequence_digest`` as specified for the transaction identifier in section T.2b. @@ -736,6 +735,17 @@ happens in the block that activates this ZIP. The block header byte format and version are not altered by this ZIP. +========= +Rationale +========= + +Several changes in this ZIP (relative to ZIP 243 [#zip-0243]_) were made to +align with BIP 341 [#bip-0341]_: + +- The semantics of ``sequence_sig_digest`` were changed, to commit to ``nSequence`` + even if ``SIGHASH_SINGLE`` or ``SIGHASH_NONE`` is set. The rationale for this + change is inherited from BIP 341 [#bip-0341-nSequence]_. + ======================== Reference implementation ======================== @@ -754,3 +764,5 @@ References .. [#zip-0143] `ZIP 143: Transaction Signature Validation for Overwinter `_ .. [#zip-0243] `ZIP 243: Transaction Signature Validation for Sapling `_ .. [#zip-0307] `ZIP 307: Light Client Protocol for Payment Detection `_ +.. [#bip-0341] `BIP 341: Taproot: SegWit version 1 spending rules `_ +.. [#bip-0341-nSequence] `Why does the signature message commit to all input nSequence if SIGHASH_SINGLE or SIGHASH_NONE are set? `_ From daac926497146038cd69ac0cb206462a36188c26 Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Mon, 3 Jan 2022 23:30:55 +0000 Subject: [PATCH 02/13] ZIP 244: Add new S.2 commitments to input amounts and scriptCodes Co-authored-by: Daira Hopwood --- zip-0244.rst | 65 +++++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 54 insertions(+), 11 deletions(-) diff --git a/zip-0244.rst b/zip-0244.rst index 230cc1b9f..9a3e04ca0 100644 --- a/zip-0244.rst +++ b/zip-0244.rst @@ -503,10 +503,12 @@ The construction of each component below depends upon the values of the This digest is a BLAKE2b-256 hash of the following values :: - S.2a: prevouts_sig_digest (32-byte hash) - S.2b: sequence_sig_digest (32-byte hash) - S.2c: outputs_sig_digest (32-byte hash) - S.2d: txin_sig_digest (32-byte hash) + S.2a: prevouts_sig_digest (32-byte hash) + S.2b: amounts_sig_digest (32-byte hash) + S.2c: script_codes_sig_digest (32-byte hash) + S.2d: sequence_sig_digest (32-byte hash) + S.2e: outputs_sig_digest (32-byte hash) + S.2f: txin_sig_digest (32-byte hash) The personalization field of this hash is set to:: @@ -526,7 +528,37 @@ otherwise:: BLAKE2b-256(``ZTxIdPrevoutHash``, []) -S.2b: sequence_sig_digest +S.2b: amounts_sig_digest +'''''''''''''''''''''''' +If the ``SIGHASH_ANYONECANPAY`` flag is not set, the value of +``amounts_sig_digest`` is a BLAKE2b-256 hash of the concatenation of the 8-byte +signed little-endian representations of all ``value`` fields [#bdr-txout]_ for +the coins spent by the transparent inputs to the transaction. + +The personalization field of this hash is set to:: + + "ZTxTrAmountsHash" + +If the ``SIGHASH_ANYONECANPAY`` flag is set, ``amounts_sig_digest`` is:: + + BLAKE2b-256("ZTxTrAmountsHash", []) + +S.2c: script_codes_sig_digest +''''''''''''''''''''''''''''' +If the ``SIGHASH_ANYONECANPAY`` flag is not set, the value of +``script_codes_sig_digest`` is a BLAKE2b-256 hash of the concatenation of the +field encodings (including leading ``CompactSize``) of all ``pk_script`` fields +[#bdr-txout]_ for the coins spent by the transparent inputs to the transaction. + +The personalization field of this hash is set to:: + + "ZTxTrScriptsHash" + +If the ``SIGHASH_ANYONECANPAY`` flag is set, ``script_codes_sig_digest`` is:: + + BLAKE2b-256("ZTxTrScriptsHash", []) + +S.2d: sequence_sig_digest ''''''''''''''''''''''''' This is a BLAKE2b-256 hash initialized with the personalization field value ``ZTxIdSequencHash``. @@ -540,7 +572,7 @@ otherwise:: BLAKE2b-256(``ZTxIdSequencHash``, []) -S.2c: outputs_sig_digest +S.2e: outputs_sig_digest '''''''''''''''''''''''' This is a BLAKE2b-256 hash initialized with the personalization field value ``ZTxIdOutputsHash``. @@ -561,16 +593,16 @@ otherwise:: BLAKE2b-256(``ZTxIdOutputsHash``, []) -S.2d: txin_sig_digest +S.2f: txin_sig_digest ''''''''''''''''''''' This is a BLAKE2b-256 hash of the following properties of the transparent input being signed, initialized with the personalization field value ``Zcash___TxInHash`` (3 underscores):: - S.2d.i: prevout (field encoding) - S.2d.ii: script_code (field encoding) - S.2d.iii: value (8-byte signed little-endian) - S.2d.iv: nSequence (4-byte unsigned little-endian) + S.2f.i: prevout (field encoding) + S.2f.ii: script_code (field encoding) + S.2f.iii: value (8-byte signed little-endian) + S.2f.iv: nSequence (4-byte unsigned little-endian) Note: ``value`` is defined in the consensus rules to be a nonnegative value <= ``MAX_MONEY``, but all existing implementations parse this value as signed and @@ -742,6 +774,14 @@ Rationale Several changes in this ZIP (relative to ZIP 243 [#zip-0243]_) were made to align with BIP 341 [#bip-0341]_: +- Two new commitments (``amounts_sig_digest`` and ``script_codes_sig_digest``) + were added, to address difficulties in the case of a hardware wallet signing + transparent inputs. ``script_codes_sig_digest`` helps the hardware wallet to + determine the subset of inputs belonging to it [#bip-0341-scriptPubKey]_. + ``amounts_sig_digest`` prevents the transaction creator from lying to the + hardware wallet about the transaction fee [#bip-0341-amount]_. Without these + commitments, the hardware wallet would need to be sent every transaction + containing an outpoint referenced in the transaction being signed. - The semantics of ``sequence_sig_digest`` were changed, to commit to ``nSequence`` even if ``SIGHASH_SINGLE`` or ``SIGHASH_NONE`` is set. The rationale for this change is inherited from BIP 341 [#bip-0341-nSequence]_. @@ -765,4 +805,7 @@ References .. [#zip-0243] `ZIP 243: Transaction Signature Validation for Sapling `_ .. [#zip-0307] `ZIP 307: Light Client Protocol for Payment Detection `_ .. [#bip-0341] `BIP 341: Taproot: SegWit version 1 spending rules `_ +.. [#bip-0341-scriptPubKey] `Why does the signature message commit to the scriptPubKey? `_ +.. [#bip-0341-amount] `Why does the signature message commit to the amounts of all transaction inputs? `_ .. [#bip-0341-nSequence] `Why does the signature message commit to all input nSequence if SIGHASH_SINGLE or SIGHASH_NONE are set? `_ +.. [#bdr-txout] `Bitcoin Developer Reference. TxOut: A Transaction Output `_ \ No newline at end of file From c2585a4fc94329f1366b4d666af5a91380201b74 Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Mon, 3 Jan 2022 23:49:04 +0000 Subject: [PATCH 03/13] ZIP 244: Extend S.2 to be used for shielded signatures Co-authored-by: Daira Hopwood --- zip-0244.rst | 36 ++++++++++++++++++++++++++++-------- 1 file changed, 28 insertions(+), 8 deletions(-) diff --git a/zip-0244.rst b/zip-0244.rst index 9a3e04ca0..ad33860ea 100644 --- a/zip-0244.rst +++ b/zip-0244.rst @@ -490,11 +490,7 @@ Identical to that specified for the transaction identifier. S.2: transparent_sig_digest ``````````````````````````` -If we are producing a hash for the signature over a Sapling Spend or an Orchard Action, -the value of ``transparent_sig_digest`` is identical to the value specified in section -`T.2 <#t-2-transparent-digest>`_. - -If we are producing a hash for signature over a transparent input, the value of +In the case that transparent inputs or outputs are present, the value of ``transparent_sig_digest`` depends upon the value of a ``hash_type`` flag as in ZIP 143 [#zip-0143]_. @@ -514,6 +510,11 @@ The personalization field of this hash is set to:: "ZTxIdTranspaHash" +In the case that the transaction has no transparent components, +``transparent_sig_digest`` is :: + + BLAKE2b-256("ZTxIdTranspaHash", []) + S.2a: prevouts_sig_digest ''''''''''''''''''''''''' This is a BLAKE2b-256 hash initialized with the personalization field value @@ -595,9 +596,10 @@ otherwise:: S.2f: txin_sig_digest ''''''''''''''''''''' -This is a BLAKE2b-256 hash of the following properties of the transparent input being -signed, initialized with the personalization field value ``Zcash___TxInHash`` (3 -underscores):: +If we are producing a hash for the signature over a transparent input, the value +of ``txin_sig_digest`` is a BLAKE2b-256 hash of the following properties of the +transparent input being signed, initialized with the personalization field value +``Zcash___TxInHash`` (3 underscores):: S.2f.i: prevout (field encoding) S.2f.ii: script_code (field encoding) @@ -609,6 +611,11 @@ Note: ``value`` is defined in the consensus rules to be a nonnegative value <= enforce the nonnegative constraint as a consensus check. It is defined as signed here for consistency with those existing implementations. +If we are producing a hash for the signature over a Sapling Spend or an Orchard +Action, ``txin_sig_digest`` is:: + + BLAKE2b-256("Zcash___TxInHash", []) + S.3: sapling_digest ``````````````````` Identical to that specified for the transaction identifier. @@ -771,6 +778,12 @@ The block header byte format and version are not altered by this ZIP. Rationale ========= +In S.2, we use the same personalization strings for fields that have matching +fields in T.2, in order to facilitate reuse of their digests. In particular, the +"no transparent inputs or outputs" case of S.2 is identical to the equivalent +case in T.2; thus for purely-shielded transactions, ``signature_digest`` is +equal to ``txid_digest``. + Several changes in this ZIP (relative to ZIP 243 [#zip-0243]_) were made to align with BIP 341 [#bip-0341]_: @@ -786,6 +799,13 @@ align with BIP 341 [#bip-0341]_: even if ``SIGHASH_SINGLE`` or ``SIGHASH_NONE`` is set. The rationale for this change is inherited from BIP 341 [#bip-0341-nSequence]_. +Signatures over Sapling Spends or Orchard Actions commit to the same data as for +transparent inputs, in order to ensure that they commit to all transparent input +values. Without this commitment, there is a similar difficulty in the case where +a hardware wallet is only signing shielded inputs, in a transaction that also +contains transparent inputs from a malicious other party (where that party lies +about their coins' values). + ======================== Reference implementation ======================== From 89f46c2d99199525d2ee272b3328dc615e5c6c0d Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Tue, 4 Jan 2022 00:20:49 +0000 Subject: [PATCH 04/13] ZIP 244: Add hash_type to the S.2 digest input This was committed to by the ZIP 143 and ZIP 243 transaction digest algorithms, but had been accidentally omitted from ZIP 244. It is not a security issue because the encoding of each layer uses sentinel values, meaning we were indirectly committing to hash_type (unlike BIP 341, which conditionally omits commitments based on hash_type and therefore needs to directly commit to it). But not committing directly to hash_type would complicate security analysis of the digest, and including it keeps the transparent part of ZIP 244 closer to BIP 341. We additionally import two new consensus rules from BIP 341 that apply to hash_type. Co-authored-by: Daira Hopwood Co-authored-by: Kris Nuttycom --- zip-0244.rst | 66 +++++++++++++++++++++++++++++++++++++--------------- 1 file changed, 47 insertions(+), 19 deletions(-) diff --git a/zip-0244.rst b/zip-0244.rst index ad33860ea..e5fda9d71 100644 --- a/zip-0244.rst +++ b/zip-0244.rst @@ -491,20 +491,20 @@ Identical to that specified for the transaction identifier. S.2: transparent_sig_digest ``````````````````````````` In the case that transparent inputs or outputs are present, the value of -``transparent_sig_digest`` depends upon the value of a ``hash_type`` flag as in ZIP 143 -[#zip-0143]_. +``transparent_sig_digest`` depends upon the value of a ``hash_type`` flag. The construction of each component below depends upon the values of the -``hash_type`` flag bits. Each component will be described separately +``hash_type`` flag bits. Each component will be described separately. This digest is a BLAKE2b-256 hash of the following values :: - S.2a: prevouts_sig_digest (32-byte hash) - S.2b: amounts_sig_digest (32-byte hash) - S.2c: script_codes_sig_digest (32-byte hash) - S.2d: sequence_sig_digest (32-byte hash) - S.2e: outputs_sig_digest (32-byte hash) - S.2f: txin_sig_digest (32-byte hash) + S.2a: hash_type (1 byte) + S.2b: prevouts_sig_digest (32-byte hash) + S.2c: amounts_sig_digest (32-byte hash) + S.2d: script_codes_sig_digest (32-byte hash) + S.2e: sequence_sig_digest (32-byte hash) + S.2f: outputs_sig_digest (32-byte hash) + S.2g: txin_sig_digest (32-byte hash) The personalization field of this hash is set to:: @@ -515,7 +515,22 @@ In the case that the transaction has no transparent components, BLAKE2b-256("ZTxIdTranspaHash", []) -S.2a: prevouts_sig_digest +S.2a: hash_type +''''''''''''''' +This is an 8-bit unsigned value. The ``SIGHASH`` encodings from the legacy +script system are reused: one of ``SIGHASH_ALL``, ``SIGHASH_NONE``, and +``SIGHASH_SINGLE``, with or without the ``SIGHASH_ANYONECANPAY`` flag. The +following restrictions apply, which cause validation failure if violated: + +- Using any undefined ``hash_type`` (not 0x01, 0x02, 0x03, 0x81, 0x82, or 0x83). +- Using ``SIGHASH_SINGLE`` without a "corresponding output" (an output with the + same index as the input being verified). + +If we are producing a hash for the signature over a Sapling Spend or an Orchard +Action, ``hash_type`` is set to ``SIGHASH_ALL``, and is not encoded anywhere in +the transaction's authorizing data. + +S.2b: prevouts_sig_digest ''''''''''''''''''''''''' This is a BLAKE2b-256 hash initialized with the personalization field value ``ZTxIdPrevoutHash``. @@ -529,7 +544,7 @@ otherwise:: BLAKE2b-256(``ZTxIdPrevoutHash``, []) -S.2b: amounts_sig_digest +S.2c: amounts_sig_digest '''''''''''''''''''''''' If the ``SIGHASH_ANYONECANPAY`` flag is not set, the value of ``amounts_sig_digest`` is a BLAKE2b-256 hash of the concatenation of the 8-byte @@ -544,7 +559,7 @@ If the ``SIGHASH_ANYONECANPAY`` flag is set, ``amounts_sig_digest`` is:: BLAKE2b-256("ZTxTrAmountsHash", []) -S.2c: script_codes_sig_digest +S.2d: script_codes_sig_digest ''''''''''''''''''''''''''''' If the ``SIGHASH_ANYONECANPAY`` flag is not set, the value of ``script_codes_sig_digest`` is a BLAKE2b-256 hash of the concatenation of the @@ -559,7 +574,7 @@ If the ``SIGHASH_ANYONECANPAY`` flag is set, ``script_codes_sig_digest`` is:: BLAKE2b-256("ZTxTrScriptsHash", []) -S.2d: sequence_sig_digest +S.2e: sequence_sig_digest ''''''''''''''''''''''''' This is a BLAKE2b-256 hash initialized with the personalization field value ``ZTxIdSequencHash``. @@ -573,7 +588,7 @@ otherwise:: BLAKE2b-256(``ZTxIdSequencHash``, []) -S.2e: outputs_sig_digest +S.2f: outputs_sig_digest '''''''''''''''''''''''' This is a BLAKE2b-256 hash initialized with the personalization field value ``ZTxIdOutputsHash``. @@ -594,17 +609,17 @@ otherwise:: BLAKE2b-256(``ZTxIdOutputsHash``, []) -S.2f: txin_sig_digest +S.2g: txin_sig_digest ''''''''''''''''''''' If we are producing a hash for the signature over a transparent input, the value of ``txin_sig_digest`` is a BLAKE2b-256 hash of the following properties of the transparent input being signed, initialized with the personalization field value ``Zcash___TxInHash`` (3 underscores):: - S.2f.i: prevout (field encoding) - S.2f.ii: script_code (field encoding) - S.2f.iii: value (8-byte signed little-endian) - S.2f.iv: nSequence (4-byte unsigned little-endian) + S.2g.i: prevout (field encoding) + S.2g.ii: script_code (field encoding) + S.2g.iii: value (8-byte signed little-endian) + S.2g.iv: nSequence (4-byte unsigned little-endian) Note: ``value`` is defined in the consensus rules to be a nonnegative value <= ``MAX_MONEY``, but all existing implementations parse this value as signed and @@ -787,6 +802,13 @@ equal to ``txid_digest``. Several changes in this ZIP (relative to ZIP 243 [#zip-0243]_) were made to align with BIP 341 [#bip-0341]_: +- The ``hash_type`` field is now restricted via a new consensus rule to be one + of a specific set of sighash type encodings. The rationale for this change is + inherited from BIP 341 [#bip-0341-hash_type]_. + + - Note however that we do not define ``SIGHASH_DEFAULT``, as it is equivalent + to ``SIGHASH_ALL``, and we prefer the encodings to be canonical. + - Two new commitments (``amounts_sig_digest`` and ``script_codes_sig_digest``) were added, to address difficulties in the case of a hardware wallet signing transparent inputs. ``script_codes_sig_digest`` helps the hardware wallet to @@ -798,6 +820,11 @@ align with BIP 341 [#bip-0341]_: - The semantics of ``sequence_sig_digest`` were changed, to commit to ``nSequence`` even if ``SIGHASH_SINGLE`` or ``SIGHASH_NONE`` is set. The rationale for this change is inherited from BIP 341 [#bip-0341-nSequence]_. +- The semantics of ``outputs_sig_digest`` were changed, via a new consensus rule + that rejects transparent inputs for which ``SIGHASH_SINGLE`` is set without a + corresponding transparent output at the same index. BIP 341 does not give a + rationale for this change, but without it these inputs were effectively using + ``SIGHASH_NONE``, which is silently misleading. Signatures over Sapling Spends or Orchard Actions commit to the same data as for transparent inputs, in order to ensure that they commit to all transparent input @@ -825,6 +852,7 @@ References .. [#zip-0243] `ZIP 243: Transaction Signature Validation for Sapling `_ .. [#zip-0307] `ZIP 307: Light Client Protocol for Payment Detection `_ .. [#bip-0341] `BIP 341: Taproot: SegWit version 1 spending rules `_ +.. [#bip-0341-hash_type] `Why reject unknown hash_type values? `_ .. [#bip-0341-scriptPubKey] `Why does the signature message commit to the scriptPubKey? `_ .. [#bip-0341-amount] `Why does the signature message commit to the amounts of all transaction inputs? `_ .. [#bip-0341-nSequence] `Why does the signature message commit to all input nSequence if SIGHASH_SINGLE or SIGHASH_NONE are set? `_ From 68b6147c02bc5412948b9411cb38e0ab4d5f5ffc Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Tue, 4 Jan 2022 00:52:07 +0000 Subject: [PATCH 05/13] ZIP 244: Reverse order of value and script_code in txin_sig_digest This matches the order in which they are committed to in BIP 341 (and also at the transaction level in S.2). --- zip-0244.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/zip-0244.rst b/zip-0244.rst index e5fda9d71..59612be3a 100644 --- a/zip-0244.rst +++ b/zip-0244.rst @@ -617,8 +617,8 @@ transparent input being signed, initialized with the personalization field value ``Zcash___TxInHash`` (3 underscores):: S.2g.i: prevout (field encoding) - S.2g.ii: script_code (field encoding) - S.2g.iii: value (8-byte signed little-endian) + S.2g.ii: value (8-byte signed little-endian) + S.2g.iii: script_code (field encoding) S.2g.iv: nSequence (4-byte unsigned little-endian) Note: ``value`` is defined in the consensus rules to be a nonnegative value <= From 2671741042bd2d2fca57ffa0db267385d9de729a Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Tue, 4 Jan 2022 00:54:16 +0000 Subject: [PATCH 06/13] ZIP 244: Regenerate HTML --- zip-0244.html | 127 +++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 109 insertions(+), 18 deletions(-) diff --git a/zip-0244.html b/zip-0244.html index c0c297b99..90d82ee29 100644 --- a/zip-0244.html +++ b/zip-0244.html @@ -254,17 +254,29 @@

Identical to that specified for the transaction identifier.

S.2: transparent_sig_digest
-

If we are producing a hash for the signature over a Sapling Spend or an Orchard Action, the value of transparent_sig_digest is identical to the value specified in section T.2.

-

If we are producing a hash for signature over a transparent input, the value of transparent_sig_digest depends upon the value of a hash_type flag as in ZIP 143 6.

-

The construction of each component below depends upon the values of the hash_type flag bits. Each component will be described separately

+

In the case that transparent inputs or outputs are present, the value of transparent_sig_digest depends upon the value of a hash_type flag.

+

The construction of each component below depends upon the values of the hash_type flag bits. Each component will be described separately.

This digest is a BLAKE2b-256 hash of the following values

- 
S.2a: prevouts_sig_digest (32-byte hash)
-S.2b: sequence_sig_digest (32-byte hash)
-S.2c: outputs_sig_digest  (32-byte hash)
-S.2d: txin_sig_digest     (32-byte hash)
+ 
S.2a: hash_type               (1 byte)
+S.2b: prevouts_sig_digest     (32-byte hash)
+S.2c: amounts_sig_digest      (32-byte hash)
+S.2d: script_codes_sig_digest (32-byte hash)
+S.2e: sequence_sig_digest     (32-byte hash)
+S.2f: outputs_sig_digest      (32-byte hash)
+S.2g: txin_sig_digest         (32-byte hash)

The personalization field of this hash is set to:

"ZTxIdTranspaHash"
-
S.2a: prevouts_sig_digest +

In the case that the transaction has no transparent components, transparent_sig_digest is

+ 
BLAKE2b-256("ZTxIdTranspaHash", [])
+
S.2a: hash_type +

This is an 8-bit unsigned value. The SIGHASH encodings from the legacy script system are reused: one of SIGHASH_ALL, SIGHASH_NONE, and SIGHASH_SINGLE, with or without the SIGHASH_ANYONECANPAY flag. The following restrictions apply, which cause validation failure if violated:

+
    +
  • Using any undefined hash_type (not 0x01, 0x02, 0x03, 0x81, 0x82, or 0x83).
    • +
  • Using SIGHASH_SINGLE without a "corresponding output" (an output with the same index as the input being verified).
    • +
+

If we are producing a hash for the signature over a Sapling Spend or an Orchard Action, hash_type is set to SIGHASH_ALL, and is not encoded anywhere in the transaction's authorizing data.

+
+
S.2b: prevouts_sig_digest

This is a BLAKE2b-256 hash initialized with the personalization field value ZTxIdPrevoutHash.

If the SIGHASH_ANYONECANPAY flag is not set:

identical to the value of ``prevouts_digest`` as specified for the
@@ -272,15 +284,29 @@
                                 
otherwise:

                                 
BLAKE2b-256(``ZTxIdPrevoutHash``, [])
-
S.2b: sequence_sig_digest +
S.2c: amounts_sig_digest +

If the SIGHASH_ANYONECANPAY flag is not set, the value of amounts_sig_digest is a BLAKE2b-256 hash of the concatenation of the 8-byte signed little-endian representations of all value fields 14 for the coins spent by the transparent inputs to the transaction.

+

The personalization field of this hash is set to:

+ 
"ZTxTrAmountsHash"
+

If the SIGHASH_ANYONECANPAY flag is set, amounts_sig_digest is:

+ 
BLAKE2b-256("ZTxTrAmountsHash", [])
+
+
S.2d: script_codes_sig_digest +

If the SIGHASH_ANYONECANPAY flag is not set, the value of script_codes_sig_digest is a BLAKE2b-256 hash of the concatenation of the field encodings (including leading CompactSize) of all pk_script fields 14 for the coins spent by the transparent inputs to the transaction.

+

The personalization field of this hash is set to:

+ 
"ZTxTrScriptsHash"
+

If the SIGHASH_ANYONECANPAY flag is set, script_codes_sig_digest is:

+ 
BLAKE2b-256("ZTxTrScriptsHash", [])
+
+
S.2e: sequence_sig_digest

This is a BLAKE2b-256 hash initialized with the personalization field value ZTxIdSequencHash.

-

If the SIGHASH_ANYONECANPAY flag is not set, and the sighash type is neither SIGHASH_SINGLE nor SIGHASH_NONE:

+

If the SIGHASH_ANYONECANPAY flag is not set:

identical to the value of ``sequence_digest`` as specified for the
 transaction identifier in section T.2b.

otherwise:

BLAKE2b-256(``ZTxIdSequencHash``, [])
-
S.2c: outputs_sig_digest +
S.2f: outputs_sig_digest

This is a BLAKE2b-256 hash initialized with the personalization field value ZTxIdOutputsHash.

If the sighash type is neither SIGHASH_SINGLE nor SIGHASH_NONE:

identical to the value of ``outputs_digest`` as specified for the
@@ -291,13 +317,15 @@
                                 
otherwise:

                                 
BLAKE2b-256(``ZTxIdOutputsHash``, [])
-
S.2d: txin_sig_digest -

This is a BLAKE2b-256 hash of the following properties of the transparent input being signed, initialized with the personalization field value Zcash___TxInHash (3 underscores):

- 
S.2d.i:   prevout     (field encoding)
-S.2d.ii:  script_code (field encoding)
-S.2d.iii: value       (8-byte signed little-endian)
-S.2d.iv:  nSequence   (4-byte unsigned little-endian)
+
S.2g: txin_sig_digest +

If we are producing a hash for the signature over a transparent input, the value of txin_sig_digest is a BLAKE2b-256 hash of the following properties of the transparent input being signed, initialized with the personalization field value Zcash___TxInHash (3 underscores):

+ 
S.2g.i:   prevout     (field encoding)
+S.2g.ii:  value       (8-byte signed little-endian)
+S.2g.iii: script_code (field encoding)
+S.2g.iv:  nSequence   (4-byte unsigned little-endian)

Note: value is defined in the consensus rules to be a nonnegative value <= MAX_MONEY, but all existing implementations parse this value as signed and enforce the nonnegative constraint as a consensus check. It is defined as signed here for consistency with those existing implementations.

+

If we are producing a hash for the signature over a Sapling Spend or an Orchard Action, txin_sig_digest is:

+ 
BLAKE2b-256("Zcash___TxInHash", [])
S.3: sapling_digest
@@ -366,7 +394,7 @@ is well-defined because \(\mathsf{tx\_count} > 0\) , due to the coinbase transaction in each block. Non-leaf hashes in this tree are BLAKE2b-256 hashes personalized by the string "ZcashAuthDatHash".

-

Changing the block header format to allow space for an additional commitment is somewhat invasive. Instead, the name and meaning of the hashLightClientRoot field, described in ZIP 221 4, is changed.

+

Changing the block header format to allow space for an additional commitment is somewhat invasive. Instead, the name and meaning of the hashLightClientRoot field, described in ZIP 221 4, is changed.

hashLightClientRoot is renamed to hashBlockCommitments. The value of this hash is the BLAKE2b-256 hash personalized by the string "ZcashBlockCommit" of the following elements:

hashLightClientRoot (as described in ZIP 221)
 hashAuthDataRoot    (as described below)
@@ -377,6 +405,21 @@
                 
The block header byte format and version are not altered by this ZIP.
+

Rationale

+

In S.2, we use the same personalization strings for fields that have matching fields in T.2, in order to facilitate reuse of their digests. In particular, the "no transparent inputs or outputs" case of S.2 is identical to the equivalent case in T.2; thus for purely-shielded transactions, signature_digest is equal to txid_digest.

+

Several changes in this ZIP (relative to ZIP 243 7) were made to align with BIP 341 9:

+
    +
  • The hash_type field is now restricted via a new consensus rule to be one of a specific set of sighash type encodings. The rationale for this change is inherited from BIP 341 10. +
      +
    • Note however that we do not define SIGHASH_DEFAULT, as it is equivalent to SIGHASH_ALL, and we prefer the encodings to be canonical.
      • +
    +
    • +
  • Two new commitments (amounts_sig_digest and script_codes_sig_digest) were added, to address difficulties in the case of a hardware wallet signing transparent inputs. script_codes_sig_digest helps the hardware wallet to determine the subset of inputs belonging to it 11. amounts_sig_digest prevents the transaction creator from lying to the hardware wallet about the transaction fee 12. Without these commitments, the hardware wallet would need to be sent every transaction containing an outpoint referenced in the transaction being signed.
    • +
  • The semantics of sequence_sig_digest were changed, to commit to nSequence even if SIGHASH_SINGLE or SIGHASH_NONE is set. The rationale for this change is inherited from BIP 341 13.
    • +
  • The semantics of outputs_sig_digest were changed, via a new consensus rule that rejects transparent inputs for which SIGHASH_SINGLE is set without a corresponding transparent output at the same index. BIP 341 does not give a rationale for this change, but without it these inputs were effectively using SIGHASH_NONE, which is silently misleading.
    • +
+

Signatures over Sapling Spends or Orchard Actions commit to the same data as for transparent inputs, in order to ensure that they commit to all transparent input values. Without this commitment, there is a similar difficulty in the case where a hardware wallet is only signing shielded inputs, in a transaction that also contains transparent inputs from a malicious other party (where that party lies about their coins' values).

+

Reference implementation

From bdfe15bb3f636fcacfca6a3d42b58704ff306ff1 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Wed, 5 Jan 2022 17:35:20 +0000 Subject: [PATCH 07/13] Apply suggestions from code review Co-authored-by: Kris Nuttycombe --- zip-0244.html | 8 ++++---- zip-0244.rst | 16 +++++++++------- 2 files changed, 13 insertions(+), 11 deletions(-) diff --git a/zip-0244.html b/zip-0244.html index 90d82ee29..e5f65cf05 100644 --- a/zip-0244.html +++ b/zip-0244.html @@ -266,10 +266,10 @@ S.2g: txin_sig_digest (32-byte hash)

The personalization field of this hash is set to:

"ZTxIdTranspaHash"
-

In the case that the transaction has no transparent components, transparent_sig_digest is

+

In the case that the transaction has no transparent inputs or outputs, transparent_sig_digest is

BLAKE2b-256("ZTxIdTranspaHash", [])
S.2a: hash_type -

This is an 8-bit unsigned value. The SIGHASH encodings from the legacy script system are reused: one of SIGHASH_ALL, SIGHASH_NONE, and SIGHASH_SINGLE, with or without the SIGHASH_ANYONECANPAY flag. The following restrictions apply, which cause validation failure if violated:

+

This is an 8-bit unsigned value. The SIGHASH encodings from the legacy script system are reused: one of SIGHASH_ALL (0x01), SIGHASH_NONE (0x02), and SIGHASH_SINGLE (0x03), with or without the SIGHASH_ANYONECANPAY flag (0x80). The following restrictions apply, which cause validation failure if violated:

  • Using any undefined hash_type (not 0x01, 0x02, 0x03, 0x81, 0x82, or 0x83).
  • Using SIGHASH_SINGLE without a "corresponding output" (an output with the same index as the input being verified).
    • @@ -292,7 +292,7 @@ 
    BLAKE2b-256("ZTxTrAmountsHash", [])
S.2d: script_codes_sig_digest -

If the SIGHASH_ANYONECANPAY flag is not set, the value of script_codes_sig_digest is a BLAKE2b-256 hash of the concatenation of the field encodings (including leading CompactSize) of all pk_script fields 14 for the coins spent by the transparent inputs to the transaction.

+

If the SIGHASH_ANYONECANPAY flag is not set, the value of script_codes_sig_digest is a BLAKE2b-256 hash of the concatenation of the field encodings (each including a leading CompactSize) of all pk_script fields 14 for the coins spent by the transparent inputs to the transaction.

The personalization field of this hash is set to:

"ZTxTrScriptsHash"

If the SIGHASH_ANYONECANPAY flag is set, script_codes_sig_digest is:

@@ -406,7 +406,7 @@

Rationale

-

In S.2, we use the same personalization strings for fields that have matching fields in T.2, in order to facilitate reuse of their digests. In particular, the "no transparent inputs or outputs" case of S.2 is identical to the equivalent case in T.2; thus for purely-shielded transactions, signature_digest is equal to txid_digest.

+

In S.2, we use the same personalization strings for fields that have matching fields in T.2, in order to facilitate reuse of their digests. In particular, the "no transparent inputs or outputs" case of S.2 is identical to the equivalent case in T.2; thus for fully shielded transactions, signature_digest is equal to txid_digest.

Several changes in this ZIP (relative to ZIP 243 7) were made to align with BIP 341 9:

  • The hash_type field is now restricted via a new consensus rule to be one of a specific set of sighash type encodings. The rationale for this change is inherited from BIP 341 10. diff --git a/zip-0244.rst b/zip-0244.rst index 59612be3a..9c050d22c 100644 --- a/zip-0244.rst +++ b/zip-0244.rst @@ -510,7 +510,7 @@ The personalization field of this hash is set to:: "ZTxIdTranspaHash" -In the case that the transaction has no transparent components, +In the case that the transaction has no transparent inputs or outputs, ``transparent_sig_digest`` is :: BLAKE2b-256("ZTxIdTranspaHash", []) @@ -518,9 +518,10 @@ In the case that the transaction has no transparent components, S.2a: hash_type ''''''''''''''' This is an 8-bit unsigned value. The ``SIGHASH`` encodings from the legacy -script system are reused: one of ``SIGHASH_ALL``, ``SIGHASH_NONE``, and -``SIGHASH_SINGLE``, with or without the ``SIGHASH_ANYONECANPAY`` flag. The -following restrictions apply, which cause validation failure if violated: +script system are reused: one of ``SIGHASH_ALL`` (0x01), ``SIGHASH_NONE`` (0x02), +and ``SIGHASH_SINGLE`` (0x03), with or without the ``SIGHASH_ANYONECANPAY`` flag +(0x80). The following restrictions apply, which cause validation failure if +violated: - Using any undefined ``hash_type`` (not 0x01, 0x02, 0x03, 0x81, 0x82, or 0x83). - Using ``SIGHASH_SINGLE`` without a "corresponding output" (an output with the @@ -563,8 +564,9 @@ S.2d: script_codes_sig_digest ''''''''''''''''''''''''''''' If the ``SIGHASH_ANYONECANPAY`` flag is not set, the value of ``script_codes_sig_digest`` is a BLAKE2b-256 hash of the concatenation of the -field encodings (including leading ``CompactSize``) of all ``pk_script`` fields -[#bdr-txout]_ for the coins spent by the transparent inputs to the transaction. +field encodings (each including a leading ``CompactSize``) of all ``pk_script`` +fields [#bdr-txout]_ for the coins spent by the transparent inputs to the +transaction. The personalization field of this hash is set to:: @@ -796,7 +798,7 @@ Rationale In S.2, we use the same personalization strings for fields that have matching fields in T.2, in order to facilitate reuse of their digests. In particular, the "no transparent inputs or outputs" case of S.2 is identical to the equivalent -case in T.2; thus for purely-shielded transactions, ``signature_digest`` is +case in T.2; thus for fully shielded transactions, ``signature_digest`` is equal to ``txid_digest``. Several changes in this ZIP (relative to ZIP 243 [#zip-0243]_) were made to From a3a86b4a44b7f7af160524902987fbcb7cad7497 Mon Sep 17 00:00:00 2001 From: Deirdre Connolly Date: Thu, 6 Jan 2022 13:54:49 -0500 Subject: [PATCH 08/13] Update zip-0244.rst Co-authored-by: str4d --- zip-0244.rst | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/zip-0244.rst b/zip-0244.rst index 9c050d22c..3c344edc8 100644 --- a/zip-0244.rst +++ b/zip-0244.rst @@ -527,9 +527,10 @@ violated: - Using ``SIGHASH_SINGLE`` without a "corresponding output" (an output with the same index as the input being verified). -If we are producing a hash for the signature over a Sapling Spend or an Orchard -Action, ``hash_type`` is set to ``SIGHASH_ALL``, and is not encoded anywhere in -the transaction's authorizing data. +If we are producing a hash for the signature over a transparent input, the value +of ``hash_type`` is obtained from the input's ``scriptSig`` as encoded in the +transaction. If we are producing a hash for the signature over a Sapling Spend +or an Orchard Action, ``hash_type`` is set to ``SIGHASH_ALL``. S.2b: prevouts_sig_digest ''''''''''''''''''''''''' From 30ff9f6ddbe03c0240e577ad720cbad119c83e29 Mon Sep 17 00:00:00 2001 From: Kris Nuttycombe Date: Fri, 7 Jan 2022 16:46:10 -0700 Subject: [PATCH 09/13] Regenerate HTML --- zip-0244.html | 40 ++++++++++++++++++++-------------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/zip-0244.html b/zip-0244.html index e5f65cf05..290737d00 100644 --- a/zip-0244.html +++ b/zip-0244.html @@ -18,9 +18,9 @@ License: MIT Discussions-To: <https://github.com/zcash/zips/issues/411>

    Terminology

    -

    The key words "MUST" and "MUST NOT" in this document are to be interpreted as described in RFC 2119. 1

    -

    The terms "consensus branch", "epoch", and "network upgrade" in this document are to be interpreted as described in ZIP 200. 3

    -

    The term "field encoding" refers to the binary serialized form of a Zcash transaction field, as specified in section 7.1 of the Zcash protocol specification 2.

    +

    The key words "MUST" and "MUST NOT" in this document are to be interpreted as described in RFC 2119. 1

    +

    The terms "consensus branch", "epoch", and "network upgrade" in this document are to be interpreted as described in ZIP 200. 3

    +

    The term "field encoding" refers to the binary serialized form of a Zcash transaction field, as specified in section 7.1 of the Zcash protocol specification 2.

    Abstract

    This proposal defines a new transaction digest algorithm for the NU5 network upgrade onward, in order to introduce non-malleable transaction identifiers that commit to all transaction data except for attestations to transaction validity.

    @@ -75,7 +75,7 @@    ├── valueBalanceOrchard    └── anchorOrchard

    Each node written as snake_case in this tree is a BLAKE2b-256 hash of its children, initialized with a personalization string specific to that branch of the tree. Nodes that are not themselves digests are written in camelCase. In the specification below, nodes of the tree are presented in depth-first order.

    -
    txid_digest
    +
    txid_digest

    A BLAKE2b-256 hash of the following values

    T.1: header_digest       (32-byte hash output)
 T.2: transparent_digest  (32-byte hash output)
@@ -84,7 +84,7 @@
                         
    The personalization field of this hash is set to:
    
                         
    "ZcashTxHash_" || CONSENSUS_BRANCH_ID
    
                         
    ZcashTxHash_ has 1 underscore character.
    
-                        
    As in ZIP 143 6, CONSENSUS_BRANCH_ID is the 4-byte little-endian encoding of the consensus branch ID for the epoch of the block containing the transaction. Domain separation of the transaction id hash across parallel consensus branches provides replay protection: transactions targeted for one consensus branch will not have the same transaction identifier on other consensus branches.
    
+                        
    As in ZIP 143 6, CONSENSUS_BRANCH_ID is the 4-byte little-endian encoding of the consensus branch ID for the epoch of the block containing the transaction. Domain separation of the transaction id hash across parallel consensus branches provides replay protection: transactions targeted for one consensus branch will not have the same transaction identifier on other consensus branches.
    
                         
    This signature hash personalization prefix has been changed to reflect the new role of this hash (relative to ZcashSigHash as specified in ZIP 143) as a transaction identifier rather than a commitment that is exclusively used for signature purposes. The previous computation of the transaction identifier was a SHA256d hash of the serialized transaction contents, and was not personalized.
    
                         
    T.1: header_digest 
    
                             
    A BLAKE2b-256 hash of the following values
    
@@ -128,7 +128,7 @@
    T.3: sapling_digest
    -

    In the case that Sapling spends or outputs are present, the digest of Sapling components is composed of two subtrees which are organized to permit easy interoperability with the CompactBlock representation of Sapling data specified by the ZIP 307 Light Client Protocol 8.

    +

    In the case that Sapling spends or outputs are present, the digest of Sapling components is composed of two subtrees which are organized to permit easy interoperability with the CompactBlock representation of Sapling data specified by the ZIP 307 Light Client Protocol 8.

    This digest is a BLAKE2b-256 hash of the following values

    T.3a: sapling_spends_digest  (32-byte hash)
 T.3b: sapling_outputs_digest (32-byte hash)
@@ -170,7 +170,7 @@
                                 
    In the case that the transaction has Sapling spends but no Sapling outputs, sapling_outputs_digest is
    
                                 
    BLAKE2b-256("ZTxIdSOutputHash", [])
    
                                 
    T.3b.i: sapling_outputs_compact_digest 
-                                    
    A BLAKE2b-256 hash of the subset of Sapling output information included in the ZIP-307 8 CompactBlock format for all Sapling shielded outputs belonging to the transaction. For each output, the following elements are included in the hash:
    
+                                    
    A BLAKE2b-256 hash of the subset of Sapling output information included in the ZIP-307 8 CompactBlock format for all Sapling shielded outputs belonging to the transaction. For each output, the following elements are included in the hash:
    
                                     
    T.3b.i.1: cmu                  (field encoding bytes)
 T.3b.i.2: ephemeral_key        (field encoding bytes)
 T.3b.i.3: enc_ciphertext[..52] (First 52 bytes of field encoding)
    
@@ -184,7 +184,7 @@
                                     
    "ZTxIdSOutM__Hash" (2 underscore characters)
    
                                 
    
                                 
    T.3b.iii: sapling_outputs_noncompact_digest 
-                                    
    A BLAKE2b-256 hash of the remaining subset of Sapling output information not included in the ZIP 307 8 CompactBlock format, excluding zkproof data, for all Sapling shielded outputs belonging to the transaction. For each output, the following elements are included in the hash:
    
+                                    
    A BLAKE2b-256 hash of the remaining subset of Sapling output information not included in the ZIP 307 8 CompactBlock format, excluding zkproof data, for all Sapling shielded outputs belonging to the transaction. For each output, the following elements are included in the hash:
    
                                     
    T.3b.iii.1: cv                    (field encoding bytes)
 T.3b.iii.2: enc_ciphertext[564..] (post-memo Poly1305 AEAD tag of field encoding)
 T.3b.iii.3: out_ciphertext        (field encoding bytes)
    
@@ -206,7 +206,7 @@
                             
    In the case that the transaction has no Orchard actions, orchard_digest is
    
                             
    BLAKE2b-256("ZTxIdOrchardHash", [])
    
                             
    T.4a: orchard_actions_compact_digest 
-                                
    A BLAKE2b-256 hash of the subset of Orchard Action information intended to be included in an updated version of the ZIP-307 8 CompactBlock format for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:
    
+                                
    A BLAKE2b-256 hash of the subset of Orchard Action information intended to be included in an updated version of the ZIP-307 8 CompactBlock format for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:
    
                                 
    T.4a.i  : nullifier            (field encoding bytes)
 T.4a.ii : cmx                  (field encoding bytes)
 T.4a.iii: ephemeralKey         (field encoding bytes)
@@ -221,7 +221,7 @@
                                 
    "ZTxIdOrcActMHash"
    
                             
    
                             
    T.4c: orchard_actions_noncompact_digest 
-                                
    A BLAKE2b-256 hash of the remaining subset of Orchard Action information not intended for inclusion in an updated version of the the ZIP 307 8 CompactBlock format, for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:
    
+                                
    A BLAKE2b-256 hash of the remaining subset of Orchard Action information not intended for inclusion in an updated version of the the ZIP 307 8 CompactBlock format, for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:
    
                                 
    T.4c.i  : cv                    (field encoding bytes)
 T.4c.ii : rk                    (field encoding bytes)
 T.4c.iii: encCiphertext[564..]  (post-memo suffix of field encoding)
@@ -233,14 +233,14 @@
                     
    
                 
    
                 
    Signature Digest 
    
-                    
    A new per-input transaction digest algorithm is defined that constructs a hash that may be signed by a transaction creator to commit to the effects of the transaction. A signature digest is produced for each transparent input, each Sapling input, and each Orchard action. For transparent inputs, this follows closely the algorithms from ZIP 143 6 and ZIP 243 7. For shielded inputs, this algorithm has the exact same output as the transaction digest algorithm, thus the txid may be signed directly.
    
+                    
    A new per-input transaction digest algorithm is defined that constructs a hash that may be signed by a transaction creator to commit to the effects of the transaction. A signature digest is produced for each transparent input, each Sapling input, and each Orchard action. For transparent inputs, this follows closely the algorithms from ZIP 143 6 and ZIP 243 7. For shielded inputs, this algorithm has the exact same output as the transaction digest algorithm, thus the txid may be signed directly.
    
                     
    The overall structure of the hash is as follows; each name referenced here will be described in detail below:
    
                     
    signature_digest
 ├── header_digest
 ├── transparent_sig_digest
 ├── sapling_digest
 └── orchard_digest
    
-                    
    signature_digest 
    
+                    
    signature_digest 
    
                         
    A BLAKE2b-256 hash of the following values
    
                         
    S.1: header_digest          (32-byte hash output)
 S.2: transparent_sig_digest (32-byte hash output)
@@ -274,7 +274,7 @@
                                     
  • Using any undefined hash_type (not 0x01, 0x02, 0x03, 0x81, 0x82, or 0x83).
    • 
                                     
  • Using SIGHASH_SINGLE without a "corresponding output" (an output with the same index as the input being verified).
    •
-

If we are producing a hash for the signature over a Sapling Spend or an Orchard Action, hash_type is set to SIGHASH_ALL, and is not encoded anywhere in the transaction's authorizing data.

+

If we are producing a hash for the signature over a transparent input, the value of hash_type is obtained from the input's scriptSig as encoded in the transaction. If we are producing a hash for the signature over a Sapling Spend or an Orchard Action, hash_type is set to SIGHASH_ALL.

S.2b: prevouts_sig_digest

This is a BLAKE2b-256 hash initialized with the personalization field value ZTxIdPrevoutHash.

@@ -285,14 +285,14 @@ 
BLAKE2b-256(``ZTxIdPrevoutHash``, [])
S.2c: amounts_sig_digest -

If the SIGHASH_ANYONECANPAY flag is not set, the value of amounts_sig_digest is a BLAKE2b-256 hash of the concatenation of the 8-byte signed little-endian representations of all value fields 14 for the coins spent by the transparent inputs to the transaction.

+

If the SIGHASH_ANYONECANPAY flag is not set, the value of amounts_sig_digest is a BLAKE2b-256 hash of the concatenation of the 8-byte signed little-endian representations of all value fields 14 for the coins spent by the transparent inputs to the transaction.

The personalization field of this hash is set to:

"ZTxTrAmountsHash"

If the SIGHASH_ANYONECANPAY flag is set, amounts_sig_digest is:

BLAKE2b-256("ZTxTrAmountsHash", [])
S.2d: script_codes_sig_digest -

If the SIGHASH_ANYONECANPAY flag is not set, the value of script_codes_sig_digest is a BLAKE2b-256 hash of the concatenation of the field encodings (each including a leading CompactSize) of all pk_script fields 14 for the coins spent by the transparent inputs to the transaction.

+

If the SIGHASH_ANYONECANPAY flag is not set, the value of script_codes_sig_digest is a BLAKE2b-256 hash of the concatenation of the field encodings (each including a leading CompactSize) of all pk_script fields 14 for the coins spent by the transparent inputs to the transaction.

The personalization field of this hash is set to:

"ZTxTrScriptsHash"

If the SIGHASH_ANYONECANPAY flag is set, script_codes_sig_digest is:

@@ -394,7 +394,7 @@ is well-defined because \(\mathsf{tx\_count} > 0\) , due to the coinbase transaction in each block. Non-leaf hashes in this tree are BLAKE2b-256 hashes personalized by the string "ZcashAuthDatHash".

-

Changing the block header format to allow space for an additional commitment is somewhat invasive. Instead, the name and meaning of the hashLightClientRoot field, described in ZIP 221 4, is changed.

+

Changing the block header format to allow space for an additional commitment is somewhat invasive. Instead, the name and meaning of the hashLightClientRoot field, described in ZIP 221 4, is changed.

hashLightClientRoot is renamed to hashBlockCommitments. The value of this hash is the BLAKE2b-256 hash personalized by the string "ZcashBlockCommit" of the following elements:

hashLightClientRoot (as described in ZIP 221)
 hashAuthDataRoot    (as described below)
@@ -407,15 +407,15 @@

Rationale

In S.2, we use the same personalization strings for fields that have matching fields in T.2, in order to facilitate reuse of their digests. In particular, the "no transparent inputs or outputs" case of S.2 is identical to the equivalent case in T.2; thus for fully shielded transactions, signature_digest is equal to txid_digest.

-

Several changes in this ZIP (relative to ZIP 243 7) were made to align with BIP 341 9:

+

Several changes in this ZIP (relative to ZIP 243 7) were made to align with BIP 341 9:

    -
  • The hash_type field is now restricted via a new consensus rule to be one of a specific set of sighash type encodings. The rationale for this change is inherited from BIP 341 10. +
  • The hash_type field is now restricted via a new consensus rule to be one of a specific set of sighash type encodings. The rationale for this change is inherited from BIP 341 10.
    • Note however that we do not define SIGHASH_DEFAULT, as it is equivalent to SIGHASH_ALL, and we prefer the encodings to be canonical.
    • -
  • Two new commitments (amounts_sig_digest and script_codes_sig_digest) were added, to address difficulties in the case of a hardware wallet signing transparent inputs. script_codes_sig_digest helps the hardware wallet to determine the subset of inputs belonging to it 11. amounts_sig_digest prevents the transaction creator from lying to the hardware wallet about the transaction fee 12. Without these commitments, the hardware wallet would need to be sent every transaction containing an outpoint referenced in the transaction being signed.
    • -
  • The semantics of sequence_sig_digest were changed, to commit to nSequence even if SIGHASH_SINGLE or SIGHASH_NONE is set. The rationale for this change is inherited from BIP 341 13.
    • +
  • Two new commitments (amounts_sig_digest and script_codes_sig_digest) were added, to address difficulties in the case of a hardware wallet signing transparent inputs. script_codes_sig_digest helps the hardware wallet to determine the subset of inputs belonging to it 11. amounts_sig_digest prevents the transaction creator from lying to the hardware wallet about the transaction fee 12. Without these commitments, the hardware wallet would need to be sent every transaction containing an outpoint referenced in the transaction being signed.
    • +
  • The semantics of sequence_sig_digest were changed, to commit to nSequence even if SIGHASH_SINGLE or SIGHASH_NONE is set. The rationale for this change is inherited from BIP 341 13.
  • The semantics of outputs_sig_digest were changed, via a new consensus rule that rejects transparent inputs for which SIGHASH_SINGLE is set without a corresponding transparent output at the same index. BIP 341 does not give a rationale for this change, but without it these inputs were effectively using SIGHASH_NONE, which is silently misleading.

Signatures over Sapling Spends or Orchard Actions commit to the same data as for transparent inputs, in order to ensure that they commit to all transparent input values. Without this commitment, there is a similar difficulty in the case where a hardware wallet is only signing shielded inputs, in a transaction that also contains transparent inputs from a malicious other party (where that party lies about their coins' values).

From 8e74c62a2104620c85ab9cbe7b70e78e071a4a91 Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Wed, 12 Jan 2022 15:58:51 +0000 Subject: [PATCH 10/13] ZIP 244: Fix numbering of BIP 341 references Co-authored-by: Kris Nuttycombe --- zip-0244.html | 8 ++++---- zip-0244.rst | 10 +++++----- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/zip-0244.html b/zip-0244.html index 53b19aa70..6752dba01 100644 --- a/zip-0244.html +++ b/zip-0244.html @@ -502,7 +502,7 @@ 10 - Why reject unknown hash_type values? + Why reject unknown hash_type values? @@ -510,7 +510,7 @@ 11 - Why does the signature message commit to the scriptPubKey? + Why does the signature message commit to the scriptPubKey? @@ -518,7 +518,7 @@ 12 - Why does the signature message commit to the amounts of all transaction inputs? + Why does the signature message commit to the amounts of all transaction inputs? @@ -526,7 +526,7 @@ 13 - Why does the signature message commit to all input nSequence if SIGHASH_SINGLE or SIGHASH_NONE are set? + Why does the signature message commit to all input nSequence if SIGHASH_SINGLE or SIGHASH_NONE are set? diff --git a/zip-0244.rst b/zip-0244.rst index 3c344edc8..9866b2fb8 100644 --- a/zip-0244.rst +++ b/zip-0244.rst @@ -855,8 +855,8 @@ References .. [#zip-0243] `ZIP 243: Transaction Signature Validation for Sapling `_ .. [#zip-0307] `ZIP 307: Light Client Protocol for Payment Detection `_ .. [#bip-0341] `BIP 341: Taproot: SegWit version 1 spending rules `_ -.. [#bip-0341-hash_type] `Why reject unknown hash_type values? `_ -.. [#bip-0341-scriptPubKey] `Why does the signature message commit to the scriptPubKey? `_ -.. [#bip-0341-amount] `Why does the signature message commit to the amounts of all transaction inputs? `_ -.. [#bip-0341-nSequence] `Why does the signature message commit to all input nSequence if SIGHASH_SINGLE or SIGHASH_NONE are set? `_ -.. [#bdr-txout] `Bitcoin Developer Reference. TxOut: A Transaction Output `_ \ No newline at end of file +.. [#bip-0341-hash_type] `Why reject unknown hash_type values? `_ +.. [#bip-0341-scriptPubKey] `Why does the signature message commit to the scriptPubKey? `_ +.. [#bip-0341-amount] `Why does the signature message commit to the amounts of all transaction inputs? `_ +.. [#bip-0341-nSequence] `Why does the signature message commit to all input nSequence if SIGHASH_SINGLE or SIGHASH_NONE are set? `_ +.. [#bdr-txout] `Bitcoin Developer Reference. TxOut: A Transaction Output `_ From 509b7a2b0c210270960ff65d679bd5d06cc9cfc3 Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Wed, 12 Jan 2022 16:00:23 +0000 Subject: [PATCH 11/13] ZIP 244: Rename script_codes_sig_digest to scriptpubkeys_sig_digest --- zip-0244.html | 22 +++++++++++----------- zip-0244.rst | 26 +++++++++++++------------- 2 files changed, 24 insertions(+), 24 deletions(-) diff --git a/zip-0244.html b/zip-0244.html index 6752dba01..08e4c46aa 100644 --- a/zip-0244.html +++ b/zip-0244.html @@ -257,13 +257,13 @@

In the case that transparent inputs or outputs are present, the value of transparent_sig_digest depends upon the value of a hash_type flag.

The construction of each component below depends upon the values of the hash_type flag bits. Each component will be described separately.

This digest is a BLAKE2b-256 hash of the following values

- 
S.2a: hash_type               (1 byte)
-S.2b: prevouts_sig_digest     (32-byte hash)
-S.2c: amounts_sig_digest      (32-byte hash)
-S.2d: script_codes_sig_digest (32-byte hash)
-S.2e: sequence_sig_digest     (32-byte hash)
-S.2f: outputs_sig_digest      (32-byte hash)
-S.2g: txin_sig_digest         (32-byte hash)
+ 
S.2a: hash_type                (1 byte)
+S.2b: prevouts_sig_digest      (32-byte hash)
+S.2c: amounts_sig_digest       (32-byte hash)
+S.2d: scriptpubkeys_sig_digest (32-byte hash)
+S.2e: sequence_sig_digest      (32-byte hash)
+S.2f: outputs_sig_digest       (32-byte hash)
+S.2g: txin_sig_digest          (32-byte hash)

The personalization field of this hash is set to:

"ZTxIdTranspaHash"

In the case that the transaction has no transparent inputs or outputs, transparent_sig_digest is

@@ -291,11 +291,11 @@

If the SIGHASH_ANYONECANPAY flag is set, amounts_sig_digest is:

BLAKE2b-256("ZTxTrAmountsHash", [])
-
S.2d: script_codes_sig_digest -

If the SIGHASH_ANYONECANPAY flag is not set, the value of script_codes_sig_digest is a BLAKE2b-256 hash of the concatenation of the field encodings (each including a leading CompactSize) of all pk_script fields 14 for the coins spent by the transparent inputs to the transaction.

+
S.2d: scriptpubkeys_sig_digest +

If the SIGHASH_ANYONECANPAY flag is not set, the value of scriptpubkeys_sig_digest is a BLAKE2b-256 hash of the concatenation of the field encodings (each including a leading CompactSize) of all pk_script fields 14 for the coins spent by the transparent inputs to the transaction.

The personalization field of this hash is set to:

"ZTxTrScriptsHash"
-

If the SIGHASH_ANYONECANPAY flag is set, script_codes_sig_digest is:

+

If the SIGHASH_ANYONECANPAY flag is set, scriptpubkeys_sig_digest is:

BLAKE2b-256("ZTxTrScriptsHash", [])
S.2e: sequence_sig_digest @@ -414,7 +414,7 @@
  • Note however that we do not define SIGHASH_DEFAULT, as it is equivalent to SIGHASH_ALL, and we prefer the encodings to be canonical.
    • -
  • Two new commitments (amounts_sig_digest and script_codes_sig_digest) were added, to address difficulties in the case of a hardware wallet signing transparent inputs. script_codes_sig_digest helps the hardware wallet to determine the subset of inputs belonging to it 11. amounts_sig_digest prevents the transaction creator from lying to the hardware wallet about the transaction fee 12. Without these commitments, the hardware wallet would need to be sent every transaction containing an outpoint referenced in the transaction being signed.
    • +
  • Two new commitments (amounts_sig_digest and scriptpubkeys_sig_digest) were added, to address difficulties in the case of a hardware wallet signing transparent inputs. scriptpubkeys_sig_digest helps the hardware wallet to determine the subset of inputs belonging to it 11. amounts_sig_digest prevents the transaction creator from lying to the hardware wallet about the transaction fee 12. Without these commitments, the hardware wallet would need to be sent every transaction containing an outpoint referenced in the transaction being signed.
  • The semantics of sequence_sig_digest were changed, to commit to nSequence even if SIGHASH_SINGLE or SIGHASH_NONE is set. The rationale for this change is inherited from BIP 341 13.
  • The semantics of outputs_sig_digest were changed, via a new consensus rule that rejects transparent inputs for which SIGHASH_SINGLE is set without a corresponding transparent output at the same index. BIP 341 does not give a rationale for this change, but without it these inputs were effectively using SIGHASH_NONE, which is silently misleading.
    • diff --git a/zip-0244.rst b/zip-0244.rst index 9866b2fb8..f1fc889e9 100644 --- a/zip-0244.rst +++ b/zip-0244.rst @@ -498,13 +498,13 @@ The construction of each component below depends upon the values of the This digest is a BLAKE2b-256 hash of the following values :: - S.2a: hash_type (1 byte) - S.2b: prevouts_sig_digest (32-byte hash) - S.2c: amounts_sig_digest (32-byte hash) - S.2d: script_codes_sig_digest (32-byte hash) - S.2e: sequence_sig_digest (32-byte hash) - S.2f: outputs_sig_digest (32-byte hash) - S.2g: txin_sig_digest (32-byte hash) + S.2a: hash_type (1 byte) + S.2b: prevouts_sig_digest (32-byte hash) + S.2c: amounts_sig_digest (32-byte hash) + S.2d: scriptpubkeys_sig_digest (32-byte hash) + S.2e: sequence_sig_digest (32-byte hash) + S.2f: outputs_sig_digest (32-byte hash) + S.2g: txin_sig_digest (32-byte hash) The personalization field of this hash is set to:: @@ -561,10 +561,10 @@ If the ``SIGHASH_ANYONECANPAY`` flag is set, ``amounts_sig_digest`` is:: BLAKE2b-256("ZTxTrAmountsHash", []) -S.2d: script_codes_sig_digest -''''''''''''''''''''''''''''' +S.2d: scriptpubkeys_sig_digest +'''''''''''''''''''''''''''''' If the ``SIGHASH_ANYONECANPAY`` flag is not set, the value of -``script_codes_sig_digest`` is a BLAKE2b-256 hash of the concatenation of the +``scriptpubkeys_sig_digest`` is a BLAKE2b-256 hash of the concatenation of the field encodings (each including a leading ``CompactSize``) of all ``pk_script`` fields [#bdr-txout]_ for the coins spent by the transparent inputs to the transaction. @@ -573,7 +573,7 @@ The personalization field of this hash is set to:: "ZTxTrScriptsHash" -If the ``SIGHASH_ANYONECANPAY`` flag is set, ``script_codes_sig_digest`` is:: +If the ``SIGHASH_ANYONECANPAY`` flag is set, ``scriptpubkeys_sig_digest`` is:: BLAKE2b-256("ZTxTrScriptsHash", []) @@ -812,9 +812,9 @@ align with BIP 341 [#bip-0341]_: - Note however that we do not define ``SIGHASH_DEFAULT``, as it is equivalent to ``SIGHASH_ALL``, and we prefer the encodings to be canonical. -- Two new commitments (``amounts_sig_digest`` and ``script_codes_sig_digest``) +- Two new commitments (``amounts_sig_digest`` and ``scriptpubkeys_sig_digest``) were added, to address difficulties in the case of a hardware wallet signing - transparent inputs. ``script_codes_sig_digest`` helps the hardware wallet to + transparent inputs. ``scriptpubkeys_sig_digest`` helps the hardware wallet to determine the subset of inputs belonging to it [#bip-0341-scriptPubKey]_. ``amounts_sig_digest`` prevents the transaction creator from lying to the hardware wallet about the transaction fee [#bip-0341-amount]_. Without these From 1b30e57bde9d6cafb3585a18c47c04c22d26933a Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Wed, 12 Jan 2022 16:36:08 +0000 Subject: [PATCH 12/13] ZIP 244: Commit to scriptPubKey in txin_sig_digest instead of scriptCode This is a no-op for every scriptPubKey format except P2SH, where we now commit to the digest of the redeemScript instead instead of redeemScript directly. --- zip-0244.html | 30 ++++++++++++++++++++---------- zip-0244.rst | 43 ++++++++++++++++++++++++++++++++++--------- 2 files changed, 54 insertions(+), 19 deletions(-) diff --git a/zip-0244.html b/zip-0244.html index 08e4c46aa..9ce86d75e 100644 --- a/zip-0244.html +++ b/zip-0244.html @@ -319,11 +319,15 @@
    S.2g: txin_sig_digest

    If we are producing a hash for the signature over a transparent input, the value of txin_sig_digest is a BLAKE2b-256 hash of the following properties of the transparent input being signed, initialized with the personalization field value Zcash___TxInHash (3 underscores):

    - 
    S.2g.i:   prevout     (field encoding)
-S.2g.ii:  value       (8-byte signed little-endian)
-S.2g.iii: script_code (field encoding)
-S.2g.iv:  nSequence   (4-byte unsigned little-endian)
    -

    Note: value is defined in the consensus rules to be a nonnegative value <= MAX_MONEY, but all existing implementations parse this value as signed and enforce the nonnegative constraint as a consensus check. It is defined as signed here for consistency with those existing implementations.

    + 
    S.2g.i:   prevout      (field encoding)
+S.2g.ii:  value        (8-byte signed little-endian)
+S.2g.iii: scriptPubKey (field encoding)
+S.2g.iv:  nSequence    (4-byte unsigned little-endian)
    +

    Notes:

    +
      +
    • value is defined in the consensus rules to be a nonnegative value <= MAX_MONEY, but all existing implementations parse this value as signed and enforce the nonnegative constraint as a consensus check. It is defined as signed here for consistency with those existing implementations.
      • +
    • scriptPubKey is the field encoding (including a leading CompactSize) of the pk_script field 14 for the coin spent by the transparent input. For P2SH coins, this differs from the redeemScript committed to in ZIP 243 7.
      • +

    If we are producing a hash for the signature over a Sapling Spend or an Orchard Action, txin_sig_digest is:

    BLAKE2b-256("Zcash___TxInHash", [])
    @@ -394,7 +398,7 @@ is well-defined because \(\mathsf{tx\_count} > 0\) , due to the coinbase transaction in each block. Non-leaf hashes in this tree are BLAKE2b-256 hashes personalized by the string "ZcashAuthDatHash".

    -

    Changing the block header format to allow space for an additional commitment is somewhat invasive. Instead, the name and meaning of the hashLightClientRoot field, described in ZIP 221 4, is changed.

    +

    Changing the block header format to allow space for an additional commitment is somewhat invasive. Instead, the name and meaning of the hashLightClientRoot field, described in ZIP 221 4, is changed.

    hashLightClientRoot is renamed to hashBlockCommitments. The value of this hash is the BLAKE2b-256 hash personalized by the string "ZcashBlockCommit" of the following elements:

    hashLightClientRoot (as described in ZIP 221)
 hashAuthDataRoot    (as described below)
@@ -407,16 +411,22 @@

    Rationale

    In S.2, we use the same personalization strings for fields that have matching fields in T.2, in order to facilitate reuse of their digests. In particular, the "no transparent inputs or outputs" case of S.2 is identical to the equivalent case in T.2; thus for fully shielded transactions, signature_digest is equal to txid_digest.

    -

    Several changes in this ZIP (relative to ZIP 243 7) were made to align with BIP 341 9:

    +

    Several changes in this ZIP (relative to ZIP 243 7) were made to align with BIP 341 9:

      -
    • The hash_type field is now restricted via a new consensus rule to be one of a specific set of sighash type encodings. The rationale for this change is inherited from BIP 341 10. +
    • The hash_type field is now restricted via a new consensus rule to be one of a specific set of sighash type encodings. The rationale for this change is inherited from BIP 341 10.
      • Note however that we do not define SIGHASH_DEFAULT, as it is equivalent to SIGHASH_ALL, and we prefer the encodings to be canonical.
      • -
    • Two new commitments (amounts_sig_digest and scriptpubkeys_sig_digest) were added, to address difficulties in the case of a hardware wallet signing transparent inputs. scriptpubkeys_sig_digest helps the hardware wallet to determine the subset of inputs belonging to it 11. amounts_sig_digest prevents the transaction creator from lying to the hardware wallet about the transaction fee 12. Without these commitments, the hardware wallet would need to be sent every transaction containing an outpoint referenced in the transaction being signed.
      • -
    • The semantics of sequence_sig_digest were changed, to commit to nSequence even if SIGHASH_SINGLE or SIGHASH_NONE is set. The rationale for this change is inherited from BIP 341 13.
      • +
    • Two new commitments (amounts_sig_digest and scriptpubkeys_sig_digest) were added, to address difficulties in the case of a hardware wallet signing transparent inputs. scriptpubkeys_sig_digest helps the hardware wallet to determine the subset of inputs belonging to it 11. amounts_sig_digest prevents the transaction creator from lying to the hardware wallet about the transaction fee 12. Without these commitments, the hardware wallet would need to be sent every transaction containing an outpoint referenced in the transaction being signed.
      • +
    • The semantics of sequence_sig_digest were changed, to commit to nSequence even if SIGHASH_SINGLE or SIGHASH_NONE is set. The rationale for this change is inherited from BIP 341 13.
    • The semantics of outputs_sig_digest were changed, via a new consensus rule that rejects transparent inputs for which SIGHASH_SINGLE is set without a corresponding transparent output at the same index. BIP 341 does not give a rationale for this change, but without it these inputs were effectively using SIGHASH_NONE, which is silently misleading.
      • +
    • The semantics of txin_sig_digest were changed, to always commit to the scriptPubKey field of the transparent coin being spent, instead of the script actually being executed at the time signature_digest is calculated. +
        +
      • This ensures that the signature commits to the entire committed script. In Taproot, this makes it possible to prove to a hardware wallet what (unused) execution paths exist 11. Alternate execution paths don't exist for P2PKH (where the executed script is scriptPubKey) or P2SH (where scriptPubKey is fully executed prior to redeemScript).
        • +
      • For P2SH, this means we commit to the Hash160 digest of redeemScript instead of the actual script. Note that the Bitcoin P2SH design depends entirely on Hash160 being preimage resistant, because otherwise anyone would be able to spend someone else's P2SH UTXO using a preimage. We do need to ensure that there is no collision attack; this holds because even if an adversary could find a Hash160 collision, this would only enable them to alter the input's scriptSig field. Doing so doesn't alter the effecting data of the transaction, which by definition means the transaction has the same effect under consensus (spends the same inputs and produces the same outputs).
        • +
      +

    Signatures over Sapling Spends or Orchard Actions commit to the same data as for transparent inputs, in order to ensure that they commit to all transparent input values. Without this commitment, there is a similar difficulty in the case where a hardware wallet is only signing shielded inputs, in a transaction that also contains transparent inputs from a malicious other party (where that party lies about their coins' values).

    diff --git a/zip-0244.rst b/zip-0244.rst index f1fc889e9..bb09ebc00 100644 --- a/zip-0244.rst +++ b/zip-0244.rst @@ -619,15 +619,21 @@ of ``txin_sig_digest`` is a BLAKE2b-256 hash of the following properties of the transparent input being signed, initialized with the personalization field value ``Zcash___TxInHash`` (3 underscores):: - S.2g.i: prevout (field encoding) - S.2g.ii: value (8-byte signed little-endian) - S.2g.iii: script_code (field encoding) - S.2g.iv: nSequence (4-byte unsigned little-endian) - -Note: ``value`` is defined in the consensus rules to be a nonnegative value <= -``MAX_MONEY``, but all existing implementations parse this value as signed and -enforce the nonnegative constraint as a consensus check. It is defined as signed -here for consistency with those existing implementations. + S.2g.i: prevout (field encoding) + S.2g.ii: value (8-byte signed little-endian) + S.2g.iii: scriptPubKey (field encoding) + S.2g.iv: nSequence (4-byte unsigned little-endian) + +Notes: + +- ``value`` is defined in the consensus rules to be a nonnegative value <= + ``MAX_MONEY``, but all existing implementations parse this value as signed and + enforce the nonnegative constraint as a consensus check. It is defined as + signed here for consistency with those existing implementations. +- ``scriptPubKey`` is the field encoding (including a leading ``CompactSize``) + of the ``pk_script`` field [#bdr-txout]_ for the coin spent by the transparent + input. For P2SH coins, this differs from the ``redeemScript`` committed to in + ZIP 243 [#zip-0243]_. If we are producing a hash for the signature over a Sapling Spend or an Orchard Action, ``txin_sig_digest`` is:: @@ -828,6 +834,25 @@ align with BIP 341 [#bip-0341]_: corresponding transparent output at the same index. BIP 341 does not give a rationale for this change, but without it these inputs were effectively using ``SIGHASH_NONE``, which is silently misleading. +- The semantics of ``txin_sig_digest`` were changed, to always commit to the + ``scriptPubKey`` field of the transparent coin being spent, instead of the + script actually being executed at the time ``signature_digest`` is calculated. + + - This ensures that the signature commits to the entire committed script. In + Taproot, this makes it possible to prove to a hardware wallet what (unused) + execution paths exist [#bip-0341-scriptPubKey]_. Alternate execution paths + don't exist for P2PKH (where the executed script is ``scriptPubKey``) or + P2SH (where ``scriptPubKey`` is fully executed prior to ``redeemScript``). + - For P2SH, this means we commit to the Hash160 digest of ``redeemScript`` + instead of the actual script. Note that the Bitcoin P2SH design depends + entirely on Hash160 being preimage resistant, because otherwise anyone would + be able to spend someone else's P2SH UTXO using a preimage. We do need to + ensure that there is no collision attack; this holds because even if an + adversary could find a Hash160 collision, this would only enable them to + alter the input's ``scriptSig`` field. Doing so doesn't alter the effecting + data of the transaction, which by definition means the transaction has the + same effect under consensus (spends the same inputs and produces the same + outputs). Signatures over Sapling Spends or Orchard Actions commit to the same data as for transparent inputs, in order to ensure that they commit to all transparent input From 2ae8fc6cec8fdf47ed84b4b8bfb69077bc2b5d6b Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Thu, 13 Jan 2022 14:25:50 +0000 Subject: [PATCH 13/13] Minor wording nits. Signed-off-by: Daira Hopwood --- zip-0244.html | 2 +- zip-0244.rst | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/zip-0244.html b/zip-0244.html index 9ce86d75e..4c73f00e3 100644 --- a/zip-0244.html +++ b/zip-0244.html @@ -424,7 +424,7 @@
  • The semantics of txin_sig_digest were changed, to always commit to the scriptPubKey field of the transparent coin being spent, instead of the script actually being executed at the time signature_digest is calculated.
    • This ensures that the signature commits to the entire committed script. In Taproot, this makes it possible to prove to a hardware wallet what (unused) execution paths exist 11. Alternate execution paths don't exist for P2PKH (where the executed script is scriptPubKey) or P2SH (where scriptPubKey is fully executed prior to redeemScript).
      • -
    • For P2SH, this means we commit to the Hash160 digest of redeemScript instead of the actual script. Note that the Bitcoin P2SH design depends entirely on Hash160 being preimage resistant, because otherwise anyone would be able to spend someone else's P2SH UTXO using a preimage. We do need to ensure that there is no collision attack; this holds because even if an adversary could find a Hash160 collision, this would only enable them to alter the input's scriptSig field. Doing so doesn't alter the effecting data of the transaction, which by definition means the transaction has the same effect under consensus (spends the same inputs and produces the same outputs).
      • +
    • For P2SH, this means we commit to the Hash160 digest of redeemScript instead of the actual script. Note that the Bitcoin P2SH design depends entirely on Hash160 being preimage-resistant, because otherwise anyone would be able to spend someone else's P2SH UTXO using a preimage. We do need to ensure that there is no collision attack; this holds because even if an adversary could find a Hash160 collision, it would only enable them to alter the input's scriptSig field. Doing so doesn't alter the effecting data of the transaction, which by definition means the transaction has the same effect under consensus (spends the same inputs and produces the same outputs).
    • diff --git a/zip-0244.rst b/zip-0244.rst index bb09ebc00..4640cfcc4 100644 --- a/zip-0244.rst +++ b/zip-0244.rst @@ -845,10 +845,10 @@ align with BIP 341 [#bip-0341]_: P2SH (where ``scriptPubKey`` is fully executed prior to ``redeemScript``). - For P2SH, this means we commit to the Hash160 digest of ``redeemScript`` instead of the actual script. Note that the Bitcoin P2SH design depends - entirely on Hash160 being preimage resistant, because otherwise anyone would + entirely on Hash160 being preimage-resistant, because otherwise anyone would be able to spend someone else's P2SH UTXO using a preimage. We do need to ensure that there is no collision attack; this holds because even if an - adversary could find a Hash160 collision, this would only enable them to + adversary could find a Hash160 collision, it would only enable them to alter the input's ``scriptSig`` field. Doing so doesn't alter the effecting data of the transaction, which by definition means the transaction has the same effect under consensus (spends the same inputs and produces the same