Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2016-01-28 📝 Original message: Anthony Towns <aj at ...
📅 Original date posted:2016-01-28
📝 Original message:
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.
📝 Original message:
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.