[Lightning-dev] Onion-Routing for Messages

Mats Jerratsch mats.jerratsch at blockchain.com
Wed Dec 9 09:45:20 UTC 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

> I have sort of lost track of preferences regarding what is to be
> sent through onion routing versus what's not...

Agree, it hasn't been on list for quite some time, the last time we
discussed it, we only included the route in there.

http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-October/00
0247.html

Back then only the pubkey of the next hop has been part of the onion
object, with no additional message to the final receiver. For having
the added privacy of changing R value we would probably add a random
number in there as well.

> Originally I had assumed that some out-of-band messaging would be 
> taking place (like an equivalent to a BIP70-style payment
> protocol). Rather than a single QR code, I was expecting an
> interactive wallet-to-wallet protocol while both sides are busy
> communicating with the onion routing network for the actual payment
> route negotiation stuff. When they ultimately find that no
> sufficiently cheap route exists, then the wallets would opt to
> create a new payment channel in some circumstances.

Interesting. I think the important term here is 'out-of-band', as I
would implement above using the actual lightning network. But I also
fail to see how to implement a secure and private communications. I
guess one way would be to have wallets open up a hidden service on TOR
and take payment requests on a service listening there. But it would
not exactly reduce complexity nor would provide sufficient defense
against DoS attacks. Everything simplifies a bit when we assume these
communications using non-private way as simple
HTTPS-requests-responses, but I think we are sacrificing too much
privacy on the way.

> Once a path is found, the recipient would then communicate over
> the wallet-to-wallet channel to pass over the fully-constructed
> onion routing information. Sending that data back over the onion
> routing network may not be necessary. Unfortunately this increases
> the complexity of the payment side (wallet-to-wallet), but
> meanwhile makes for less message passing in onion land, which could
> make the problem easier to think about?

Do you mind defining wallet-to-wallet channel a bit more? Which
techniques could/should they use without leaking information?

Yes, we would increase the total load for the nodes if they should
handle these additional messages. But I think we can go with a
simplified message-delivery-system where each hop costs like 1 satoshi.
I call it simplified, because we are not using the a HTLC, but just
rebalancing the unencumbered outputs of the commit transaction.

As the sender of a message you can go to the first node and give him
30 satoshis for opening the onion object and passing the message to
the next node as instructed in the onion object. It would pay the next
node 29 satoshis, and so on. These would not be enforcable on the
blockchain, so a dishonest node could just keep the 29 satoshis and
not deliver anything at all. However, if you receive a message to
relay it, it is a strong indication that there is a payment to follow
up to that message. The general incentive is to relay these messages,
as fees of payment are likely higher. Given that we can have
sub-satoshi payments too, we might want to tune the cost-per-hop to
make it substantially less than any fees you could get of the payment.

If it remains a problem (and some people could just join the network
and not relay anything just for the sake of it), we might either find
a way to proof this behavior or even use HTLCs for these, even though
that would probably be not practical and bloat commit transactions
waay too much.


- -- 
Mats Jerratsch
Backend Engineer, Blockchain
e: mats.jerratsch at blockchain.com
PGP: https://pgp.mit.edu/pks/lookup?op=get&search=0x7F3EC6CA
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWZ/gwAAoJEAYZmwZ/PsbKv4MQAKxoeZ+G3ozifODlY7nhqYeE
GQChU8DyDal8tAn1Bgb44s7SZMltSgpL9RR2G51/Cn0pygPMPUkT9OS5mRNMlEA1
s1JZ3annaxkJslUlFeF86Tw1MC8LhFYi/WbnJoCPElTmR1PljOtCmpUpjlrDMx7N
YNyjD/zUR+N1ZMqZh0q5okoZegyOkgo0biT5RHrjALUEnK3qWh/PCwUHXYdN/l22
h0LaEi0ajTFhEPNygSFz3Z13KmwYvsmsHl9MydweLbKARx6wo7OPxOWbuNVqD7xF
4eGgkniQZgZM+8owYFifXn/XVGj65PLQaqCN0o/gmCKphqjgoPWtbcJtKg8NtShN
6AI54ZqAtqh4IxpOZRBm2OiFW5TTou/XICDrCS/mfCNtv0wYNANop9+WQ/KTfStx
KnL986TDww5XkLws30Q9C6qFpBjwEgmTmGibvCM8z+HPe223kW0ElofLrWmvqyso
Ncj+iKj91cJLbs3XuzZ6pMgBwhW0ERSRj4bUm6r/oApSRyxYNNLVchOFhU9eWJxu
dhJul2ACFpcTql2zQOUhUe3PXD6M3cRpyLgeqRMNGNNs4+3eTnFdNiqWjK+QIIvZ
uFWpUDcPh3TJSh7TBZCHSxtAIHpCUyPL8u/LV6oZ4PHSd5aLMMm5tq95ViDNzAvm
ARTMgJtNA6q4CYlUflr3
=b/hD
-----END PGP SIGNATURE-----


More information about the Lightning-dev mailing list