Joseph Poon [ARCHIVE] on Nostr: 📅 Original date posted:2016-08-12 📝 Original message: On Fri, Aug 12, 2016 at ...

📅 Original date posted:2016-08-12
📝 Original message:
On Fri, Aug 12, 2016 at 12:54:52PM +0930, Rusty Russell wrote:
> 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;
> }

Yeah, the way I described would (optimally over-the-wire) be a tree of
chained preimages *AND* hashes as a part of the tree itself (so the
chain looks like preimage->hash->preimage->hash instead of
preimage->preimage). That way if you're willing to forgo the ability to
have multiple "next revocation hashes" in-flight (by instead having
multiple trees to achieve multiple in-flight), it's possible to only
send the "next revocation hash", which will automatically reveal the
prior "revocation preimage". In other words, the wire message could only
be sending next_revocation_hash. If one were to use pubkey revocations,
then that construction *requires* using privkeys+pubkeys instead of
preimages+hashes, which ups the cost/complexity -- which is why I said
it probably wasn't worth it.

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

For sure.

--
Joseph Poon