Olaoluwa Osuntokun [ARCHIVE] on Nostr: 📅 Original date posted:2022-11-04 📝 Original message: Hi tbast, FWIW, we ...
📅 Original date posted:2022-11-04
📝 Original message:
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 <bastien at 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 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/20221104/9a1cfeb2/attachment.html>;
📝 Original message:
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 <bastien at 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 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/20221104/9a1cfeb2/attachment.html>;