ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-03-19 📝 Original message: Good morning Corne, > > ...
📅 Original date posted:2018-03-19
📝 Original message:
Good morning Corne,
> > It is a public key hash, yes. But what I refer to is that the payee-determined route section, which starts from an introduction point, protects the payee from being located by the payer, but how did the payer contact the payee in the first place anyway? If it was by IP or non-.onion hostname, then the payee has been already located and there is no point in hiding from the payer. If it was by .onion hostname, then the payee security is bounded by the security of TOR, so it is no more secure for the payee to simply run its LN node on the same .onion address (which LN spec supports) and provide the public key of its LN node.
> >
> > Note that onion routing on LN in general protects the payer and the payee from being known easily by intermediate hop nodes, and this is the sole intent of onion routing for now. Presumably the payer knows how to contact the payee (else how would it form a connection to the payee in order to make an interactive request for invoice?). Presumably if the payee is a merchant, it knows how to send its product to the payer (and thus would know details like the physical address of the payer). And so on. The payee-determined route that starts from the introduction point protects the payee from the payer, but does it indeed increase the security or is there some other way to locate the payee anyway?
>
> If that payee has a LN node that is 100% a TOR hidden service, and you
>
> don't use a (partially) payee-determined route, the payee has to reveal
>
> its node ID to the payer. This is not the same as revealing the physical
>
> identity of the payee, and having a hidden service may help to keep the
>
> two identities separated, but a LN node is a relatively long-lived
>
> entity.
The LN node is long-lived, but the TOR address it uses is not long-lived? LN nodes need to communicate with counterparties, and if the connection breaks, you need to get in contact again, else the channel is unuseable.
Admittedly an LN node may change its TOR address by re-gossiping a new TOR address, though, so I suppose that is a possibility. But that still links LN pubkeys with TOR addresses anyway.
I suppose the use-case here is that the payee uses many TOR addresses with only one LN node.
Regards,
ZmnSCPxj
📝 Original message:
Good morning Corne,
> > It is a public key hash, yes. But what I refer to is that the payee-determined route section, which starts from an introduction point, protects the payee from being located by the payer, but how did the payer contact the payee in the first place anyway? If it was by IP or non-.onion hostname, then the payee has been already located and there is no point in hiding from the payer. If it was by .onion hostname, then the payee security is bounded by the security of TOR, so it is no more secure for the payee to simply run its LN node on the same .onion address (which LN spec supports) and provide the public key of its LN node.
> >
> > Note that onion routing on LN in general protects the payer and the payee from being known easily by intermediate hop nodes, and this is the sole intent of onion routing for now. Presumably the payer knows how to contact the payee (else how would it form a connection to the payee in order to make an interactive request for invoice?). Presumably if the payee is a merchant, it knows how to send its product to the payer (and thus would know details like the physical address of the payer). And so on. The payee-determined route that starts from the introduction point protects the payee from the payer, but does it indeed increase the security or is there some other way to locate the payee anyway?
>
> If that payee has a LN node that is 100% a TOR hidden service, and you
>
> don't use a (partially) payee-determined route, the payee has to reveal
>
> its node ID to the payer. This is not the same as revealing the physical
>
> identity of the payee, and having a hidden service may help to keep the
>
> two identities separated, but a LN node is a relatively long-lived
>
> entity.
The LN node is long-lived, but the TOR address it uses is not long-lived? LN nodes need to communicate with counterparties, and if the connection breaks, you need to get in contact again, else the channel is unuseable.
Admittedly an LN node may change its TOR address by re-gossiping a new TOR address, though, so I suppose that is a possibility. But that still links LN pubkeys with TOR addresses anyway.
I suppose the use-case here is that the payee uses many TOR addresses with only one LN node.
Regards,
ZmnSCPxj