Zero-fee commitments using v3 transactions (feature 40/41) #1228
Conversation
We introduce a new `channel_type` that leverages v3 transactions, pay-to-anchor outputs and ephemeral dust. With this change, commitment transactions don't pay any mining fee, which gets rid of `update_fee` and all of the related channel reserve issues. It also gets rid of the undesired channel force-closes that happen when the mempool feerate spikes and channel participants disagree on what feerate to use, which has been a major source of wasted on-chain space. It also offers better protection against pinning attacks and reduces the on-chain footprint compared to anchor output channels. We use a single anchor output whose amount is the sum of all trimmed outputs (and may thus be `0 sat`). We remove the 1-block relative delay used by anchor output channels: this allows using our channel outputs (main balance or pending HTLCs) to CPFP a remote commitment transaction (no need to add external inputs). v3 transactions and pay-to-anchor outputs have been standard since the release of Bitcoin Core v28.0. Ephemeral dust will become standard in the Bitcoin Core v29.0 release.
Hi @t-bast can you elaborate this a bit? |
Never mind. This delving post has the details, makes for a good supplemental reading: |
This will become more obvious when I add the test vectors! It is also already defined in Bolt 3, if the paragraph for this is unclear please put a comment on it with a suggestion on how I could make it clearer. |
There was a problem hiding this comment.
Approach ACK.
Really eager to see this get implemented and used across the network. Also hope we can follow up soon with the changes needed to fix HTLC pinning.
We cap the amount of the `shared_anchor` to its dust limit of 240 sats to ensure that only miners can collect the excess from trimmed outputs. We cannot keep the `shared_anchor` amount at 0 sats all the time: when the commitment transaction includes some mining fees (because outputs are trimmed) it is forbidden by `bitcoind`'s default policy to have a 0-value output, otherwise we those outputs would pollute the utxo set because nobody would ever spend them if the transaction confirms on its own.
HTLC transactions don't benefit from the wider network's anonymity set, so we can stick to `0` as we did previously.
|
Just want to node that it was discussed in yesterday's spec call that as part of this work we'll probably also want to make |
Compared to the HTLC case, are there any pinning concerns when it comes to coop close? The channel is no longer active, and the only outputs on the coop close transaction send funds directly to either party. I point this out as the TRUC constraints are passed on to all unconfirmed children:
As a result, if the coop close transaction is v3, then a user wouldn't be able to CPFP with a non-v3 transaction to bump the fee (imagine the peer is just no longer offline). Another scenario that would be prevented is a non-v3 aware wallet spending that unconfirmed change to create a normal transaction, or fund a new channel. |
I don't think there are any, once we start using v3 for the commit tx and mutual close tx, the mutual close tx should be protected against pinning. |
The "legacy" anchor outputs are always taken from the funder's main output. Thanks @carlaKC for spotting this!
| OP_1 <0x4e73> | ||
|
|
||
| The amount of this output is usually 0 sats, in which case it must be spent by the child transaction paying the mining fees. | ||
| When the commitment contains [trimmed outputs](#trimmed-outputs), their amount is added to this `shared_anchor` output until it reaches 240 sats. |
There was a problem hiding this comment.
nit: I think it would be helpful to make a note here explaining why need to switch between the anchor and fees
- Ephemeral dust requires zero fees for values <= dust limit to be standard
- The dust limit for P2A is 240
Perhaps link to this issue: bitcoin/bitcoin#31938 (helped me understand it better)
We introduce a new
channel_typethat leverages v3 transactions, pay-to-anchor outputs and ephemeral dust. With this change, commitment transactions don't pay any mining fee, which gets rid ofupdate_feeand all of the related channel reserve issues. It also gets rid of the undesired channel force-closes that happen when the mempool feerate spikes and channel participants disagree on what feerate to use, which has been a major source of wasted on-chain space.It also offers better protection against pinning attacks (thanks to package relay) and reduces the on-chain footprint compared to anchor output channels. We use a single anchor output whose amount is the sum of all trimmed outputs (and may thus be
0 sat). We remove the 1-block relative delay used by anchor output channels: this allows using our channel outputs (main balance or pending HTLCs) to CPFP a remote commitment transaction (no need to add external inputs).v3 transactions and pay-to-anchor outputs have been standard since the release of Bitcoin Core v28.0. Ephemeral dust will become standard in the Bitcoin Core v29.0 release.
TODO: