[Lightning-dev] [BOLT Draft] Onion Routing Spec

Christian Decker decker.christian at gmail.com
Fri Sep 2 12:08:22 UTC 2016


I'd like to pick up the conversation about the onion routing protocol
again, since we are close to merging our implementation into the
lightningd node.

As far as I can see we mostly agree on the spec, with some issues that
should be deferred until later/to other specs:

 - Key-rotation policies
 - Backlog of seen shared secrets
 - Payload formatting (what data to include and how it is encoded)

The last pressing issue is the use of the HMAC, specifically what the
per-hop verifiable HMAC should include. Having it cover the entirety
of the packet, including the payloads, has the advantage that
corrupted packets get dropped immediately, which prevents the route
length discovery attacks Rusty described and we make more efficient
use of our funds, i.e., drop a transfer immediately not allocating
HTLCs for a payment that is destined to fail, and quicker retries.

The downside is the rendezvous problem, in which the recipient would
provide part of the onion, hence the sender cannot compute the
HMACs. We can potentially sidestep this with a partially trusted
reflector, have an interactive construction of the packet, or come up
with a new scheme ourselves. Anyway, I'm happy to shelve this aspect
for a future v2 of the onion routing protocol, and include the payload
in the HMAC.

I think for now we should also keep the payload sizes fixed at 20
bytes for per-hop and 1024 byte for end-to-end payload, and we can
discuss how to format those payloads in another spec. Since we seem to
want to add and remove bits and pieces it might be worth to make it
flexible using a generic encoding (JSON, msgpack, ...). This
potentially includes the "forward X units of coin Y" and the "expect X
units" for the endpoint. We can also address the "last-hop corrupts"
problem in the payload with an additional end-to-end secret like you
suggested. Having them in the per-hop payload and HMACing the payloads
secures them against tampering.

Let me know if there is any major thing that is not/insufficiently
addressed. BTW do we have a process in place for upgrading spec drafts
or do we keep things informal?

Regards,
Christian

On Mon, Aug 22, 2016 at 07:47:56PM +0000, Olaoluwa Osuntokun wrote:
> On Sun, Aug 21, 2016 at 1:46 PM Rusty Russell <rusty at rustcorp.com.au> wrote:
> 
> > > This may not fully solve the problem, since if one presumes that the
> > > second-to-last hop is malicious, they can re-create a new onion blob
> > > (presuming consistent hashes for each hop, of course).
> >
> > Great catch.  Oops...
> >
> 
> During the whole payment negotiation process, the sender and receiver can
> additionally agree on a shared secret-ish value (possibly the hash of the
> contract) that should be included in the per-hop payload for the final hop.
> 
> If the portion of the per-hop payload doesn't match identically with this
> value, then the payment should be rejected as a prior node has
> unsuccessfully attempted re-create the onion packet.
> 
> 
> -- Laolu

> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev



More information about the Lightning-dev mailing list