Andy Schroder [ARCHIVE] on Nostr: 📅 Original date posted:2018-03-21 📝 Original message: Andy Schroder On ...
📅 Original date posted:2018-03-21
📝 Original message:
Andy Schroder
On 03/19/2018 09:59 AM, Corné Plooy wrote:
>> 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. Over time, the risk increases that knowledge about the node ID
> (e.g. what kinds of transactions are linked to this ID) leaks out and
> gets combined, revealing things you don't want to be revealed.
>
> It may, for instance, be that some of your incoming transactions are
> inherently linked to your physical identity (e.g. salary), and some
> other you don't want linked to yourself. If you have to reveal your node
> ID to all payers, you risk those transactions being linked to you,
> either now or in the future. Running a node as a TOR hidden service is
> not sufficient. However, if you manage to hide your node ID from payers,
> this becomes much more difficult; you really gain some privacy.
>
> In fact, using a TOR hidden service may not always be necessary. In some
> cases, you could alternatively set up payer/payee communication over a
> more-or-less anonymous physical medium; maybe using a burner phone, WiFi
> with a randomized MAC address, NFC, or some other kind of radio
> communication.
Regarding NFC and radio communication, I think this would be important
to bake into the original spec. I'm going to encourage bluetooth over
wifi with a randomized MAC address. Bluetooth is likely a little better
because you can make a lot of simultaneous bluetooth connections and
they don't require you to do any changes to your internet connection,
which you still need in order to interact with the bitcoin and lightning
networks. Bluetooth also makes it simpler for the payee as far as
limiting what the payee can use the connection for. I'm guessing you can
randomize the bluetooth MAC address.
One thing for example that makes BIP70 complicated in that regard is
that you need to be able to supply a few URLs in order to give the payer
an option on how they may want to connect to fetch a payment request
(locally via bluetooth, or over the internet using http). Some hacks
were made to BIP70 to make it work with bluetooth, but I'm not sure if
the design was the best.
* Demo using my fuel pump and Bitcoin Wallet
o http://andyschroder.com/BitcoinFluidDispenser/2.3/
+ Watch the first video on this page.
+ I don't think totally offline payments are possible with
lightning, so that part of the workflow isn't comparable.
* Details about how Bitcoin Wallet is designed and different ways to
communicate with the payee.
o https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki
o https://github.com/bitcoin-wallet/bitcoin-wallet/wiki/Payment-Requests
o Note, the bluetooth communication protocol used here still needs
to be encrypted. That extension was never developed.
Obviously we aren't going to use BIP70 here for lightning, but my point
is that there are some lessons that can be learned from the work flow.
>
> The alternative approach to partially payee-determined routes would be
> to run different nodes for different identities and to regularly shut
> down nodes and set up new ones. This requires expensive on-chain actions
> though (more expensive than setting up a new TOR hidden service), and I
> don't think it's good for the rest of the network either if channels are
> regularly shut down.
Definitely.
> I prefer if people can have lots of privacy, even
> when running only a single node.
>
> You could roughly say that TOR is necessary because your IP address can
> often be linked to you, and partially payee-determined routes are
> necessary because your node ID can often be linked to you.
>
> CJP
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180321/2fb57639/attachment-0001.html>;
📝 Original message:
Andy Schroder
On 03/19/2018 09:59 AM, Corné Plooy wrote:
>> 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. Over time, the risk increases that knowledge about the node ID
> (e.g. what kinds of transactions are linked to this ID) leaks out and
> gets combined, revealing things you don't want to be revealed.
>
> It may, for instance, be that some of your incoming transactions are
> inherently linked to your physical identity (e.g. salary), and some
> other you don't want linked to yourself. If you have to reveal your node
> ID to all payers, you risk those transactions being linked to you,
> either now or in the future. Running a node as a TOR hidden service is
> not sufficient. However, if you manage to hide your node ID from payers,
> this becomes much more difficult; you really gain some privacy.
>
> In fact, using a TOR hidden service may not always be necessary. In some
> cases, you could alternatively set up payer/payee communication over a
> more-or-less anonymous physical medium; maybe using a burner phone, WiFi
> with a randomized MAC address, NFC, or some other kind of radio
> communication.
Regarding NFC and radio communication, I think this would be important
to bake into the original spec. I'm going to encourage bluetooth over
wifi with a randomized MAC address. Bluetooth is likely a little better
because you can make a lot of simultaneous bluetooth connections and
they don't require you to do any changes to your internet connection,
which you still need in order to interact with the bitcoin and lightning
networks. Bluetooth also makes it simpler for the payee as far as
limiting what the payee can use the connection for. I'm guessing you can
randomize the bluetooth MAC address.
One thing for example that makes BIP70 complicated in that regard is
that you need to be able to supply a few URLs in order to give the payer
an option on how they may want to connect to fetch a payment request
(locally via bluetooth, or over the internet using http). Some hacks
were made to BIP70 to make it work with bluetooth, but I'm not sure if
the design was the best.
* Demo using my fuel pump and Bitcoin Wallet
o http://andyschroder.com/BitcoinFluidDispenser/2.3/
+ Watch the first video on this page.
+ I don't think totally offline payments are possible with
lightning, so that part of the workflow isn't comparable.
* Details about how Bitcoin Wallet is designed and different ways to
communicate with the payee.
o https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki
o https://github.com/bitcoin-wallet/bitcoin-wallet/wiki/Payment-Requests
o Note, the bluetooth communication protocol used here still needs
to be encrypted. That extension was never developed.
Obviously we aren't going to use BIP70 here for lightning, but my point
is that there are some lessons that can be learned from the work flow.
>
> The alternative approach to partially payee-determined routes would be
> to run different nodes for different identities and to regularly shut
> down nodes and set up new ones. This requires expensive on-chain actions
> though (more expensive than setting up a new TOR hidden service), and I
> don't think it's good for the rest of the network either if channels are
> regularly shut down.
Definitely.
> I prefer if people can have lots of privacy, even
> when running only a single node.
>
> You could roughly say that TOR is necessary because your IP address can
> often be linked to you, and partially payee-determined routes are
> necessary because your node ID can often be linked to you.
>
> CJP
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180321/2fb57639/attachment-0001.html>;