In Sapling, when the sender wants to send money to the receiver, he will firstly get the receiver’s diversified address. But how does the receiver generate the diversified payment address? Is the diversified address generated online or offline? How can the receiver guarantee that different senders can get different diversified address? Thanks!
2 Likes
The address generated by the client is hashed to the particular spending key so I think it would require accidentally breaking the protocol along with an astronomical amount of luck (what were the possibilities now? 2^256?)
Thanks for your reply.
But my question is why different sender can get different payment addresses in Sapling version Zcash. We know that the payment addresses of receivers are diversified, and generated roughly like this: receiver picks a random d, and use it to get a gd. Finally, he combined his incoming viewing key with the gd and get the pkd. But the question is how the receiver can guarantee that the sender can get the pkd distinctly. It is generated online? But I could not find any clue about this in the zcash protocol specification. Do you know about the detail about this? Thanks!
John Bruhling via Zcash Community Forum zcash@discoursemail.com 于 2019年12月6日周五 上午12:25写道：
Online or offline probably wouldn’t make a difference because you can’t cross reference against shielded addresses that you don’t know exist
Technically there are no guarantees but assuming your diversifier is long enough then the likelihood of a hash collision between two Diversified addresses within the same set is extremely low (nil)
I’d like to re-emphasize the fact that there are no guarantees, only strong assumptions
So in conclusion, who do you think picks the diversifier d, which later is combined with the incoming viewing key to generate the pkd？Sender or receiver？
John Bruhling via Zcash Community Forum zcash@discoursemail.com 于 2019年12月6日周五 下午8:48写道：
Thanks for your reply. But I still don’t know how the receiver’s payment address is generated. Because according to the specification protocol, the pkd := KASapling.DerivePublic(ivk, gd), which means that you need an incoming viewing key to derive the public key. But the incoming viewing key is a private key of the receiver. So it means that it can only be generated by the receiver. And if we want the pkds to be distinct for different senders, it seems that it need be to online for the receiver’s key generation program. I just want to know if it turns out to be like what I think(need be to online). Can you tell me this exact answer. I could not find it on the protocol. Thanks.
Yes, it’s clear that new diversified addresses can only be generated by the receiver.
Note that use of multiple diversified addresses for a spend authority is an entirely optional feature (and in fact is not fully implemented in zcashd, which will only generate a single diversified address for a given spending authority).
1 Like
Thanks for your reply. By the way, may I ask that why the sapling version should be updated like that(only the receiver can generate the payment address)? I don’t think the previous version is insecure.
It has always been the case that the receiver (or more precisely, anyone who knows the receiver’s incoming viewing key) generates their payment address.
In Sprout, the incoming viewing key is (apk, skenc) and the payment address is (apk, pkenc). Only the recipient knows skenc and can derive pkenc.
In Sapling, the incoming viewing key is ivk and the payment address is (d, pkd). Only the recipient knows ivk and can derive pkd 
(gd, ivk). This also means that while the sender can derive gd d, they cannot derive an arbitrary diversified address (because they cannot derive pkd for arbitrary d without ivk).
This is correct. Note that ivk also needs to be online to detect and decrypt incoming payments, so this falls within the expected usage model. The key hierarchy is designed to enable different privacy levels for different key material; in particular, viewing keys can be kept online to enable live detection of payments and live derivation of diversified addresses, while spending keys can be kept offline for optimal security around spending funds.
2 Likes
Thanks for your reply.
However, sender could not generate the d by themselves(Because * d j = FF1-AES256.Encrypt( dk , “”, I2LEBSP88( j )). ), while in monero or sprout, sender can generate the one-time payment address for the receiver, which i think is more convenient. If it is required to be online to get the one-time pk for the receiver, it may become insecure.(for example, it can be detected by the adversary. And then the adversary can know this sender will send something to the receiver.) Am I right?
This is correct, but not for the reason you state. The derivation algorithm for d you reference is only there so that the d values in addresses can be deterministic yet pseudo-random (so e.g. exchanges can use user IDs to derive d values without leaking those user IDs); it has no effect on the rest of the key structure.
Sprout doesn’t have sender-generated one-time payment addresses. If you want a one-time Sprout address, the recipient needs to generate it (so that only they know the spending key).
Monero’s stealth addresses are sender-generated, in that the recipient publishes a single public address and then the senders can actually send funds to random addresses that the recipient did not decide on in advance but that they can receive on. (The underlying cryptography enabling this is very similar to how Zcash’s diversified addresses work). However, I consider this to not be particularly reliable for providing recipient privacy, because it relies on the recipient trusting the sender’s wallet to perform this randomization. It is entirely possible for the sender to use the same address for multiple payments, linking them together, and the recipient is unable to prevent this. Meanwhile, the recipient’s viewing key is still necessary to receive incoming Monero payments, and needs to be online at some point.
Putting this aside, per-payment address randomization isn’t necessary for privacy in Zcash shielded transactions, because the recipient address is encrypted in the transaction and is thus not visible, so cannot be used to publicly link the transactions without knowing the recipient’s viewing key.
“Detected by the adversary” is too broad of a threat model. Is the adversary breaking into the recipient’s machine, or only observing network traffic, or something else? The fact that the recipient’s viewing key is “online” to derive a new diversified payment address doesn’t have any effect on network traffic patterns:
- In a merchant-customer use case, there is network communication in any case to negotiate the sale.
- In non-interactive transactions, the sender already needs to have obtained an address at some point in the past, and either that process is interactive (in which case the adversary would know anyway that a transaction might occur at some point), or the sender finds the address on some public board (in which case they just use the same address as everyone else, which as above is fine because the adversary can’t tell which address a sender is sending to).
tl;dr the design goal for diversified addresses is performance: enabling a recipient to give out unique addresses that can all be scanned by the same viewing key. This use case is important for many-to-one interactions like an exchange with millions of users, but the diversified addresses themselves don’t have any effect on what can be discerned from a transaction’s contents.
3 Likes
Thanks for your patient reply.
Yes, what I concern is that the adversary will observe the network traffic and know anyway that a transaction might occur at some point. So your opinion is that although the this might be the case, the advantage brought by the diversified address scheme far outweigh its disadvantage?
str4d via Zcash Community Forum zcash@discoursemail.com 于2019年12月19日周四 上午11:44写道：