Silent payments BIP

[josibake]

No description provided.

[RubenSomsen]

Nice work!

[murchandamus]

Reads well, really clear already. Left a few comments and suggestions.

[murchandamus]

Isn’t that obvious already, because the scan key is the same anyway?

Perhaps it should be explicitly pointed out somewhere that the labels are not sufficient to hide that multiple different addresses are owned by the same recipient. (It’s obvious to me, now that I think about it, but wasn’t at first until I realized that the other public key is still part of the address.)

[RubenSomsen]

Shouldn't i and n be the same letter here?

[nikkisigurdson]

Hello! Overall, this is a interesting idea, and I enjoyed reading the draft. Since this payment method is being proposed specifically to offer strong theoretical privacy properties, I thought I would take a look. My background is in research cryptography, so my focus while reading the document was on analyzing the mathematical parts in the Overview section for the listed goal privacy properties. I read the entire Overview section, and I haven't found any issues with the cryptography being used (with regards to the listed goals). The two goals I looked at the most carefully (and are most cryptographic in nature) were:

• "Transactions can’t be linked to a silent payment address by an outside observer"
• "No linking of multiple payments to the same sender"

Here are a few other thoughts I have from a cryptographer's perspective:

1. If Bob's silent payment address B is public information (as one may wish to do so for instance in a donation use-case), then why bother adding it to the end of the destination output P = HASH(a·B)·G + B for Bob? What properties do you lose when you remove it? (Since the value a·B is assumed to be completely secret to anyone outside of Alice and Bob, so we don't offer privacy guarantees when a·B, a, or b is leaked.) Answer: I found the answer to this question, and it is that if you remove the added B, then it is no longer the case that only Bob can spend the output. This is because for P = HASH(a·B)·G + B, the discrete log of P is HASH(a·B) + b, and only Bob knows b.

2. (I point this out because it was not immediately obvious to me when first reading this.) It is crucial for the desired privacy properties of this protocol that the value a·B (Diffie-Hellman keys between Alice and Bob) are kept secret from all third-parties. The reason is because if some third-party Carol knew a·B, she could break several of the listed properties, such as linking multiple payments to the same sender, and linking a transaction to a silent payment address by an outside observer. But since Diffie-Hellman keys are often thought of as "safe-to-reveal-to-the-public" values, it may be useful to clarify the fact that a ·B must be considered secret data in this protocol. In general, it may be worth exploring what privacy losses occur if the secret data (a,b, or a·B) from a Silent Payment get leaked. If b got leaked, what loss of privacy does Alice experience? Similarly, what loss of privacy does Bob experience if a got leaked? Is the damage for leaked secret data as bad in Silent Payments as for any other type of existing Bitcoin payment?

3. It may be useful to observe that in the goal "Transactions can’t be linked to a silent payment address by an outside observer", you can easily define "outside observers" as any party who does not know a or a·B. Further, you can actually define protocol participants Alice and Bob as those who know the respective values (a, a·B) and (b, a·B). This may be helpful in formally defining the privacy properties you wish to achieve.

4. It seems that "forward secrecy" type properties are not useful in this context, where forward secrecy preserves privacy properties even if the secret data retroactively got leaked after a Silent Payment was made. (https://en.wikipedia.org/wiki/Forward_secrecy) I thought it would be useful to point out why these rightfully shouldn't be cryptographic privacy goals for Silent Payments.

[RubenSomsen]

@nikkisigurdson thanks for taking the time to look over the proposal. It's reassuring to hear you haven't come across any issues with the cryptography being used.

1. That is correct. Incidentally, it also allows us to have a separate key for scanning and spending.

2. Yes, that is a good point regarding the need of keeping the shared secret hidden from public, and worth mentioning explicitly. If a*B, b*A or a is leaked then the output(s) of that specific transaction (containing the inputs that add up to A) can be tied to the recipient. This seems a bit worse than Alice simply telling the world they paid Bob, since now there's cryptographic evidence that Bob received the payment. If b (or more specifically b_scan) is leaked then the recipient (Bob) loses all privacy (anyone can scan for all of the recipient's received payments).

3. Another excellent point. Outside observers are basically anyone who doesn't know a, b, a*B, or b*A. It seems useful to define it as such in order to be more precise in our wording.

4. Good question/comment. Off the top of my head I see two fundamental reasons: a.) you actually want to actively preserve the secret data in order to be able to recover from backup. b.) you are dealing with different senders each time that have no ability to interact with the recipient, so you can't establish new secrets.

Thanks again for sharing your thoughts, this was helpful.

[theStack]

Concept ACK

Left some comments below, a deeper review round will follow soon (tm)

[josibake]

opened against the bips repo here: bitcoin#1458