From bastien at acinq.fr Thu Oct 27 13:51:05 2022 From: bastien at acinq.fr (Bastien TEINTURIER) Date: Thu, 27 Oct 2022 15:51:05 +0200 Subject: [Lightning-dev] A pragmatic, unsatisfying work-around for anchor outputs fee-bumping reserve requirements Message-ID: 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: