📅 Original date posted:2022-10-27
📝 Original message:
Good morning list,
The lightning network transaction format was updated to leverage CPFP
carve-out and allow nodes to set fees at broadcast time, using a feature
called anchor outputs [1].
While desirable, this change brought a whole new set of challenges, by
requiring nodes to maintain a reserve of available utxos for fee-bumping.
Correctly managing this fee-bumping reserve involves a lot of complex
decisions and dynamic risk assessment, because in worst-case scenarios,
a node may need to fee-bump thousands of HTLC transactions in a short
period of time.
This is especially frustrating because HTLC transactions should not need
external inputs, as the whole value of the HTLC is already provided in
its input, which means we could in theory "simply" decrease the amount of
the corresponding output to set the fees to any desired value. However,
we can't do this safely because it doesn't work well with the revocation
mechanism, unless we find fancy new sighash flags to add to bitcoin.
See [2] for a longer rant on this issue.
A very low tech and unsatisfying solution exists, which is what I'm
proposing today: each node can simply sign multiple versions of the
HTLC transactions at various feerates, and at broadcast time if you're
lucky you'll have a pre-signed transaction that approximately matches
the feerate you want, so you don't need to add inputs from your fee
bumping reserve. This reduces the requirements on your on-chain wallet
and simplifies transaction management logic. I believe that it's a
pragmatic approach, even though not very elegant, to increase funds
safety for existing node operators and wallets. I opened a spec PR
that is currently chasing concept ACKs before I refine it [3].
Please let me know what you think, and if this is something that you
would like your implementation to provide.
Thanks,
Bastien
[1] https://github.com/lightning/bolts/pull/688
[2] https://github.com/lightning/bolts/issues/845
[3] https://github.com/lightning/bolts/pull/1036
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221027/df1e8ff5/attachment.html>;
Bastien TEINTURIER [ARCHIVE] /
npub17f…ntr0s
2023-06-09 13:07:10
in reply to nevent1q…pnmk
Author Public Key
npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0sPublished at
2023-06-09 13:07:10Event JSON
{
"id": "a70634a5c2decfa9cd9c4179fa7e4143a9f07f6aa1c33f66bd8ee1452911f077",
"pubkey": "f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb",
"created_at": 1686316030,
"kind": 1,
"tags": [
[
"e",
"a8f151bc6f8ff5e28d3b76282b0ac06875ad62b87bcc41dd9796a3d604c1b31c",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2022-10-27\n📝 Original message:\nGood morning list,\n\nThe lightning network transaction format was updated to leverage CPFP\ncarve-out and allow nodes to set fees at broadcast time, using a feature\ncalled anchor outputs [1].\n\nWhile desirable, this change brought a whole new set of challenges, by\nrequiring nodes to maintain a reserve of available utxos for fee-bumping.\nCorrectly managing this fee-bumping reserve involves a lot of complex\ndecisions and dynamic risk assessment, because in worst-case scenarios,\na node may need to fee-bump thousands of HTLC transactions in a short\nperiod of time.\n\nThis is especially frustrating because HTLC transactions should not need\nexternal inputs, as the whole value of the HTLC is already provided in\nits input, which means we could in theory \"simply\" decrease the amount of\nthe corresponding output to set the fees to any desired value. However,\nwe can't do this safely because it doesn't work well with the revocation\nmechanism, unless we find fancy new sighash flags to add to bitcoin.\nSee [2] for a longer rant on this issue.\n\nA very low tech and unsatisfying solution exists, which is what I'm\nproposing today: each node can simply sign multiple versions of the\nHTLC transactions at various feerates, and at broadcast time if you're\nlucky you'll have a pre-signed transaction that approximately matches\nthe feerate you want, so you don't need to add inputs from your fee\nbumping reserve. This reduces the requirements on your on-chain wallet\nand simplifies transaction management logic. I believe that it's a\npragmatic approach, even though not very elegant, to increase funds\nsafety for existing node operators and wallets. I opened a spec PR\nthat is currently chasing concept ACKs before I refine it [3].\n\nPlease let me know what you think, and if this is something that you\nwould like your implementation to provide.\n\nThanks,\nBastien\n\n[1] https://github.com/lightning/bolts/pull/688\n[2] https://github.com/lightning/bolts/issues/845\n[3] https://github.com/lightning/bolts/pull/1036\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221027/df1e8ff5/attachment.html\u003e",
"sig": "eeb145d460e3849da5cea1ba36c43559716a525a12795422480b4fe7346d7f79296e3d2daced3c916b2cea9d4bf9b2c35e1b7624fc1faf3445eee0fbc2c35ec3"
}