so I had my funds on zecwallet lite 1.7.8 on my android smartphone, I synced, no errors, I sent certain round amount of coins to exchange t address, and I got error saying that I’m using old consensus branch, my coin amount was the same after the error, I figured it’s time to update my wallet, I uninstalled 1.7.8 version and installed 1.7.12 version, recovered wallet using seed phrase and as it seems funds are lost somewhere, I cant even see incoming and outgoing transaction of those coins that I had in 1.7.8 version… are they on old branch? since that amount I sent is deducted from my current amount.
any help would be appreciated.
also I tried installing old version of zecwallet to try to discover my funds on old branch or something, but I couldn’t install any old version of zecwallet, phone just says app not installed…
Zecwallet Lite is no longer functioning. Check in Nighthawk and/or YWallet.
hloo
June 7, 2022, 5:47pm
4
@agent007 If you use an old consensus branch id, your transaction will NOT be mined. You can recover your funds by importing your private keys into another wallet.
how do I export private keys on android smartphone, app doesn’t seem to have that option of any sort.
From ZecWallet Lite on mobile, you should be able to go to > Receive on the right, then click the three dots in the top right and go to “Export Private key”.
Try importing that private key, or your seed phrase, into a working wallet.
2 Likes
hanh
June 10, 2022, 6:21am
7
Looks like ZWL zip 212 bug
opened 08:02PM - 16 Dec 20 UTC
# Summary
A "misplaced funds" issue is possible for Canopy wallets due to chang… es from [ZIP-212](https://zips.z.cash/zip-0212). This is less severe than a true "loss of funds" issue only because recovery is possible yet complex. Nonetheless, the implications are noteworthy because they expose related problems that should be improved.
Below, the "Related Issues" section should be researched and "Action Items" should be addressed.
## Conditions
In order for this issue to occur a pre-canopy user or developer would need to:
- **update the consensus branch ID yet not apply the related changes**
This condition is met by versions of Zecwallet-lite prior to 6/6/2020.
## Impact
Transactions generated by such wallets would become "misplaced," currently unusable by both the sender and receiver. It is theoretically possible to recover these funds with a specialized tool. Also, these transactions have a strong likelihood of breaking the sender's wallet, rendering it unable to send funds, even after an upgrade, even after a clean install/restore from backup because it will contain a note that it never sees as mined.
## Mechanics
Once conditions are met, this issue occurs because:
- Canopy introduced a new (V2) plaintext format for notes
- Per ZIP-212, after the "grace period," any transactions using the old (V1) plaintext format should be ignored
- Zcashd cannot detect these "invalid" transactions because the issue occurs in encrypted text
- Crucially, **Zcashd cannot prevent these invalid transactions from being mined** and therefore their nullifiers get revealed on-chain. Let's call this `Factor A`
- Crucially, after the grace period **Canopy wallets ignore transactions with V1 plaintext, as though they never occured.** Let's call this `Factor B`
- Therefore, if a Canopy wallet manages to send such a transaction, **it will never be considered mined by the wallet** due to `Factor B` ([as implemented in the primitives create](https://github.com/zcash/librustzcash/blob/master/zcash_primitives/src/note_encryption.rs#L571-L573))
- Therefore, the funds will expire **and become "spendable" again**
(currently, in the [sqlite crate](https://github.com/zcash/librustzcash/blob/b1c3f9d3f033db9519d45c69d1a8e51dd6b710a5/zcash_client_sqlite/src/scan.rs#L359-L360) but soon [migrating to the data_api](https://github.com/zcash/librustzcash/pull/307/files#diff-b7822330bab7e02a46d4d53555f90753126c6077b7439a1cfb449f051a003854R264-R265))
- However, they're not actually spendable because their nullifier has been revealed due to `Factor A`
- The current [note selection algorithm in the sqlite crate](https://github.com/zcash/librustzcash/blob/master/zcash_client_sqlite/src/transact.rs#L165-L204) selects the oldest notes until the required value has been reached
- Consequently, the wallet will repeatedly attempt to add these "spent" notes to every transaction it creates of equal or greater value
- **In theory, this could render a wallet unusable** even across upgrades and clean restores because the faulty note would be "available" (from the original received note) but unusable (from the V1 spend).
- Additionally, these **funds will be "misplaced" in that neither the sender nor recipient can access them in a wallet.**
- The sender has spent the note
- The recipient will ignore the note during a scan
- It should be possible for the recipient to regain control over the note but no wallet supports this, currently
## Related Issues
This exposes several opportunities for improvement:
Process improvements:
1. **Increase alignment among libraries**
Partners have been somewhat conditioned to [just update the consensus branch ID](https://github.com/zcash/zcash/issues/4629#issuecomment-662358587) in the code. In the past, this was more likely to be hard-coded. Going forward, partners should be encouraged to use the latest node or library. The consensus branch ID should be pushed further down so that it is less tempting for developers to tweak its value or hard-code it somewhere or derive it from block height.
2. **Introduce End of Support (EoS) halts for light clients**
Given the increased presence of light clients, merely enforcing upgrade behavior at the node level is no longer sufficient. The light client ecosystem should be enhanced to handle network upgrades in a more scalable way. EoS should be considered, systemically.
3. **Work from tagged versions rather than commits**
Wallets and libraries should work from tags and versions of underlying dependencies, rather than commits. This makes it easier to pinpoint problems and identify exactly what code is in each release. It also helps ensure that all coordinated changes are available together at once and reduces the likelihood of supporting some but not all consensus changes. Developers should make it as easy as possible to pinpoint exactly when changes were introduced.
4. **Light clients must be conscious participants in consensus rule changes**
Since it is possible to disagree with or partially support consensus changes, wallets and libraries must not passively adopt consensus changes. Therefore, a light client must not create a transaction targeting a consensus branch ID that they do not fully support. Instead, consensus changes should be actively accepted and supported by updating to a tagged version of a library that is compatible with a network upgrade because this allows the developer to confirm whether their product aligns with all consensus changes.
Code improvements:
4. **If a user has a spendable note, they should be able to spend it**
A problematic note should not break send functionality in a wallet, if there are other notes available for transactions. Libraries should either randomize note selection or flag failed notes so that they are not repeatedly chosen for transactions. Errors such as `18: bad-txns-sapling-duplicate-nullifier` should result in those notes being getting lower priority during note selection. This could be flagged in the UI and brought to the user's attention in a clear way.
5. **Notes must not be marked as unspent, if the nullifier exists**
Currently, in the sqlite crate, any sent transaction that is not mined within 20 blocks becomes "expired" and therefore "spendable" but that must not happen if the nullifier is present on the blockchain.
6. **Programmatically identify incompatible sever v. client code**
Incompatible behavior should be prevented as much as possible, particularly for anything that impacts funds. For instance, by default, light clients should refuse to connect to incompatible servers (such as testnet or a different consensus branch).
## Action Items
- [ ] deploy solution for users of old wallets
- [ ] [disable the ability](https://github.com/adityapk00/lightwalletd/pull/6) to create transactions that "misplace" funds
- [ ] [optional] find a creative way to make lightwalletd fail such that a helpful error message appears for users of old wallets.
- [ ] deploy code improvements for future users
- [ ] prevent incompatible sends
- [ ] force upgrades (wallets become "view only" to prevent loss of funds or display "send at your own risk" errors)
- [ ] identify incompatible lightwalletd servers
1 Like