Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug: V5 Transaction's network upgrade is not verified before calculating the SigHash #2480

Closed
jvff opened this issue Jul 9, 2021 · 2 comments · Fixed by #2719 or #2679
Closed

Bug: V5 Transaction's network upgrade is not verified before calculating the SigHash #2480

jvff opened this issue Jul 9, 2021 · 2 comments · Fixed by #2719 or #2679
Assignees
Labels
A-consensus Area: Consensus rule updates A-rust Area: Updates to Rust code C-bug Category: This is a bug C-enhancement Category: This is an improvement NU-1 Sapling Network Upgrade: Sapling specific tasks NU-5 Network Upgrade: NU5 specific tasks

Comments

@jvff
Copy link
Contributor

jvff commented Jul 9, 2021

Motivation

In zebra_consensus::transaction::Verifier::verify_v5_transaction, there's a validation of the network upgrade the transaction is part of (Verifier::verify_v5_transaction_upgrade) that prevents V5 transactions from being accepted before NU5 activation. However, the transaction's sighash is calculated before the network upgrade check. This means that an incorrect sighash is calculated unnecessarily if the transaction's network upgrade is before NU5.

@conradoplg noticed that the v5_transaction_is_rejected_before_nu5_activation test was failing after updating the sighash code to use librustzcash (#2183). This was because the test was marked should_panic, and it wasn't panicking anymore.

Initially, the test would panic because there was the sighash algorithm for V5 transactions wasn't implemented yet. After it was implemented, the test was still panicking because the sighash implementation would panic with the incorrect transaction version. Changing all sighash calculations to use librustzcash (#2469) does not panic when calculating the sighash, so using it led to the test failing, because it was now passing successfully when a panic was expected.

However, this should still be prevented in the transaction::Verifier code. A more general option is to change the check to be more generic, so that it can match multiple transaction versions (not just V5) to multiple network upgrades. This check can then be moved into the call method, together with some other more basic checks.

Specifications

These rules are already implemented, but the check needs to be earlier, and all these rules need to be documented:

  • [Sapling to Canopy inclusive, pre-NU5] The transaction version number MUST be 4, and the version group ID MUST be 0x892F2085.
  • [NU5 onward] The transaction version number MUST be 4 or 5. If the transaction version number is 4 then the version group ID MUST be 0x892F2085. If the transaction version number is 5 then the version group ID MUST be 0x26A7270A.

https://zips.z.cash/protocol/protocol.pdf#txnconsensus

These rules are redundant, or covered by the mandatory Canopy checkpoint:

  • The transaction version number MUST be greater than or equal to 1.
  • [Overwinter only, pre-Sapling] The transaction version number MUST be 3, and the version group ID MUST be 0x03C48270.

Related Work

#2469 uncovered this issue, initially introduced by how the code was structured in #2437.

@jvff jvff added C-enhancement Category: This is an improvement S-needs-triage Status: A bug report needs triage labels Jul 9, 2021
@teor2345 teor2345 added A-consensus Area: Consensus rule updates A-rust Area: Updates to Rust code C-bug Category: This is a bug NU-1 Sapling Network Upgrade: Sapling specific tasks NU-5 Network Upgrade: NU5 specific tasks P-Low labels Jul 12, 2021
@conradoplg
Copy link
Collaborator

#2679 reorders the network upgrade check and also adds the check for V4 transactions. But we still need to verify/document the version group ID check.

@conradoplg
Copy link
Collaborator

This will only close when #2679 is merged (which will happen soon anyway)

@conradoplg conradoplg reopened this Sep 1, 2021
@conradoplg conradoplg linked a pull request Sep 1, 2021 that will close this issue
3 tasks
@mpguerra mpguerra removed the S-needs-triage Status: A bug report needs triage label Sep 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-consensus Area: Consensus rule updates A-rust Area: Updates to Rust code C-bug Category: This is a bug C-enhancement Category: This is an improvement NU-1 Sapling Network Upgrade: Sapling specific tasks NU-5 Network Upgrade: NU5 specific tasks
Projects
None yet
4 participants