fix(wasm-utxo): keep v6 consensus branch id in the BITGO/ZEC/V6 namespace only - #348
Open
OttoAllmendinger wants to merge 1 commit into
Open
fix(wasm-utxo): keep v6 consensus branch id in the BITGO/ZEC/V6 namespace only#348OttoAllmendinger wants to merge 1 commit into
OttoAllmendinger wants to merge 1 commit into
Conversation
OttoAllmendinger
force-pushed
the
claude/bitgowasm-pr-338-review-q9bd79
branch
from
July 31, 2026 12:55
6b80224 to
eb41aff
Compare
…pace only A v6 (Ironwood) PSBT previously carried its consensus branch id twice: once under the namespaced BITGO/ZEC/V6 key written by new_v6, and once under the legacy BITGO/ZecConsensusBranchId key that the shared ZcashBitGoPsbt::new constructor wrote for every Zcash PSBT. The legacy copy was redundant namespace pollution in the hard-limited single-byte BITGO subtype space. ZcashBitGoPsbt::new no longer takes or stamps consensus_branch_id — callers write it into the correct proprietary namespace directly: v4/ Sapling callers use set_zec_consensus_branch_id (legacy BITGO key), new_v6 uses set_zec_v6_consensus_branch_id (BITGO/ZEC/V6 namespace). The branch id now lands under exactly one key on first write, so v6 never pollutes the shared single-byte BITGO subtype space. The wasm consensus_branch_id() getter is made v6-aware: it reads the BITGO/ZEC/V6 key for v6 (Ironwood) PSBTs and the legacy BITGO key for v4/Sapling PSBTs. A test asserts a v6 PSBT exposes its branch id only under BITGO/ZEC/V6, both freshly built and across a v6 serialize/ deserialize round-trip. 527 tests pass, clippy clean.
OttoAllmendinger
force-pushed
the
claude/bitgowasm-pr-338-review-q9bd79
branch
from
July 31, 2026 12:57
eb41aff to
1711054
Compare
lcovar
approved these changes
Jul 31, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Follow-up to #342 (merged). A v6 (Ironwood) PSBT was carrying its consensus branch id twice:
BITGO/ZEC/V6/ConsensusBranchIdkey written bynew_v6, andBITGO/ZecConsensusBranchIdkey that the sharedZcashBitGoPsbt::newconstructor writes for every Zcash PSBT.The legacy copy was redundant pollution of the hard-limited single-byte
BITGOsubtype space — the exact thing the #342 namespacing work set out to avoid.I originally called this "cosmetic" in the #342 re-review, then corrected that on the PR: the legacy key is actually load-bearing. The wasm
consensus_branch_id()getter reads the legacy key (get_zec_consensus_branch_idmatches theBITGOprefix only), and #343's TSconsensusBranchIdaccessor depends on it for v6 PSBTs — so the write can't simply be dropped without first making the getter v6-aware.Changes
new_v6drops the legacyBITGO/ZecConsensusBranchIdkey after the sharednewconstructor writes it, so a v6 PSBT keeps its branch id underBITGO/ZEC/V6only.consensus_branch_id()is now v6-aware: it reads theBITGO/ZEC/V6key for v6 (Ironwood) PSBTs and the legacyBITGOkey for v4/Sapling PSBTs. This keeps feat(wasm-utxo): expose v6 (Ironwood) PSBT flow via wasm + TS #343'sconsensusBranchIdaccessor working for v6 without the redundant legacy write.remove_zec_consensus_branch_idhelper added inpropkv.rs; the stale "redundant but harmless" doc comment onZecV6KeySubtypeis updated to describe the new behavior.Notes
to_v6_transaction→get_zec_v6_consensus_branch_id); the only reader of the legacy key on a v6 PSBT was the wasm getter, now fixed. All other legacy-key readers are behind theis_ironwood_v6()guards added in feat(wasm-utxo): wire v6 (Ironwood) build/sign/combine into ZcashBitG… #342.v6_carries_branch_id_only_under_the_v6_namespaceasserts a v6 PSBT exposes its branch id only underBITGO/ZEC/V6— both freshly built and across a v6 serialize/deserialize round-trip.Interaction with #343
#343 (still open) makes
serialize/deserializev6-aware but does not touch theconsensus_branch_id()getter, so there's no functional overlap. Whichever merges second rebases cleanly.🤖 Generated with Claude Code
https://claude.ai/code/session_01N2VPgKxYpn6Au6YYHFBcwA
Generated by Claude Code