đź“… Original date posted:2018-01-16
đź“ť Original message:
Hi Rusty,
This is something I’ve been thinking a bit about, as I’ve stumbled into some of the edge cases you mention. Just to get on the same page: does the other side (non-funder) pay any fees in the current implementation? [1] suggests that the funder pays everything atm (on both sides’ commitment), so I reckon you are talking about dual-funder from here on.
[1] https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#fee-payment
Problem#1 If we can make each side pay the fee for the HTLCs they are adding (on both commitments!), in addition to your suggestion of having them set fees independently, we get a nice bonus: Any update Alice makes, can only decrease *her* balance, not Bob’s. She can add HTLCs (she must pay HTLC+fee), do a fee update (potentially increasing the fees she must pay), or settle/fail HTLCs (can not decrease her balance). This is in contrast to the current spec, where an added HTLC can make Bob pay the fee (if he’s funder), and a fee update can make Bob not afford the new fee (the race you mentioned).
I think this will work without the check (2) you mention, since if Alice sends a fee update, then it will apply only to her HTLCs, and as mentioned can only decrease her balance. It doesn’t matter if Bob adds `max_accepted_htlcs` at the same time, since those fees will then be subtracted from his balance, and is not affected by the fee update.
This would make a lot of the edge cases go away, and would make it a lot easier to verify that a node is not violating its channel reserve. Let me know if I’m missing something.
- Johan
On Tue, Jan 16, 2018 at 0:55, Rusty Russell <rusty at rustcorp.com.au> wrote:
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.
_______________________________________________
Lightning-dev mailing list
Lightning-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180117/bebe4a64/attachment.html>;
Johan TorĂĄs Halseth [ARCHIVE] /
npub1pp…hs2fw
2023-06-09 12:48:34
in reply to nevent1q…sjxq
Author Public Key
npub1ppn2nhlfdzkw9gw0ytljpef5dpyzsxzw8ffcyykamt32hw6pge0smhs2fwPublished at
2023-06-09 12:48:34Event JSON
{
"id": "d50236da4402aac121ab96f6b51f9f277f2bdbca0a7797d10587a2ce374744a1",
"pubkey": "0866a9dfe968ace2a1cf22ff20e534684828184e3a538212dddae2abbb41465f",
"created_at": 1686314914,
"kind": 1,
"tags": [
[
"e",
"f4ea6e2be6a28791e59e2e88a0220b317c2ff57f269527eafe797276e87a01e1",
"",
"root"
],
[
"e",
"647ce90b8dae876334a98b31e0b2454a357e0d88c00fb68c7650210554d74b58",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2018-01-16\n📝 Original message:\nHi Rusty,\nThis is something I’ve been thinking a bit about, as I’ve stumbled into some of the edge cases you mention. Just to get on the same page: does the other side (non-funder) pay any fees in the current implementation? [1] suggests that the funder pays everything atm (on both sides’ commitment), so I reckon you are talking about dual-funder from here on.\n[1] https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#fee-payment\nProblem#1 If we can make each side pay the fee for the HTLCs they are adding (on both commitments!), in addition to your suggestion of having them set fees independently, we get a nice bonus: Any update Alice makes, can only decrease *her* balance, not Bob’s. She can add HTLCs (she must pay HTLC+fee), do a fee update (potentially increasing the fees she must pay), or settle/fail HTLCs (can not decrease her balance). This is in contrast to the current spec, where an added HTLC can make Bob pay the fee (if he’s funder), and a fee update can make Bob not afford the new fee (the race you mentioned).\nI think this will work without the check (2) you mention, since if Alice sends a fee update, then it will apply only to her HTLCs, and as mentioned can only decrease her balance. It doesn’t matter if Bob adds `max_accepted_htlcs` at the same time, since those fees will then be subtracted from his balance, and is not affected by the fee update.\nThis would make a lot of the edge cases go away, and would make it a lot easier to verify that a node is not violating its channel reserve. Let me know if I’m missing something.\n- Johan\n\nOn Tue, Jan 16, 2018 at 0:55, Rusty Russell \u003crusty at rustcorp.com.au\u003e wrote:\nHi all,\n\nWanted 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.\n_______________________________________________\nLightning-dev mailing list\nLightning-dev at lists.linuxfoundation.org\nhttps://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180117/bebe4a64/attachment.html\u003e",
"sig": "8baeb42560edee433601064e5a6f4b5f52bb87e301bbae84e5aceb5acf97eec701bd2ed09db8e5709fb152a0ab9822f7842712c1d8c21cba705daaf1a676522c"
}