Good morning Corne,
> > I suppose the use-case here is that the payee uses many TOR addresses with > > only one LN node. > > Yes. Use different TOR addresses for things you want to keep separated. > > Any TOR address you advertise for channel connections is so widely > > shared through gossiping that you can in practice consider such an > > address to be the same identity as your peer ID. For the payer/payee > > communication (BOLT 12, and other interfaces such as a website) you > > should not use the same TOR address if you want that activity to > > remain unlinked from your node ID. You could use another TOR address, or > > any other pseudonymous communication method. I understand. I want to bring up another possible privacy break. Channels can be brought onchain anytime, and any HTLCs pending through that channel will also be brought onchain and will be visible. This will also publish the `payment_hash`. A payer observing the chain knows the `payment_hash` it was paying to, can see the HTLC getting claimed and exposing the `payment_hash`, and from the channel signatures knows which nodes were using that channel (if it was a public channel then it has signatures attesting who the nodes participating in it are, from node gossip!). It can guess that it is likelier than usual that one of the nodes on that channel is the payee, and definitely knows that the channel was part of the payee-provided route. (using non-public channels helps here in that the payer would have to observe every possible HTLC claim, not just those that it knows are from the public channels on the network, and would be hoping that such an event occurred during its payment: so it would have to devote more bandwidth and processing power searching through all transactions for an HTLC claim that matches its `payment_hash`. But I think there is no such thing as a truly private channel: each channel has two participants and two can keep a secret only if one of them is dead) This is not such a big concern; this is expected to be a rare case and if your node accepts received HTLCs very quickly and has very good uptime it is unlikely to occur in practice. In addition, once we switch to Scriptless Script (which requires Bellare-Neven signatures to be implemented in some form on the base Bitcoin blockchain layer) this privacy leak disappears (I think... or maybe greatly reduces at least), as even onchain the equivalent to a hashlock is indistinguishable from an ordinary Bellare-Neven m-of-n signature. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
