[Lightning-dev] Onion routing strawman proposal

[Rusty Russell]

Anthony Towns <aj at erisian.com.au> writes:
>> On Tue, Oct 06, 2015 at 12:19:14PM +1030, Rusty Russell wrote:
>> > I reworked test_onion and Makefile test to separate generate and
>> > decode;
>> > we should mix in the python version there too.
>
> Okay, branch updated:
>
> https://github.com/ElementsProject/lightning/pull/9
>
> On Tue, Oct 06, 2015 at 03:22:36PM +1000, Anthony Towns wrote:
>> 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?
>
> So I disabled that, and made the 02/03 prefix explicit. Maybe saving
> a bit/byte somewhere will be worth it; but it seems way premature and
> just gave me the heebie-jeebies. :)

Yeah, it made more sense when it was common code.  The 32 bytes fits
neatly into the onion in a way 33 bytes really doesn't (esp. for AES).

But this only applies for the temporary keys used for the onion, not
so much the node keys.  Will apply your patches then cleanup.

> I also changed the "Message for blah..." to serialize the pubkey before
> turning it into hex -- aiui you were dumping the internal representation
> of the point, which would be hard to duplicate compatibly.

Oops, yeah.

> I tweaked onion_key to avoid the for loop and cut calls. pyelliptic
> doesn't like to generate a pubkey given a privkey, so I'm just passing
> both to it directly.

Sure.

> Running decoding through python is slooooow -- unfortunately most of
> the time is in loading the interpretor and crypto modules, so only way
> to improve it would be to run the decodes in a single python process,
> which I'm not sure is actually desirable?
>
> Anyway, fwiw.
>
> Was there any conclusion on the wiki/rfc/whatever ideas about documenting
> lightning protocol/technology decisions? That'd be good to try, no?

Hmm, let me try to write an RFC...

Cheers,
Rusty.