[Lightning-dev] Laundry list of inter-peer wire protocol changes

[Rusty Russell]

Anthony Towns <aj at erisian.com.au> writes:
> Personally, I think both this and shachain have the indexing backwards;
> I think i=0 should match the seed, and the first hash transmitted across
> the wire should be i=2^64-1, then counting down from there. This matches
> the numbering used in https://en.wikipedia.org/wiki/Hash_chain fwiw.

OK.

> With shachain, that gives the nice property that the only parameter
> you need is the seed, you can work out the hash for any given index
> directly from that, up to any arbitrary index, until you run out of
> integer precision, or bits of security in your hash function.
>
> With elkrem you can build an arbitrarily deep tree given a seed at the
> conceptual level without any further parameters, but when you start
> mapping that to indexes you need to know the desired height first.

We can just say "64 bits is enough for everyone", and be done.

> This is, in essence, because L(seed) (eg) gets sent at different places
> depending on the "height"; with a height of 1 it's the first value (or
> third from last), with a height of 2 it's the third value (or fifth
> from last), with a height of 3 it's the seventh value (or ninth from
> last), etc.
>
> Probably doesn't really matter, but I think it leads me to prefer Rusty's
> construction. Might be good to have an explanation with it diagrammed
> as an n-way tree structure though, in a similar way to how you visualise
> the elkrem tree...

Definitely; a 64-deep binary tree is a 64-dimensional 1x1...x1
hypercube, but the former is less brainhurty.

>> - R value vs keypair
>>   - Using a simple secret "redeemhash" allows easy tracing of
>>     transactions through the network.
>>   - Mats Jeratsch proposed a keypair scheme which decorrelates them[3],
>>     Greg Maxwell optimized it slightly, and Anthony Towns[4] and Andrew
>>     Poelstra independently came up with a way to do it without any
>>     bitcoin mods.
>
> FWIW I think this should still be considered an R&D idea rather than
> trying to release it in v1.0.
>
>> - Multi-sig txs
>>   - Joseph pointed out that by simply allowing more than one signature on
>>     commit txs[5], we can enable escrow-style services (including things
>>     like GreenAddress.it which does this for normal wallets).
>
> It's "more than one hash" not more than one /signature/, isn't it? (The
> proposal was also to support 2-of-3 hashes, slightly more complicated
> than just multiple hashes)

You're right, it's multiple hashes.  Which gives me an idea I'll post
separately.

Thanks!
Rusty.