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
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
