I’m writing up a doc on how a business can accept Zcash. It includes the business owner creating a Zcash wallet. Then I need them to export an incoming viewing key and importing it into a lite wallet on a mobile device for use at each checkout counter. This should allow for monitoring incoming payments on any of the addresses included in the unified address (transparent, sapling and orchard).
Is there any Zcash wallet today that can export a unified IVK? Is there a lite wallet that can import it?
If not, what if I reduced the requirement from unified to just sapling, or just orchard?
I suspect there may be a way to export an IVK using a rust crate, but so far I only see per-pool IVK keys instead of a unified one. And I still don’t know if any lite wallets out there can import an IVK.
Note I’m asking specifically about incoming view keys. I don’t want a full viewing key because people working at checkout counters have no need to look at the business account’s balance.
Thanks. The link to the spec may be useful as I’m willing to code up the seed generation and exporting of the keys.
Of course if no wallet supports unified IVKs, I guess I’ll have to export FVKs as well to meet people where there at.
YWallet appears to be unable to export a viewing key without first having the spending key and converting the account to a viewing-only account, which doesn’t fit the use case well. But given it can export a full unified viewing key from a viewing-only account, I presume it also supports importing one. So that’s something at least.
They would not have access to any keys of the checkout system anyway since the hardware’s PIN is only known by the admin/owner.
Besides, the IVK is enough to know the business revenue, which is probably too much knowledge already.
They would not have access to any keys of the checkout system anyway since the hardware’s PIN is only known by the admin/owner.
The key would be on the system, in its decrypted form, or else the mobile wallet couldn’t do its job of decrypting incoming transactions. A PIN block would only stop the honest people.
the IVK is enough to know the business revenue, which is probably too much knowledge already.
It’s the best Zcash can do. And it’s arguably not much more than a clerk at the store already knows. They run every charge and cash payment all day, and can estimate business revenue from that if they really wanted to. And if that is too much, using a FVK instead is not a fix. But I would argue IVK is a fine place to start.
In a store with multiple registers, you can assign each register its own key so they can’t see overall store revenue.
You can import a zxview… key directly.
I’m not familiar with zxview. ZIP-316 describes viewing keys with uivk and uview HRPs. Is zxview some predecessor to that?
Anyway, I know YWallet can import a wallet by viewing key. It just seems to be missing the ability to export and import an IVK.
This post edited to remove assertion that YWallet cannot export a viewing key from an account with a spending key. The YWallet Backup command does in fact display the viewing key even from an account with a spending key.
These systems run in “kiosk” mode where app installation and most admin usage are blocked. Even if the key is in the app, it is out of the skills of 99.9% of the people to crack it. Are you thinking about another setup?
For a bigger business, that’s true. But as I’ve failed to persuade bigger businesses to accept Zcash, I’m focused on very small businesses. Businesses where they have one checkout counter, with a fully operational Windows computer. I hypothesize that the business owner will want the spending keys to be private on their home device or phone, while only putting the IVK on the checkout counter machine.
With some luck, I’ll have a conversation with one of these small business owners soon to validate that hypothesis.
Monero’s official wallet has a nice store-front mode that would be nice to emulate for Zcash. In lieu of that, my initial plan for low cost adoption for a business is just have them print out a receiving QR code for the checkout desk, and watch the IVK wallet for payment to come in.
Looking into this further, I see 5.6.3.2 states the IVK encoding is just a 32-byte ‘ivk’ value. Section 4.2.2 indicates that ivk is a hash of ak and nk, each of which are 32-bytes.
This strikes me as odd, because the full viewing key is encoded with ak and nk separately represented. Why would the incoming viewing key only contain their hash?
While I figured out in rust how to use the zcash_primitives crate to properly hash (ak, nk) → ivk, I have not been able to figure out yet how to reverse the process. And given that ivk is the result of a hash, it’s not clear to me that that’s even possible. And if not possible, how is an app supposed to take a 32-byte ivk value and actually read incoming transaction?
Or is it that ivk itself is really all you need for this, and (ak, nk) is only needed by full viewing keys? Since full viewing keys are (ak, nk, ovk), I thought (ak, nk) was the incoming key and ovk was the outgoing key.
It looks like sapling IVK encoding in the unified key assumes the incoming viewing key has the dk value handy. That makes sense, since without it I suspect it couldn’t read all the diversified addresses that payments could be sent to.
But I guess that means the hashed ivk value alone isn’t enough.
But the dk value is assumed to be 11 bytes (88 bits) long in that spec. Yet the diversifiable full viewing key’s dk value is 32 bytes long. How to reconcile this?
How I wish the specs were more clear about exactly what components made up each key.
Why does 5.6.3.2 of the zcash protocol specify that a sapling incoming viewing key is only encoded with its 32-byte IVK value, and not the diversifier key, while ZIP-316 specifies it does need the dk value?
One cannot then read the IVK encoded based on the protocol and produce a unified IVK encoding.
FWIW I found precedent for encoding the sapling IVK with the full 32-byte dk value: ivk.rs - source (docs.rs).
So while 5.6.3.2 doesn’t include dk with the IVK (I don’t even know how that works), and ZIP-316 wants an 11-byte dk value (which doesn’t exist anywhere AFAIK), it seems that the thing to do is include the full 32-byte dk value in unified viewing keys.
Can anyone confirm/refute that this is the de facto standard, or if ZIP-316 is just buggy?
Note how it uses I2LEOSP_88(dk), as if it expects dk to be only 88 bits (11 bytes) long.
I suspect the spec authors confused the diversifier key (which is 32 bytes) with the diversifier (which is only 11 bytes).
BTW, I finished my unified view address encoding code and tests. It matches YWallet’s behavior, so evidently YWallet also also uses the full 32 byte diversifier key (along with the ivk.rs file I linked to earlier).
Exploring Cash for business transactions sounds intriguing! However, I’m not sure about a Zcash wallet that can export a unified IVK for a lite mobile wallet. If not, perhaps simplifying to just sapling or orchard could be a workaround? Rust crate might have a solution, but it seems to provide per-pool IVK keys.
