Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2016-08-12 📝 Original message: Joseph Poon <joseph at ...

📅 Original date posted:2016-08-12
📝 Original message:
Joseph Poon <joseph at lightning.network> writes:
> On Thu, Aug 11, 2016 at 11:25:36AM +0930, Rusty Russell wrote:
>> Tadge Dryja <tadge at lightning.network> writes:
>> > The method of using a revocation key is compatible with shachain/elkrem so
>> > has log(n) storage; I'll describe what I developed which omits hashing in
>> > the commit script and uses only signature verification. If Laolu has made
>> > a different key revocation scheme I'm not aware, but please do post if so.
>>
>> Oh, I blamed Laolu because he told me about it; sorry for misattribution.
>
> I came up with it a long time ago, and worked out the
> details/optimizations /w Laolu more recently (I think he told you that
> night when everything was finalized). I mentioned the general
> construction to you a LONG time ago too when you were in the Bay Area,
> but I probably didn't explain it properly (I was comparing with
> Vanitygen, if that helps). I think Tadge was the first to implement it
> though, not sure.
>
>> The property I was *hoping* for was the ability for Alice (and Bob) to
>> independently predict each others' future revocation hashes/pubkeys.
>> That would neatly allow an arbitrary number of commitment transactions
>> in flight each way at once. Naively, seems like that should be
>> possible.
>
> I'm not inclined to think an increase in complexity is helpful (if this
> is necessary), but there are probably some things you can do if you're
> looking down these paths.
>
> It's possible to get the same *bandwidth* optimization you want, except
> opposite. The idea with "predicting the future revocation
> hashes/pubkeys" is you only need to send revocations. Instead, it's
> possible to only send revocation hashes/pubkeys and not send
> revocations. In other words, instead of predicting each others' future
> revocation hashes/pubkeys, it's possible to revoke as *part of* giving
> the next revocation hash/pubkey.

Yeah, I do that already. We give the N+1th hash when we send the
revocation for N:

// Complete the update.
message update_revocation {
// Hash preimage which revokes old commitment tx.
required sha256_hash revocation_preimage = 1;
// Revocation hash for my next commit transaction
required sha256_hash next_revocation_hash = 2;
}

The trivial extension is to make in the N+Mth revocation hash, and
instead of sending the first two revocation hashes on establishment,
send the first M+1.

I just wanted to make sure there wasn't some clever alternative I was
missing. Greg Maxwell and Pieter Wuille tell me there isn't an obvious
one.

> Not sure how useful this is, though. Seems a lot of complexity for some
> small bandwidth savings, not really that interested in doing all that,
> but it's the closest I can get to what you want. This is off the top of
> my head/memory, I didn't write any notes on this, so parts of this (or
> entirety) might be wrong...

Yeah, agreed. Hash trees are nice and simple, so unless we get a
signficiant win, let's stick with that?

Cheers,
Rusty.