From aj at erisian.com.au  Tue Oct  6 05:22:36 2015
From: aj at erisian.com.au (Anthony Towns)
Date: Tue, 6 Oct 2015 15:22:36 +1000
Subject: [Lightning-dev] Onion routing strawman proposal
In-Reply-To: <87r3l8n4x0.fsf@rustcorp.com.au> <87oagcn4v9.fsf@rustcorp.com.au>
Message-ID: <20151006052236.GA1054@navy>

On Tue, Oct 06, 2015 at 12:19:14PM +1030, Rusty Russell wrote:
> Anthony Towns <aj at erisian.com.au> writes:
> >> https://github.com/ElementsProject/lightning/pull/8
> > (This is updated correspondingly)
> Thanks, merged.

Nifty.

> I reworked test_onion and Makefile test to separate generate and
> decode;
> we should mix in the python version there too.

In onion_key.c, I don't see why you're using flip_key() -- that's only 
needed for the single use onion-msg-keys, aiui?

On Tue, Oct 06, 2015 at 12:18:11PM +1030, Rusty Russell wrote:
> Anthony Towns <aj at erisian.com.au> writes:
> >   - AES128 just uses the first half of the calculated enckey, iv and
> >     pad_iv
> True.

> >  - since libsecp256k1 already sha256s the ecdh secret; the hmac/enckey/etc
> >    end up being sha256'ed twice (with a byte added in between). confused
> >    me for a minute.
> I didn't notice that.  Perhaps this is somewhere we should optimize?

You could save a sha call by using both halves of a sha for iv and pad_iv,
rather than two separate sha's. Otherwise don't see anything obvious to
do? I assume the ECDH step dominates as far as performance goes anyway?

> PS.  Message size of 128 bytes is completely made up, as is 20 hops.  We
>      might want to reduce to 96 or 64 bytes.

I figured 20=floor(4096/192) which made sense to me. AFAICS the message
*needs* to include fee info and the forwarding address; so that's 4B and
20B-32B respectively (you could use the hash160 here and assume the
forwarding node can figure it out).

But maybe some nodes want to do clever things, like allow you to tell it
to deliberately delay forwarding for an hour or two, or deduct (different)
fees from multiple HTLC's simultaneously. But I guess 64B is probably
plenty for that?

Other thing is if you want to redirect an onion routed payment (which we
talked about as a possibility originally, as compared to only allowing
source-based routing). ie, a HTLC is sent from A to B->C->D->E, but
C actually needs to send it to D via X->Y->Z->D rather than doing it
directly. AFAICS, in that case you need to add and drop hops, ie:

   A->B:  - - - - - - - E D C B
   B->C:  b - - - - - - - E D C
   C->X:  c b - - - - - - - E D Z Y X
   X->Y:  x c b - - - - - - - E D Z Y
   Y->Z:  y x c b - - - - - - - E D Z
   Z->D:  c b - - - - - - - E D
   D->E:  d c b - - - - - - - E

ie, Z needs to be able to be told "don't add padding, in fact, drop two
blocks worth of padding before forwarding". That presumably just needs a
byte or two of data; but it completely messes up the constant-size
packets. :-/

Cheers,
aj