[Lightning-dev] Onion-Routing for Messages

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

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.


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
Comment: GPGTools - https://gpgtools.org


More information about the Lightning-dev mailing list