📅 Original date posted:2018-01-15
📝 Original message:
Hi all,
Wanted to post some thinking on this for everyone to mull over,
though I know we're all busy.
Your consideration and feedback gratefully accepted!
Problem #1
==========
For simplicity, one side (funder) sets fees, but other side
needs to check they're sufficient, and not insanely high (as *they* end
up paying for HTLC txs). If they disagree, they close channel; this
happens a fair bit on testnet, for example, and will be worse with
different backends (eg. different bitcoind versions, or btcd, etc).
Solution
--------
Have both sides set fees independently. I specify what fees my
commitment tx and HTLC txs will have, you do the same. This works in
well with dual-funder proposals.
Implementation:
--------------
c-lightning did something similar pre-spec. The way it works is both
sides set an initial fee in `open_channel`: this is the only point at
which the counterparty checks it's reasonable.
You send an `update_fee` message like now, but it has no effect on the
other side: it's applied to *you* when they 'revoke_and_ack', like any
other change.
You disallow any `update_fee` which the other side could not afford with
(1) all their current HTLCs, AND (2) the `max_accepted_htlcs` from you.
That covers the race where one side sets fees and the other adds a heap
of HTLCs and the two cross over.
Also disallow any new HTLCs you can't pay fees for (given same
worst-case calculation as above), and if the one side can't afford fees,
pull from its reserve and other side as necessary (this can only happen
during initial phase, and is the same logic as now).
Problem #2
==========
Predicting the future is hard. Today's sufficient fee may be a gross
overpayment or insufficient tomorrow.
Solution
--------
Allow multiple simultaneous fee levels.
Implementation:
---------------
This means multiple signatures in each `commitment_signed` message,
which is more work and more storage. But since our nSequence is <
0xFFFFFFFE anyway, all transactions are RBF-ready except
closing_transaction. We might want to change that; we already allow
re-negotiation of closing tx by reconnecting anyway.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:48:34
in reply to nevent1q…q89r
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:48:34Event JSON
{
"id": "647ce90b8dae876334a98b31e0b2454a357e0d88c00fb68c7650210554d74b58",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314914,
"kind": 1,
"tags": [
[
"e",
"f4ea6e2be6a28791e59e2e88a0220b317c2ff57f269527eafe797276e87a01e1",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2018-01-15\n📝 Original message:\nHi all,\n\n Wanted to post some thinking on this for everyone to mull over,\nthough I know we're all busy.\n\nYour consideration and feedback gratefully accepted!\n\nProblem #1\n==========\nFor simplicity, one side (funder) sets fees, but other side\nneeds to check they're sufficient, and not insanely high (as *they* end\nup paying for HTLC txs). If they disagree, they close channel; this\nhappens a fair bit on testnet, for example, and will be worse with\ndifferent backends (eg. different bitcoind versions, or btcd, etc).\n\nSolution\n--------\nHave both sides set fees independently. I specify what fees my\ncommitment tx and HTLC txs will have, you do the same. This works in\nwell with dual-funder proposals.\n\nImplementation:\n--------------\nc-lightning did something similar pre-spec. The way it works is both\nsides set an initial fee in `open_channel`: this is the only point at\nwhich the counterparty checks it's reasonable.\n\nYou send an `update_fee` message like now, but it has no effect on the\nother side: it's applied to *you* when they 'revoke_and_ack', like any\nother change.\n\nYou disallow any `update_fee` which the other side could not afford with\n(1) all their current HTLCs, AND (2) the `max_accepted_htlcs` from you.\nThat covers the race where one side sets fees and the other adds a heap\nof HTLCs and the two cross over.\n\nAlso disallow any new HTLCs you can't pay fees for (given same\nworst-case calculation as above), and if the one side can't afford fees,\npull from its reserve and other side as necessary (this can only happen\nduring initial phase, and is the same logic as now).\n\n\nProblem #2\n==========\nPredicting the future is hard. Today's sufficient fee may be a gross\noverpayment or insufficient tomorrow.\n\nSolution\n--------\nAllow multiple simultaneous fee levels.\n\nImplementation:\n---------------\nThis means multiple signatures in each `commitment_signed` message,\nwhich is more work and more storage. But since our nSequence is \u003c\n0xFFFFFFFE anyway, all transactions are RBF-ready except\nclosing_transaction. We might want to change that; we already allow\nre-negotiation of closing tx by reconnecting anyway.",
"sig": "1cbdf75fa0b6b53aa813a5fc10863c4c946383adf1fba8fd3385de2c4cafdc279295dfc340cbaea36c042ec46a9a519f7236816bf85a14d1cb464d35ace8f7cd"
}