Hi tbast, FWIW, we haven't had _too_ many issues with the additional constraints anchor channels bring. Initially users had to deal w/ the UTXO reserve, but then sort of accepted the trade-off for the safety that actually being able to dynamically bump the fee on your commitment transaction and HTLCs. We're also able to re-target the fee level of second level spends on the fly, and even aggregate them into distinct fee buckets.
However, I can imagine that if an implementation doesn't have its own wallet, then things can be a bit more difficult, as stuff like the bitcoind wallet may not expose the APIs one needs to do things like CPFP properly. lnd has its own wallet (btcwallet), which is what has allowed us to adopt default P2TR addresses everywhere so quickly (tho ofc we inherit additional maintenance costs). > 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. IMO these new considerations aren't any worse than needing to predict the future fee schedule of the chain to ensure that you can force close in a timely manner when you need to. Re fee bumping thousands of HTLCs: anchor lets them all be batched in the same transaction, which reduces fees and also the worst-case on-chain force close footprint. > each node can simply sign multiple versions of the HTLC transactions at > various feerates I'm not sure this can be mapped super cleanly to taproot channels that use musig2. Today in the spec draft/impl, both sides maintain a pair of nonces (one for each commitment transaction). If they need to sign N different versions, then they also need to exchange N nonces, both during the initial funding process, and also each time a new commitment transaction is created. Mo signatures means mo transaction latency. Also how would retransmitting be handled? By sending distinct valid signatures for a given fee rate, you're effectively creating _even more_ commitments one needs to watch to be able to play once they potentially hit the chain. Ultimately, I'm not sure why implementations that have already rolled out anchors by default, and have a satisfactory policy for ensuring fee bumping UTXOs are available at all times would implement this. It's just yet another option defined in the spec, and prescribes a more restrictive solution to what's already possible: being able to dynamically fee bump commitment transactions, and aggregate second level spends. -- Laolu On Thu, Oct 27, 2022 at 6:51 AM Bastien TEINTURIER <bast...@acinq.fr> wrote: > 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 > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
