Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2016-02-08 📝 Original message: Hi all! Eliminating all ...
📅 Original date posted:2016-02-08
📝 Original message:
Hi all!
Eliminating all acknowledgements makes for a much simpler
protocol.
Each side sends one or more updates
(ADD/SETTLE/TIMEOUT/FAIL/UNADD), followed by a COMMIT (with sig). Reply
COMPLETE with the old revocation preimage. Each side tracks two commit
txs: its own and the other side's. When you COMMIT you're locking in
your updates to my commit, and staging them for your commit, enforcing
the requirement that you commit to your updates first.
Details
-------
ADD:
Insert this new HTLC from proposer to recipient.
SETTLE:
Recipient collects proposers's committed HTLC with R value.
TIMEOUT:
Proposer removes committed HTLC it added.
FAIL:
Recipient removes committed HTLC it received.
UNADD:
Proposer removes uncommitted HTLC it added.
COMMIT:
Contains a signature for receiver's commit tx, with all the
updates included. Recipient commits updates to its own commit tx,
and stages those same updates to the other side's commit tx, then
sends COMPLETE for its own old commit tx.
COMPLETE:
Completes removal of old commit tx. Recipient commits updates
to other side's commit tx, stages those same updates for its own
commit tx.
So the shortest possible complete exchange looks like:
A B
ADD->
COMMIT->
<-COMPLETE
<-COMMIT
COMPLETE->
Optimizations
-------------
If we want to fail faster, we can add a non-binding ADD_FAIL message,
rather than waiting for a COMMIT. This would be a hint that we will
FAIL an HTLC as soon as it is committed; recipient may UNADD if it
receives it in time.
Fee Negotiation
---------------
lnd has a fee field in their commit msg, c-lightning uses a fixed fee
negotiation at channel establishment and a FIXME. The logical place for
fee negotiation is in the COMMIT message, with a requested fee rate and
a range of acceptable values. Instead of COMPLETE a node may REJECT,
with a fee range; the COMPLETE may then be reattempted.
Similar fee negotiation would be required for mutual close (this isn't
as urgent and so would use a normal fee).
Cheers,
Rusty.
Published at
2023-06-09 12:45:42Event JSON
{
"id": "acfda9fd285dad73675f0e1c2111a6f742686e6acbb69e246973b0f3d231aa7f",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314742,
"kind": 1,
"tags": [
[
"e",
"201a08e3788288f76767043bb44439f19bd3c9444e1cf1129df84310dad6b2e6",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2016-02-08\n📝 Original message:\nHi all!\n\n Eliminating all acknowledgements makes for a much simpler\nprotocol.\n\n Each side sends one or more updates\n(ADD/SETTLE/TIMEOUT/FAIL/UNADD), followed by a COMMIT (with sig). Reply\nCOMPLETE with the old revocation preimage. Each side tracks two commit\ntxs: its own and the other side's. When you COMMIT you're locking in\nyour updates to my commit, and staging them for your commit, enforcing\nthe requirement that you commit to your updates first.\n\nDetails\n-------\nADD:\n Insert this new HTLC from proposer to recipient.\nSETTLE:\n Recipient collects proposers's committed HTLC with R value.\nTIMEOUT:\n Proposer removes committed HTLC it added.\nFAIL:\n Recipient removes committed HTLC it received.\nUNADD:\n Proposer removes uncommitted HTLC it added.\n\nCOMMIT:\n Contains a signature for receiver's commit tx, with all the\n updates included. Recipient commits updates to its own commit tx,\n and stages those same updates to the other side's commit tx, then\n sends COMPLETE for its own old commit tx.\n\nCOMPLETE:\n Completes removal of old commit tx. Recipient commits updates\n to other side's commit tx, stages those same updates for its own\n commit tx.\n\nSo the shortest possible complete exchange looks like:\n\nA B\nADD-\u003e\nCOMMIT-\u003e\n \u003c-COMPLETE\n \u003c-COMMIT\nCOMPLETE-\u003e\n\nOptimizations\n-------------\nIf we want to fail faster, we can add a non-binding ADD_FAIL message,\nrather than waiting for a COMMIT. This would be a hint that we will\nFAIL an HTLC as soon as it is committed; recipient may UNADD if it\nreceives it in time.\n\nFee Negotiation\n---------------\nlnd has a fee field in their commit msg, c-lightning uses a fixed fee\nnegotiation at channel establishment and a FIXME. The logical place for\nfee negotiation is in the COMMIT message, with a requested fee rate and\na range of acceptable values. Instead of COMPLETE a node may REJECT,\nwith a fee range; the COMPLETE may then be reattempted.\n\nSimilar fee negotiation would be required for mutual close (this isn't\nas urgent and so would use a normal fee).\n\nCheers,\nRusty.",
"sig": "5f5eff38192cd8ee36d22a14dc3fe39f9226a41326060b6da2ffd65d9d288c9304620adae12350fd780e479df2b08d1200b18346a722f4057a2639a4d1228937"
}