ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-03-16 📝 Original message: Good morning Andy, > > > ...
📅 Original date posted:2018-03-16
📝 Original message:
Good morning Andy,
> > > giving new alternatives
> > >
> > > interactively is another option. I think using the same "introduction
> > >
> > > point" for all routes is best for privacy: otherwise the payer could
> > >
> > > determine the neighborhood of the payee.
> > >
> >
> > I wonder. How does the payer contact the payee in the first place, without having located the neighborhood of the payee? If it is via some TOR hidden service, and the payee considers this enough protection, why cannot the same TOR hidden service be used as the address of the LN node of the payee (LN protocol spec allows this, current implementations not so much)? Freenet or I2P, I suppose?
>
> You're saying that a .onion address is really a public key, so their is
>
> no reason to include both a public key and a host name?
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?
Regards,
ZmnSCPxj
📝 Original message:
Good morning Andy,
> > > giving new alternatives
> > >
> > > interactively is another option. I think using the same "introduction
> > >
> > > point" for all routes is best for privacy: otherwise the payer could
> > >
> > > determine the neighborhood of the payee.
> > >
> >
> > I wonder. How does the payer contact the payee in the first place, without having located the neighborhood of the payee? If it is via some TOR hidden service, and the payee considers this enough protection, why cannot the same TOR hidden service be used as the address of the LN node of the payee (LN protocol spec allows this, current implementations not so much)? Freenet or I2P, I suppose?
>
> You're saying that a .onion address is really a public key, so their is
>
> no reason to include both a public key and a host name?
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?
Regards,
ZmnSCPxj