From aj at erisian.com.au  Tue Oct  6 14:01:34 2015
From: aj at erisian.com.au (Anthony Towns)
Date: Wed, 7 Oct 2015 00:01:34 +1000
Subject: [Lightning-dev] Onion routing strawman proposal
In-Reply-To: <20151006052236.GA1054@navy>
References: <87r3l8n4x0.fsf@rustcorp.com.au> <87oagcn4v9.fsf@rustcorp.com.au>
	<20151006052236.GA1054@navy>
Message-ID: <20151006140134.GA26690@navy>

> 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. :)

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.

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.

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?

Cheers,
aj