[ZIP 230, ZIP 246] v6 transaction format and sighash #987

str4d · 2025-02-26T23:13:32Z

Incomplete todo list:

Specify sighash versioning process (it is currently just a rough summary).

It can always be derived, and would need to be re-derived for verification purposes anyway.

This performs various improvements to the naming of the branches of the TxID and Signature Digests, and the Authorizing Data Commitment, as initially suggested in the review of QED-it/zcash-test-vectors#24. (adapted from commit QED-it/zips@8662fd6)

Rationale: these are long enough as it is, and ZSAs are an augmentation to the existing Orchard pool, not a new pool of funds.

Signed-off-by: Daira-Emma Hopwood <[email protected]>

clean up some formatting. Signed-off-by: Daira-Emma Hopwood <[email protected]>

vivek-arte

One of the changes relevant for the sighash and transaction format is the move of the burn field information into the action groups.

Note that this is independent of any subsequent versioning etc for Swaps specific changes, it is natural to have the burn information a part of each Action Group.

I've made those changes as suggestions in this review, along with a few smaller suggestions.

zips/zip-0227.rst

vivek-arte · 2025-02-27T17:28:14Z

zips/zip-0230.rst

+| varies                      | ``nAssetBurn``               | ``compactSize``                                |The number of Assets burnt.                                          |
+-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
+| 40 × ``nAssetBurn``         | ``vAssetBurn``               | ``AssetBurn[nAssetBurn]``                      |A sequence of Asset Burn descriptions, encoded per                   |
+|                             |                              |                                                | encoded per `OrchardZSA Asset Burn Description`_.                   |
+-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+


This corresponds to the move of the asset burn fields into the Action Group. We move this down into the OrchardZSA Action Group Description.

Suggested change

| varies | ``nAssetBurn`` | ``compactSize`` |The number of Assets burnt. |

+-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+

| 40 × ``nAssetBurn`` | ``vAssetBurn`` | ``AssetBurn[nAssetBurn]`` |A sequence of Asset Burn descriptions, encoded per |

| | | | encoded per `OrchardZSA Asset Burn Description`_. |

+-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+

As noted in #960 (comment), this change requires further discussion. In particular, no rationale has been provided for this move (which should be in ZIP 227), and there's been no discussion anywhere I'm aware of about the privacy implications of this change, or how it impacts the ability of the ActionGroup bundler to decide which ActionGroups to bundle (AFAICT after this change, the bundler would need to contribute their own ActionGroup in order to handle any mismatch that requires altering burns, which increases both the size and fee of the transaction beyond what the bundled ActionGroups would otherwise cost).

For the NU7 setting, there is no impact as such since the bundling continues to be done by the party creating the component action groups.

For the subsequent Swaps addition, we already expect the bundler to create their own Action Group in order to collect any "matching fees", so this is not a cost that is not already part of the Swaps mechanism.

any mismatch that requires altering burns

An example is when someone creates an Action Group with burn fields corresponding to Assets they don’t have. If the bundler wants to accept such an Action Group by adding the necessary Assets to the transaction themselves, they are free to do so (though I don't see why they would?). If not, they are free to ignore the Action Group that doesn’t balance out, so such Action Groups would never be included. Did you have a different scenario in mind?

The motivation for having burn information inside the Action Group is to allow parties to be able to burn Assets as well, otherwise the burning ability remains only with the bundler. (I agree this rationale should be added)

Also, I suppose it is better to have this discussion in its own PR rather than here?

We already have this change up in #976 building on top of main, though it does not have the ZIP 246 changes which are part of this PR. I also opened #991 that builds on top of this PR (#987) instead.

Indeed, these changes should have initially been proposed in their own PR (#976 was not such a PR, as it also included other unrelated changes). The discussion continues here: https://github.com/zcash/zips/pull/991/files#r1990147143

zips/zip-0230.rst

zips/zip-0246.rst

vivek-arte · 2025-02-27T17:55:42Z

zips/zip-0246.rst

+    T.4a.iii : flagsOrchard                        (1 byte)
+    T.4a.iv  : anchorOrchard                       (32 bytes)
+    T.4a.v   : nAGExpiryHeight                     (4 bytes)


This corresponds to the move of the asset burn fields into the Action Group.

Suggested change

T.4a.iii : flagsOrchard (1 byte)

T.4a.iv : anchorOrchard (32 bytes)

T.4a.v : nAGExpiryHeight (4 bytes)

T.4a.iii : orchard_burn_digest (32-byte hash output)

T.4a.iv : flagsOrchard (1 byte)

T.4a.v : anchorOrchard (32 bytes)

T.4a.vi : nAGExpiryHeight (4 bytes)

This is now proposed and discussed in #991

zips/zip-0246.rst

zips/zip-0226.rst

Co-authored-by: Vivek Arte <[email protected]>

daira · 2025-02-28T20:40:14Z

zips/zip-0227.rst

-.. [#zip-0317-fee-calc] `ZIP 317: Proportional Transfer Fee Mechanism, Fee calculation <zip-0317.html#fee-calculation>`_
+.. [#zip-0246] `ZIP 246: Digests for the Version 6 Transaction Format <zip-0246.html>`_
+.. [#zip-0317] `ZIP 317: Proportional Transfer Fee Mechanism <zip-0317.html>`_
+.. [#zip-0317-fee-calculation] `ZIP 317: Proportional Transfer Fee Mechanism - Fee calculation <zip-0317.html#fee-calculation>`_
 .. [#bip-0043] `BIP 43: Purpose Field for Deterministic Wallets <https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki>`_
 .. [#bip-0340] `BIP 340: Schnorr Signatures for secp256k1 <https://github.com/bitcoin/bips/blob/200f9b26fe0a2f235a2af8b30c4be9f12f6bc9cb/bip-0340.mediawiki>`_


Is there a reason this is referring to a specific commit? We usually just reference master (in this case it looks like it there are only editorial changes since that commit).

That question is irrelevant to this PR. Please open a separate issue and tag qedit into it.

We can switch to referencing master if that is the usual convention.

I used the commit for similar reasons to referencing a specific commit in the zcash-test-vectors repository when using the bip340.py code from the bips repository. The specification BIP though should not need that.

This can be switched here, as suggested, or in a separate PR, or via opening a separate issue, as the ZIP Editors feel fit.

Suggested change

.. [#bip-0340] `BIP 340: Schnorr Signatures for secp256k1 <https://github.com/bitcoin/bips/blob/200f9b26fe0a2f235a2af8b30c4be9f12f6bc9cb/bip-0340.mediawiki>`_

.. [#bip-0340] `BIP 340: Schnorr Signatures for secp256k1 <https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki>`_

str4d · 2025-03-11T22:26:09Z

zips/zip-0246.rst

+- Sighash versions are numbered starting from 0 for each tx version.
+- v0 is by convention the "commit to everything" sighash digest. Other versions can commit to whatever makes sense for desired functionality within that tx version.
+- Have a single byte encoded alongside the signature (not appended the way transparent does) that permits the signer to specify which sighash version they are using.
+- Consensus rules choose the digest algorithm for each signer based on that byte.


We should clarify that the consensus rules choose from the available digest algorithms for the (consensus_branch_id, transaction_version) tuple under question (both of which are committed to by the transaction, and can therefore be checked non-contextually). For the NU7 consensus branch ID, there will only be one available digest version for v6 transactions (the v0 digests).

str4d · 2025-03-11T23:13:11Z

zips/zip-0246.rst

+
+- Sighash versions are numbered starting from 0 for each tx version.
+- v0 is by convention the "commit to everything" sighash digest. Other versions can commit to whatever makes sense for desired functionality within that tx version.
+- Have a single byte encoded alongside the signature (not appended the way transparent does) that permits the signer to specify which sighash version they are using.


In ZIP Sync, we discussed how this should be represented. We identified that one of the issues we have with how transparent sighash types are handled is that they are considered authorizing data (they are appended to signatures and are thus part of the signature, chosen at signing time by the signer). We decided that for sighash versioning, we'd prefer them to be effecting data. This means:

For Sapling spendAuthSig, this would be an extra byte on the Spend Description.

For Orchard spendAuthSig, this would be an extra byte on the Action Description.

For bindingSigs, we place an extra byte in the corresponding bundles.

For transparent, due to the lack of a 1:1 between inputs and signatures (as an arbitrary number of signatures can exist within a scriptSig), this would be an extra byte on the CTxIn that is used for every signature authorizing the input.

@daira doesn't think we need it at the per-input level for transparent (Ya Ain't Gonna Need It), while @str4d says this is useful for symmetry (the effecting data is then consistently at the per-input level) and that we are trying to create a design that doesn't restrict what kinds of sighash digest algorithms we might want to create in future. @nuttycom is happy to have it at the per-input level for now, and we can adjust if we discover difficulties.

Note that there is no requirement for future sighash digest algorithms to pay any attention to the sighash_type appended to each signature. It is entirely fine for us to treat that as a v0-specific behaviour (or even decide to phase it out in future transaction versions, though we are explicitly choosing to keep it for the v6 transaction's v0 digest algorithm).

vivek-arte

Ran into some issues generating the rendered HTML files in #991. The suggestions in this review are those relevant to this PR (#987).

vivek-arte · 2025-03-18T11:08:40Z

zips/zip-0246.rst

+.. [#zip-0230-issue-notes-field-encodings] `ZIP 230: Version 6 Transaction Format. Specification: Issue Note Description <zip-0230.rst#issue-note-description>`_
+.. [#zip-0244] `ZIP 244: Transaction Identifier Non-Malleability <zip-0244.rst>`_
+.. [#zip-0244-sigdigest] `ZIP 244: Transaction Identifier Non-Malleability: Signature Digest <zip-0244.html#signature-digest>`_
+.. [#zip-0244-authcommitment] `ZIP 244: Transaction Identifier Non-Malleability: Authorizing Data Commitment <zip-0244.html#authorizing-data-commitment>`_


There are links to citations of ZIP 307 on L195, L213, L262 and L281 which do not have a reference here.

Suggested change

.. [#zip-0244-authcommitment] `ZIP 244: Transaction Identifier Non-Malleability: Authorizing Data Commitment <zip-0244.html#authorizing-data-commitment>`_

.. [#zip-0244-authcommitment] `ZIP 244: Transaction Identifier Non-Malleability: Authorizing Data Commitment <zip-0244.html#authorizing-data-commitment>`_

.. [#zip-0307] `ZIP 307: Light Client Protocol for Payment Detection <zip-0307.rst>`_

vivek-arte · 2025-03-18T11:14:36Z

zips/zip-0246.rst

+
+  "ZTxId6SOutC_Hash" (1 underscore character)
+
+The field encodings are specified in ZIP 230 [#zip-0230-issuance-field-encodings]_.


This link is not present in the references. Should it instead be:

Suggested change

The field encodings are specified in ZIP 230 [#zip-0230-issuance-field-encodings]_.

The field encodings are specified in §7.4 ‘Output Description Encoding and Consensus’ of the Zcash Protocol Specification [#protocol-outputdesc]_.

vivek-arte · 2025-03-18T11:16:57Z

zips/zip-0246.rst

+
+  "ZTxId6SOutN_Hash" (1 underscore character)
+
+The field encodings are specified in ZIP 230 [#zip-0230-issuance-field-encodings]_.


As above

Suggested change

The field encodings are specified in ZIP 230 [#zip-0230-issuance-field-encodings]_.

The field encodings are specified in §7.4 ‘Output Description Encoding and Consensus’ of the Zcash Protocol Specification [#protocol-outputdesc]_.

vivek-arte · 2025-03-18T11:24:09Z

zips/zip-0246.rst

+
+    BLAKE2b-256("ZTxIdMemo___Hash", [])
+
+The field encodings are specified in ZIP 230 [#zip-0230-issuance-field-encodings]_.


I think this should correspond to this section of ZIP 231 (which defines nonceOrHash rather than nonce though)

Suggested change

The field encodings are specified in ZIP 230 [#zip-0230-issuance-field-encodings]_.

The field encodings are specified in ZIP 231 [#zip-0231-encoding-in-transactions]_.

vivek-arte · 2025-03-18T11:28:38Z

zips/zip-0246.rst

+.. [#zip-0230-orchard-action-field-encodings] `ZIP 230: Version 6 Transaction Format. Specification: OrchardZSA Action Description <zip-0230.rst#orchardzsa-action-description>`_
+.. [#zip-0230-orchard-asset-burn-field-encodings] `ZIP 230: Version 6 Transaction Format. Specification: OrchardZSA Asset Burn Description <zip-0230.rst#orchardzsa-asset-burn-description>`_
+.. [#zip-0230-issue-actions-field-encodings] `ZIP 230: Version 6 Transaction Format. Specification: Issuance Action Description <zip-0230.rst#issuance-action-description>`_
+.. [#zip-0230-issue-notes-field-encodings] `ZIP 230: Version 6 Transaction Format. Specification: Issue Note Description <zip-0230.rst#issue-note-description>`_


Suggested change

.. [#zip-0230-issue-notes-field-encodings] `ZIP 230: Version 6 Transaction Format. Specification: Issue Note Description <zip-0230.rst#issue-note-description>`_

.. [#zip-0230-issue-notes-field-encodings] `ZIP 230: Version 6 Transaction Format. Specification: Issue Note Description <zip-0230.rst#issue-note-description>`_

.. [#zip-0231-encoding-in-transactions] `ZIP 231: Memo Bundles. Encoding in transactions <zip-0231.md#encodingintransactions>

vivek-arte · 2025-03-18T11:32:42Z

zips/zip-0246.rst

+
+S.5: issuance_digest
+````````````````````
+Identical to the ``issuance_digest`` specified for the transaction identifier in ZIP 227 [zip-0227-txiddigest]_.


Since issuance_digest is now in the same file (i.e. ZIP 246):

Suggested change

Identical to the ``issuance_digest`` specified for the transaction identifier in ZIP 227 [zip-0227-txiddigest]_.

Identical to that specified for the transaction identifier.

str4d and others added 15 commits February 26, 2025 00:46

ZIP 230: Reorganise ActionGroupDescription to group effecting data

8862ae2

ZIP 230: Constrain parser for nAGExpiryHeight and clarify 0

cdf76fb

ZIP 230: Remove AssetBase from issuance bundle encoding

80ac162

It can always be derived, and would need to be re-derived for verification purposes anyway.

ZIP 246: Initial empty ZIP structure for v6 transaction digests

c0c20fb

Updating digest names (#95)

7a112c7

This performs various improvements to the naming of the branches of the TxID and Signature Digests, and the Authorizing Data Commitment, as initially suggested in the review of QED-it/zcash-test-vectors#24. (adapted from commit QED-it/zips@8662fd6)

Move-only: Move sighash content from ZIP 226 to ZIP 246

a34a5eb

Move-only: Move sighash content from ZIP 227 to ZIP 246

5ab748a

Replace moved content in ZIPs 226 and 227 with a reference

457a04c

ZIP 246: Refer to ZIP 230 for field encodings

f44713e

ZIP 246: Fix heading levels and a bug from #975

8df0c17

ZIP 246: Remove _zsa internal suffix from digest names

dba350f

Rationale: these are long enough as it is, and ZSAs are an augmentation to the existing Orchard pool, not a new pool of funds.

Integrate ZIP 231 changes into ZIPs 230 and 246

5ec91f9

Integrate ZIPs 233 and 2002 into ZIPs 230 and 246

07fa7c3

Clear out some trailing whitespace

2220b35

ZIP 317: Fix rendering of conventional fee formula

aa7436e

str4d marked this pull request as draft February 26, 2025 23:13

str4d added 2 commits February 26, 2025 23:15

ZIP 317: Integrate fee changes from ZIP 227

39d74ed

ZIP 317: Integrate fee changes from ZIP 231

b0d8fbd

str4d force-pushed the v6-tx-format-and-sighash branch from b15642a to b0d8fbd Compare February 26, 2025 23:15

str4d mentioned this pull request Feb 26, 2025

ZIPs 226, 227, and 230: ZSA Transfer, Issuance and Burn #976

Open

daira added 2 commits February 27, 2025 00:57

Improve formatting of ZIP 317.

edba0a0

Signed-off-by: Daira-Emma Hopwood <[email protected]>

ZIP 230: make all the table columns the same width in the source, and

001cdd8

clean up some formatting. Signed-off-by: Daira-Emma Hopwood <[email protected]>

vivek-arte reviewed Feb 27, 2025

View reviewed changes

daira reviewed Feb 27, 2025

View reviewed changes

zips/zip-0226.rst Outdated Show resolved Hide resolved

Apply minor editorial suggestions

3d6f118

Co-authored-by: Vivek Arte <[email protected]>

daira reviewed Feb 28, 2025

View reviewed changes

vivek-arte mentioned this pull request Mar 11, 2025

[ZIP 227, ZIP 230, ZIP 246] Addition of burn fields into the Action Group #991

Open

str4d commented Mar 11, 2025

View reviewed changes

vivek-arte reviewed Mar 18, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[ZIP 230, ZIP 246] v6 transaction format and sighash #987

[ZIP 230, ZIP 246] v6 transaction format and sighash #987

str4d commented Feb 26, 2025 •

edited

Loading

vivek-arte left a comment •

edited

Loading

vivek-arte Feb 27, 2025

str4d Mar 6, 2025

vivek-arte Mar 11, 2025

vivek-arte Mar 11, 2025

str4d Mar 11, 2025

vivek-arte Feb 27, 2025

vivek-arte Mar 13, 2025

daira Feb 28, 2025

str4d Mar 6, 2025

vivek-arte Mar 6, 2025

str4d Mar 11, 2025

str4d Mar 11, 2025 •

edited

Loading

vivek-arte left a comment

vivek-arte Mar 18, 2025

vivek-arte Mar 18, 2025

vivek-arte Mar 18, 2025

vivek-arte Mar 18, 2025

vivek-arte Mar 18, 2025

vivek-arte Mar 18, 2025

-    T.4a.iii : flagsOrchard                        (1 byte)
-    T.4a.iv  : anchorOrchard                       (32 bytes)
-    T.4a.v   : nAGExpiryHeight                     (4 bytes)
+    T.4a.iii : orchard_burn_digest                 (32-byte hash output)
+    T.4a.iv  : flagsOrchard                        (1 byte)
+    T.4a.v   : anchorOrchard                       (32 bytes)
+    T.4a.vi  : nAGExpiryHeight                     (4 bytes)

	.. [#bip-0340] `BIP 340: Schnorr Signatures for secp256k1 <https://github.com/bitcoin/bips/blob/200f9b26fe0a2f235a2af8b30c4be9f12f6bc9cb/bip-0340.mediawiki>`_
	.. [#bip-0340] `BIP 340: Schnorr Signatures for secp256k1 <https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki>`_

	.. [#zip-0244-authcommitment] `ZIP 244: Transaction Identifier Non-Malleability: Authorizing Data Commitment <zip-0244.html#authorizing-data-commitment>`_
	.. [#zip-0244-authcommitment] `ZIP 244: Transaction Identifier Non-Malleability: Authorizing Data Commitment <zip-0244.html#authorizing-data-commitment>`_
	.. [#zip-0307] `ZIP 307: Light Client Protocol for Payment Detection <zip-0307.rst>`_


		"ZTxId6SOutC_Hash" (1 underscore character)

		The field encodings are specified in ZIP 230 [#zip-0230-issuance-field-encodings]_.

	The field encodings are specified in ZIP 230 [#zip-0230-issuance-field-encodings]_.
	The field encodings are specified in §7.4 ‘Output Description Encoding and Consensus’ of the Zcash Protocol Specification [#protocol-outputdesc]_.


		"ZTxId6SOutN_Hash" (1 underscore character)

		The field encodings are specified in ZIP 230 [#zip-0230-issuance-field-encodings]_.


		BLAKE2b-256("ZTxIdMemo___Hash", [])

		The field encodings are specified in ZIP 230 [#zip-0230-issuance-field-encodings]_.

	.. [#zip-0230-issue-notes-field-encodings] `ZIP 230: Version 6 Transaction Format. Specification: Issue Note Description <zip-0230.rst#issue-note-description>`_
	.. [#zip-0230-issue-notes-field-encodings] `ZIP 230: Version 6 Transaction Format. Specification: Issue Note Description <zip-0230.rst#issue-note-description>`_
	.. [#zip-0231-encoding-in-transactions] `ZIP 231: Memo Bundles. Encoding in transactions <zip-0231.md#encodingintransactions>

	Identical to the ``issuance_digest`` specified for the transaction identifier in ZIP 227 [zip-0227-txiddigest]_.
	Identical to that specified for the transaction identifier.

[ZIP 230, ZIP 246] v6 transaction format and sighash #987

Are you sure you want to change the base?

[ZIP 230, ZIP 246] v6 transaction format and sighash #987

Conversation

str4d commented Feb 26, 2025 • edited Loading

vivek-arte left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

str4d Mar 11, 2025 • edited Loading

Choose a reason for hiding this comment

vivek-arte left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

str4d commented Feb 26, 2025 •

edited

Loading

vivek-arte left a comment •

edited

Loading

str4d Mar 11, 2025 •

edited

Loading