Been spending some time looking at the design of Silent Payments, just from a crypto point of view. Overall I like it; the only wiggle room for attack I can find so far is if the spending key is somehow a key that itself previously existed and was used for something, which it never would be. I see basically no attacks that make sense, so far. If I have a complaint about the BIP, it's that it isn't as clear as it should be about what privacy guarantees it's claiming (though the common sense reading seems to be right; it should be explicit though). Obviously the way out there stuff, like inputs that are from MuSig2/FROST, or coinjoins, which are pointed at in the BIP, are very much uncharted territory and would be hard to get right, but for now I think that is just not going to happen. Anyway I'll keep looking.
#cryptography #bitcoin
Login to reply
Replies (4)
For example: for receiver B, and multiple payers A_i, we want this: payments P_i are not linkable to B, except payment P_i is linkable to B by payer A_i (of course!). Thinking in this way allows you to realize for example that the effectiveness of SilentPayments may crucially depend on B's spending policies. (in the ideal case: B only receives coins via this protocol and only co-spends utxos that were created with it; you can satisfy yourself that in this case the non-cospent utxos should not be linkable. Or maybe you can't. But that's the kind of thing I think is worth investigating. A bit beyond a BIP of course, maybe, likely, someone has already done it.)
Silent payments has 2 basic problems:
1. Scanning requirement
2. No privacy if multiple inputs are used together in a transaction later
Interesting thought for sure. Obviously *any* out of band could work (with clearly some tradeoff), nostr fits particularly nicely. I'll read it more.
