Key Takeaways Every Zcash upgrade invalidates pending signed transactions Developer proposes removing branch ID commitment in NU8 Opt-in signing variants […]
The post Zcash Wallets Break at Every Upgrade – Devs Weigh a Fix appeared first on Coindoo.
Key Takeaways
- Every Zcash upgrade invalidates pending signed transactions
- Developer proposes removing branch ID commitment in NU8
- Opt-in signing variants offered as safer compromise
- Group vaults cannot finish signing across upgrades
In a forum post on November 9, ValarDragon listed removing consensus branch ID updates among seven NU8 goals, with the stated aim of ending the pattern of “breaking wallets every NU.”
The complaint has a fresh example behind it. NU7 activated last week at block 3,543,405 without touching the transaction format, yet, as forum member strahncryptography pointed out in the same thread, every wallet still needed a new release or new firmware before it could spend again. Anyone on an air-gapped phone or an unsupported device was stuck.
By the next morning the thread had produced three positions: drop the mechanism, keep it but let users opt out, or accept that the real problem is wallets going obsolete rather than signatures expiring. A vault developer then showed why the choice is not academic.
What actually breaks
Every Zcash signature commits to a consensus branch ID, a label for the rule set in force. ZIP 200 introduced it so that a transaction signed for one chain cannot be replayed on a fork that shares the same history. When an upgrade activates, the ID changes, and anything signed under the old one is dead on arrival.
The NU7 deployment ZIP spells this out for the upgrade that just happened: version 5 and 6 transactions kept their structure, but a transaction is still not valid across activation because its signatures bind the branch ID. Saved and offline-signed transactions, it adds, need the same activation checks as live ones.
That is why wallets had to ship updates for an upgrade that changed nothing about how they build transactions. A wallet that does not know the new ID signs for a chain that no longer exists.
The vault that cannot sign in time
Daniel Gorgonha, who builds the Konclave t-of-n vault at Deega Labs, described the practical cost later in the thread. Konclave builds the transaction first and collects threshold signatures afterwards, so every required signer has to act inside the transaction’s expiry window, roughly 50 minutes. An upgrade landing in the middle of that window voids the whole thing.
The 50 minutes comes from ZIP 203, which has kept the default expiry at about that length through three changes of block time. Since NU7 that means 120 blocks at the 25-second target spacing. It is a wallet default, configurable per node, and a transaction can be built with no expiry at all by setting the field to zero.
So the clock is already solvable, at least where the wallet exposes the setting. The upgrade boundary is not. A vault could give its members a week to sign and still lose the transaction the moment the branch ID rolls over. Gorgonha’s request was for the opt-out nuttycom had just proposed, so a group could collect signatures over hours or days at its own risk.
Three ways out, each with a catch
Remove the branch ID commitment. ValarDragon’s original proposal. ECC engineer str4d replied that replay protection was a hard requirement from exchanges and other ecosystem players when ZIP 200 was written, so any removal needs a replacement mechanism, ideally one that also covers hostile forks created purely to disrupt the main chain.
Keep it as the default, let users opt out. nuttycom, also at ECC, proposed signing variants under ZIP 248 that skip both the branch ID and the expiry height. Users who choose them give up some replay protection and gain transactions that outlive an upgrade. The existing algorithm, which he said works fine for the vast majority of transactions, would stay the safe default. str4d had already noted that such a variant would be easy to define once ZIP 248 is active.
Question whether that solves anything for wallets. strahncryptography argued the variants fix transaction longevity but not obsolescence: if the branch ID is not hard-coded, the user has to supply the correct one, which puts the same burden back on the wallet software. Replay protection against friendly forks has value, he wrote, but the benefits should be weighed.
The thread has not resolved the disagreement. What it has done is narrow the question to whether an opt-in variant is worth building for the users who need it, and what those users would be giving up.
What opting out would cost
Replay risk is easiest to picture with the upgrade that just happened. For NU7 only, ZIP 259 waived the usual requirement that old node software deprecate itself before activation, which means operators who never upgraded can stay online and keep following a pre-NU7 branch. A transaction whose signature is not tied to one branch is exactly the kind that could be accepted on both.
The exposure is the scope of an authorization, not the keys behind it. A replayed transaction spends the same inputs on another chain the signer never meant to use; it does not let anyone forge a new one.
Dropping the expiry height from the signature has a second effect: an authorized payment can sit unconfirmed for as long as its inputs remain unspent. That is the feature a vault wants and the risk an individual user may not notice.
nuttycom also flagged a possible reduction in the anonymity set. In a shielded system, privacy depends on a transaction looking like every other transaction; one signed with a rarely used variant would be a smaller crowd to hide in. The post did not quantify the effect, and no variant has been specified yet.
A longer-lived signature does not update an old device
ZIP 248, the extensible transaction format all of this depends on, is still a draft. str4d said its design has been stable for over half a year and that he spent the past week updating it for consensus changes deployed since. It has not been assigned to an upgrade, and the opt-out variants do not exist in it yet.
Even once they do, a hardware wallet or offline signer still needs software that understands the new format. ZIP 248 forbids wallets from constructing or signing components they cannot parse. The compatibility benefit is real, but it arrives through wallet releases, which is the step strahncryptography says keeps failing.
Nor does any of this help transactions in a retired format. ZIP 259 notes that the NU7 ban on version 4 transactions covers transparent and Sapling spends as well as Sprout, and that re-signing cannot rescue them; the only fix is rebuilding the payment in a supported version. Coindoo covered the harder case, Sprout coins with no replacement format at all, last week.
Konclave has its own unfinished piece too. Its open issue on asynchronous signing separates approvals collected over time from the interactive threshold ceremony the vault runs today. A transaction that survives an upgrade removes one obstacle; the workflow that lets members contribute as they come online still has to be written and reviewed.
If you run a group wallet
- Activation is a block height, not a date; the deployment ZIP for each upgrade publishes it in advance
- Do not open a signing round that could straddle that height
- Anything prepared before activation has to be rebuilt afterwards, even if nobody signed it yet
If you hold coins on an old device
- Check whether its firmware or app has shipped NU7 support before trying to spend
- A stuck spend from a supported pool is a wallet problem, not lost funds
- Version 4 transactions saved before November 6 cannot be re-signed into validity
Coindoo’s earlier look at wallet-side payment improvements covered the gap between building a transaction and confirming it. This thread adds a third stage in between: keeping the authorization alive while people and devices catch up.
Late January is ValarDragon’s target, not a schedule. str4d questioned in the same thread whether two and a half months is enough for the Tachyon pool on the same list, and the branch ID item has drawn the sharpest pushback of all seven. Whether NU8 ships with an opt-out, a replacement for replay protection, or neither will be settled in the ZIP process, not on the forum.
The post Zcash Wallets Break at Every Upgrade – Devs Weigh a Fix appeared first on Coindoo.
Source: https://coindoo.com/zcash-wallets-break-at-every-upgrade-devs-weigh-a-fix/
More Crypto News
Check our Market Overview
Disclaimer: This article is for informational purposes only and does not constitute financial advice. Always conduct your own research (DYOR).
