There are 2 problems with blinding receiver address using nonces when doing payments (not operations with venue!):
1) It puts additional burden on the participants, since they need to coordinate value of the nonce with other side.
2) It is opt-in - picking default value of the nonce (e.g. zero) works just as well, no need to coordinate it.
3) It does not provide significant benefits to the participants. Privacy gains are small.
We rely on blinding of payments with nonces to generate anonymity set for deposits to a venue. Without anonymity set deposits to a venue leak information about intent to sell the token.
At the moment we know of two other possible ways of addressing this problem.
New address for every transaction
Use new addresses for every payment; generated by receiver. Impact on the contract is very low.
Problems:
Still opt-in, but at least it is a bit cheaper and simpler.
Requires wallet support.
Requires active receiver generating addresses for every payer, requires tracking of generated addresses.
Dual-Key Stealth Address Protocol (DKSAP)
Allows sender to create a keypair for receiver in such way that private key is known can be computed only by the receiver.
Problems:
Still opt-in. Unless we find a way to make it obligatory and enforce it.
Requires wallet support.
Receiver keypair becomes two entities: scan keypair stored by watcher and publicized by the receiver, and spend keypair, that may be stored offline.
Introduces bandwidth overhead - 32 bytes of additional data needs to be send.
Watcher would need to perform additional computation to determine if newly generated UTXO belongs to address watcher is tracking. Affects watchers proportionally to the amount of addresses they watch chain for.
There are 2 problems with blinding receiver address using nonces when doing payments (not operations with venue!): 1) It puts additional burden on the participants, since they need to coordinate value of the nonce with other side. 2) It is opt-in - picking default value of the nonce (e.g. zero) works just as well, no need to coordinate it. 3) It does not provide significant benefits to the participants. Privacy gains are small.
We rely on blinding of payments with nonces to generate anonymity set for deposits to a venue. Without anonymity set deposits to a venue leak information about intent to sell the token.
At the moment we know of two other possible ways of addressing this problem.
New address for every transaction
Use new addresses for every payment; generated by receiver. Impact on the contract is very low. Problems:
Dual-Key Stealth Address Protocol (DKSAP)
Allows sender to create a keypair for receiver in such way that private key is known can be computed only by the receiver. Problems:
There might be other solutions for this problem.