Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2016-02-01 📝 Original message: Hi Joseph and ml, ...
📅 Original date posted:2016-02-01
📝 Original message:
Hi Joseph and ml,
Wondering if you can describe your HTLC negotiation protocol?
Laolu said on IRC you're working on it.
I've been trying to adapt my code to do this, and ended up with
something quite different AFAICT from your HTLC ids.
Because you need to supply the revocation hash to get a signature from
the other side, this implies an ordering in commitments.
The c-lightning protocol exchange looks like:
Send: [add/fulfill/fail/timeout, with new revocation hash]
Receive: [acceptance, with new revocation hash] or [decline if add]
Send: [commitment, with signature of new commit tx, and old
revocation preimage]
Receive: [commitment reply, with signature of new commit tx, and old
revocation preimage]
The obvious way to batch this is to have variants of the first two which
don't have a new revocation hash: you could follow your initial proposal
with an arbitrary number of additional changes to build up the new
commit tx, and the commitment is to all the accepted updates.
How similar is this to yours?
Thanks!
Rusty.
PS. I swear I send this before, but I couldn't find it...
Published at
2023-06-09 12:45:39Event JSON
{
"id": "129f4b1fb61c5322a767f34bc798e50eaa2dcfb1b7824f9888b696031edfeedf",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314739,
"kind": 1,
"tags": [
[
"e",
"18682649fe79f5a2c54629ca1e6d86742074bd7eba6c99aba4f0188eb011b6a3",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2016-02-01\n📝 Original message:\nHi Joseph and ml,\n\n Wondering if you can describe your HTLC negotiation protocol?\nLaolu said on IRC you're working on it.\n\nI've been trying to adapt my code to do this, and ended up with\nsomething quite different AFAICT from your HTLC ids.\n\nBecause you need to supply the revocation hash to get a signature from\nthe other side, this implies an ordering in commitments.\n\nThe c-lightning protocol exchange looks like:\n\n Send: [add/fulfill/fail/timeout, with new revocation hash]\n Receive: [acceptance, with new revocation hash] or [decline if add]\n Send: [commitment, with signature of new commit tx, and old\n revocation preimage]\n Receive: [commitment reply, with signature of new commit tx, and old\n revocation preimage]\n\nThe obvious way to batch this is to have variants of the first two which\ndon't have a new revocation hash: you could follow your initial proposal\nwith an arbitrary number of additional changes to build up the new\ncommit tx, and the commitment is to all the accepted updates.\n\nHow similar is this to yours?\n\nThanks!\nRusty.\nPS. I swear I send this before, but I couldn't find it...",
"sig": "05b3c930153fa4c36acbebbb31d846a35506fd60556ee5dbc5bd22fa3aa8faff10a4c030090af76a3eb2f66641f18b6f3fdc511082355af38b0729104fe389fe"
}