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
Published at
2023-06-09 12:46:37Event JSON
{
"id": "2518faa829a52853038346e414f3f9dd10b6aae14e54a188f4d186cf600fd4b8",
"pubkey": "ccb4cc87c455b74febaee5929cfd0726421b2eea64ad2b16440b68e8c7433211",
"created_at": 1686314797,
"kind": 1,
"tags": [
[
"e",
"ccc2d459792b926854b04bc74e6ea324d2314fff88991806647cc195016ae9ae",
"",
"root"
],
[
"e",
"d613779a47ee7d0a4fd06ba0be634e302cf533eebd659f20efe933d40b4c9993",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2016-08-12\n📝 Original message:\nOn Fri, Aug 12, 2016 at 12:54:52PM +0930, Rusty Russell wrote:\n\u003e Yeah, I do that already. We give the N+1th hash when we send the\n\u003e revocation for N:\n\u003e \n\u003e // Complete the update.\n\u003e message update_revocation {\n\u003e // Hash preimage which revokes old commitment tx.\n\u003e required sha256_hash revocation_preimage = 1;\n\u003e // Revocation hash for my next commit transaction\n\u003e required sha256_hash next_revocation_hash = 2;\n\u003e }\n\nYeah, the way I described would (optimally over-the-wire) be a tree of\nchained preimages *AND* hashes as a part of the tree itself (so the\nchain looks like preimage-\u003ehash-\u003epreimage-\u003ehash instead of\npreimage-\u003epreimage). That way if you're willing to forgo the ability to\nhave multiple \"next revocation hashes\" in-flight (by instead having\nmultiple trees to achieve multiple in-flight), it's possible to only\nsend the \"next revocation hash\", which will automatically reveal the\nprior \"revocation preimage\". In other words, the wire message could only\nbe sending next_revocation_hash. If one were to use pubkey revocations,\nthen that construction *requires* using privkeys+pubkeys instead of\npreimages+hashes, which ups the cost/complexity -- which is why I said\nit probably wasn't worth it. \n\n\u003e Yeah, agreed. Hash trees are nice and simple, so unless we get a\n\u003e signficiant win, let's stick with that?\n\nFor sure.\n\n-- \nJoseph Poon",
"sig": "9b0ac62ef1796e5b9ae81dce772148f2b223aee4159ed4e3ae47c213508aaddf01e56bc1fefe2270555a7bc443cb27c4b0c112bee0992c218f72f48783af2898"
}