Ywallet, zingo and nighthawk seeds are all compatible even though the wallet account systems are completely different. All existed before NU5, UA’s and any idea of wallet best-practices. Zecwallet light broke and was abandoned. Ywallet is the only wallet that ever attempted to have a recovery system for it. It has always been different. It has also been exceedingly useful so I will just point out that applying present-day perspective to historical applications of things that did not exist at the time of question is a bit fallacious.
Writing a spec after the fact and calling wallets “non-compliant” isn’t gonna change history/reality. Every transparent wallet starts their offset at 0. I could change Ywallet to make it scan additional addresses, but that would make the synchronization slower (especially with the extra shielded address), and I don’t see why Ywallet users should have to pay that price.
Besides, the newer wallet (Zkool) optionally supports ZIP-316, so if someone wants compatibility, it’s there.
1 Like
There’s no extra cost for scanning shielded addresses, because these are diversified addresses; there’s only one IVK. Literally the only cost is looking up UTXOs for two transparent addresses instead of one when calling lightwalletd (unless you wanted to implement gap-limit handling.)
Nighthawk uses the ECC SDK, and always has. And all of these wallets implement ZIP 32, and always have.
Zecwallet light implemented account rotation in the Sapling key tree, not diversified address rotation, and YWallet has as well. zcash_client_backend also supports multiple accounts; that functionality just hasn’t yet been exposed in Zashi because of concerns about UX complexity & issues with having to re-scan portions of the chain when adding accounts to a fully-scanned wallet.
Where YWallet is incompatible (and I understand that Zkool is becoming compatible) is that it doesn’t scan with internal viewing keys. The rationale for internal keys has been reiterated numerous times, but I’ll repeat it here in case anyone isn’t aware of it:
If someone shares an incoming viewing key with a third party, they should be able to assume that that third party can only learn about incoming transactions, and cannot learn when funds received by addresses generated from that IVK are spent, or what the spend amounts are. Prior to ZIP 316, though, wallets used external addresses to receive change. This allowed IVK holders to detect spends, and even potentially learn spend amounts, by comparing the value of change outputs to the value of notes being spent. Essentially, without ZIP 316, an IVK acts almost as a full viewing key for the wallet. The ECC team decided that this was an unacceptable reduction in privacy that at best significantly decreases the usability of incoming viewing keys and at worst dramatically violates users’ assumptions about what an IVK holder could learn, and so we fixed it in the process of introducing unified addresses.
1 Like
The internal/change address has a different IVK, doesn’t it?
I am not questioning your rationale, but pointing out that when you introduce new behavior that is not backward compatible, users won’t be able to transfer from Zashi to an old wallet. IMO, backward compatibility is very important for the ecosystem.
PS: What you say about IVK is true, but in practice, we only have been using FVK.
1 Like
Would it make sense to make this a user choice?
That’s what has been happening on most wallets supporting Ethereum. There are basically three relevant derivation paths (MEW, Trezor & Ledger Live) with default being Trezor, I believe.
The worst for a end user is very clearly to be given no choice and to think their funds are gone. I appreciate the stance of @hanh here. If the default does not work, at least they see this option and they can try something different instead of just being stuck with no apparent recourse.
We gotta move on from this in an elegant way. What’s the move?
i just tried to shield my funds with zashi and it worked! don’t know how, but it’s all good now 
3 Likes
Yes, as the protocol specifies for unified addresses containing a Sapling component.
A valid diversifier d_j is one for which DiversifyHash^Sapling(d_j) ≠ ⊥. For a given dk, approximately half of the possible values of j yield valid diversifiers.
The default diversifier for a Sapling extended key is defined to be d_j, where j is the least nonnegative integer yielding a valid diversifier.
To derive a Unified Address from a UIVK we need to choose a diversifier index, which MUST be valid for all of the Viewing Key Types in the UIVK. That is,
- A Sapling diversifier index MUST generate a valid diversifier as defined in ZIP 32 section “Sapling diversifier derivation”.
- A Transparent diversifier index MUST be in the range 0 to 2^31 - 1 inclusive.
- There are no additional constraints on an Orchard diversifier index.
Note: A diversifier index of 0 may not generate a valid Sapling diversifier (with probability 1/2). Some wallets (either prior to the deployment of ZIP 316, in violation of the above requirement, or because they do not include a Sapling component in their UAs) always generate a Transparent P2PKH address at diversifier index 0. Therefore, all Zcash wallets, whether or not they support Unified Addresses, MUST assume that there may be transparent funds associated with diversifier index 0 for each ZIP 32 account, even in cases where the wallet implementation would not generate a Unified Address with that index for a given account. This is necessary to ensure reliable recovery of funds if key material is imported between wallets.
@hahn chose not to comply with these specifications in Ywallet (which he is entitled to do, no matter how irritating it is), but we added a workaround —the last paragraph above— to allow compliant wallets like Zashi to see funds created by Ywallet. We cannot do anything to force Ywallet to follow the spec and see funds created by Zashi.
The issue is that when a user recovers a seed from Zashi that uses a non-zero index, they will not see the funds because their wallet assumes the funds are in address index 0.
Btw, it’s not only Ywallet. Every transparent wallet starts at 0.
Most transparent wallets perform gap-limit style handling, where they scan a series of addresses to find funds, in case a user has done address rotation and have given out addresses but have not received funds on those addresses; this is an entirely possible case (for example, on an old Ledger I had I rotated addresses but never received funds on the zero address.)
Any wallet that does gap-limit handling will find transparent funds sent to the default Zashi transparent receiver.
1 Like
I chose not to follow this because it came after a bunch of users have their funds at 0 and I don’t want to move their funds. You may not like it but that happens when specs are written after products are released.
My new wallet uses the same address index as ZIP-316.
1 Like
- We’re not asking to move users’ funds (for this reason). We’re asking for Ywallet to scan the addresses that are specified in ZIP 316, so that it finds the funds of other wallets. We’ve done the converse in
zcash_client_backendand Zashi. - What’s the difficulty in moving funds? This is functionality that is needed anyway: migrating from Sapling to Orchard, for note management, etc. It will also be needed to migrate from Orchard to quantum-resilient Orchard or any future pools.
I am not questioning your rationale, but pointing out that when you introduce new behavior that is not backward compatible, users won’t be able to transfer from Zashi to an old wallet.
That’s absolutely not true. If it were true that there were a fundamental incompatibility between wallets that put funds at different addresses, then users wouldn’t be able to transfer a seed phrase from a pre-ZIP-316 wallet to a ZIP 316 one either — but they can. The incompatibility is only on the Ywallet side because you refuse to change its behaviour.
It should not be difficult for the user. I just don’t want the wallet to do any transaction on the user’s behalf. That is important to me. I would get upset if my bank did that.
I know Zashi does on auto shielding, etc. So if users want that, they can migrate to it.
You mean if I was scanning also the other address index?
1 Like
Zashi does not currently do auto shielding. It will soon, but it doesn’t now; shielding is only triggered manually. So that can’t be (and isn’t) the reason why Zashi can see Ywallet’s funds but Ywallet cannot see Zashi’s funds.
Yes. Ywallet would also need to scan with internal viewing keys to see all shielded funds. (The transparent equivalent is just the corresponding change address.)
It’s a technical limitation. The code does not support notes at multiple transparent addresses.
That’s why if someone wants to use a Zashi or Ledger account, they have to sweep/consolidate.
Ok, then, you should document and describe it as a technical limitation of Ywallet, instead of repeatedly casting aspersions on other wallets.
1 Like
What aspersions? Please provide a quote.
The only thing I said is that Zashi sometimes does not use the index 0.
I think having this option configurable is important too 
1 Like
example: How to Switch ETH Path to Ledger Live / Legacy Format? | Keystone Support
At the end of the day, I think it’s in everyone’s best interest that whenever a user picks a wallet and insert their passphrase they’ve used a while ago, on another wallet, funds are not missing.
I agree with you. There are legitimate security, confidence, accounting etc. reasons why some users may only want transactions to be triggered manually.
Additionally, hardware wallets can’t auto-shield because they require a user to get the hardware ready and confirm the transaction (this is a bit of a simplification because you could bundle transactions, but that likely runs up against memory limits). Therefore, any wallet that supports both hardware wallet integration and auto-shielding, like Zashi, still has to have code for manual shielding and the associated UI flows.
So it makes sense to me to make it configurable on the software side. In the case of Zashi, it’s up to the ECC wallet team to decide on this but I’ve expressed this opinion to them.
Edit: the wallet team have confirmed this is how it is designed so far.
3 Likes