Nostr Web Client

Maybe so, but some information is safer to reveal than others

Option A: the receiver gives the sender a one-time payment string, the sender pays it, and the the receiver irrecoverably discards every trace that he ever had the payment string

Option B: the receiver gives the sender a reusable payment string, the sender pays it, and they both keep the string forever

The latter is worse for privacy because the shared piece of data ties the sender and the recipient together, it stands as an everlasting proof that they interacted. At least one of them should discard it because if it is found on them both, it is evidence that they once interacted. But there is only one way for each to be sure that at least one of them destroyed it: destroy it yourself.

This is not encouraged in monero; on the contrary, the standard contact list feature encourages the sender to keep the receiver's monero address and reuse it, and the standard recommendation for the receiver is never to delete his private keys, because someone might send him money at an old address, not knowing he deleted the keys.

mister_monster 6mo ago

Well, this is all 100% true. Us Monero dudes often say "this is a known issue and we are taught never to re use subaddresses" and while that's true, they're deterministically generated from our private key and so cannot be deleted, and it is taken for granted that we will reuse them so much that it is encoded in our UX for basically every client. Still, I would say that as a privacy shortcoming, this is the least detrimental one to have, but youre right, that doesnt mean it doesnt need a solution.

You might find this interesting, in MW, transactions are sent side channel and must be signed by both parties. This works like an ephemeral record of who is paid, all the sender has is an email address or something that they do not have to keep indefinitely, like option A above. The signatures are schnorr signatures and so what gets written to the chain is a combined signature that nobody but the parties to it can tell they were parties to it. And, ultimately the only thing that is needed for consensus is the UTXO set, so once the recipient spends the output it is no longer kept as a record, in contrast to literally all other blockchain protocols. The shortcoming with it is that this deleting of old transactions cannot be forced on all nodes, so while those transactions are not needed for consensus, a node choosing to keep them anyway can probabilistically put together a graph of counterparties from them over time. This is actual tracing by third parties and so the trade off here is not worth it privacy wise.

Reply to this note

Please Login to reply.

Discussion

Saberhagen The Nameless 6mo ago

Subaddresses are deterministically generated, but have a massive space of 2^96 possible subaddresses per private key (virtually endless for all practical purposes). I could be wrong but I think you could technically choose a random range where the index would start. It would basically be impossible to find your transactions for an adversary even if they somehow got ahold of your private keys. I don't know any wallet that has this option built-in and not sure how practical it would be since you would have to save that index range somewhere along with your private keys. I think wallets should provide users an accessible way to do this though if they wanted to.

MW is great. There are no addresses on the blockchain, period, not even stealth addresses. I like Grin and LTCMWEB, and Beam is doing some cool things. But you already described the problem that an active malicious node could simply save that info in the mempool to put together a transaction graph. It would only be able to see from that point forward, but it is pretty weak privacy as far as hiding transaction graphs go.