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.
03-transactions.md
Outdated
| 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. |
There was a problem hiding this comment.
Hmm, I really don't feel great about having an anchor output that has all the dust in it. That would just encourage people to use private transaction relay services to avoid fee sniping in the mempool and steal the dust value even if they aren't a miner. Instead, @instagibbs suggested only letting the anchor rise up to the dust threshold and then switch to adding any remaining dust value directly to the commitment transaction's fees (as we'd no longer be relying on the ephemeral dust rules).
IMO Bitcoin Core shouldn't be requiring ephemeral transactions be 0 fee at all, but that's a separate discussion (maybe one we have before we ship this, tho bitcoin/bitcoin#31938 ).
There was a problem hiding this comment.
Instead, @instagibbs suggested only letting the anchor rise up to the dust threshold and then switch to adding any remaining dust value directly to the commitment transaction's fees (as we'd no longer be relying on the ephemeral dust rules).
What I dislike with this option is that having a threshold is more clumsy...and it relies on a threshold currently defined by bitcoind which could be removed in the future, leaving us with a weird technical debt in our commitment protocol (unless the requirement is removed after discussing bitcoin/bitcoin#31938 of course).
If we didn't have this threshold and could always keep the output 0 sat, then I'd agree with you that since we're doing P2A anyway, it's better to directly add dust outputs to the transaction's mining fees.
That would just encourage people to use private transaction relay services to avoid fee sniping in the mempool and steal the dust value even if they aren't a miner.
I'm not sure how the incentives to do that would work: if someone wants to do this, that means they'd share the transaction with only a subset of miners that they trust, with whom they will share the dust value, right? In that case why would the miner share that dust value instead of claiming everything for themselves?
That also means users who'd do that would be using only a subset of the network's hashrate, which lowers the probability that the transaction gets confirmed. That can thus only be done for transactions where there's no deadline, and thus no (untrimmed) HTLCs? Is it really worth force-closing a channel that contains only dust HTLCs just to claim a small portion of that dust, especially given the fact that the maximum dust at stake in the transaction can be controlled by both nodes? Also, the other node always has the option of broadcasting their commitment to the whole network (e.g. if some of the pending trimmed HTLCs timeout) and benefit from a bigger hashrate?
There was a problem hiding this comment.
What I dislike with this option is that having a threshold is more clumsy...and it relies on a threshold currently defined by bitcoind which could be removed in the future, leaving us with a weird technical debt in our commitment protocol (unless the requirement is removed after discussing bitcoin/bitcoin#31938 of course).
I admit I'm not super optimistic about getting it changed in bitcoind, as much as I think it should be. But, maybe more importantly, we have another shot here anyway...when we adapt this to taproot channels (probably at least another Bitcoin Core release away) we can revist this decision and drop the cruft if policy has changed.
I agree its pretty meh, but it seems even weirder to have an anyone-can-spent output that might actually rise to a material amount of money. Luckily its not all that much code diff from your current logic, just have to cap the anchor amount, so its not much code-wise difference (though it'd be a log nicer for me if the value were fixed at zero!)
I'm not sure how the incentives to do that would work: if someone wants to do this, that means they'd share the transaction with only a subset of miners that they trust, with whom they will share the dust value, right? In that case why would the miner share that dust value instead of claiming everything for themselves?
Generally private mempool services allow transactors to submit transactions directly to miners with the promise that the miner will not modify/inspect the transaction (to extract any available MEV) and in exchange the transactor pays some fee directly to the miner and only submits the transaction to miners participating in the private mempool service (so the miner gets additional transaction flow that isn't publicly available). eg our MEVPool proposal from a few days ago proposes using SGX for this.
That also means users who'd do that would be using only a subset of the network's hashrate, which lowers the probability that the transaction gets confirmed.
Sadly, private mempools (eg mempool.space's, though its not quite a "private" mempool yet) are already used by a very nontrivial portion of hashrate :/
There was a problem hiding this comment.
Luckily its not all that much code diff from your current logic, just have to cap the anchor amount, so its not much code-wise difference (though it'd be a log nicer for me if the value were fixed at zero!)
I agree, it's not horrible, but it would have been more elegant without any threshold 😅
Let's discuss this during today's spec meeting to decide what we want to do here for this first commitment format.
There was a problem hiding this comment.
I added the 240 sats threshold in c1110b1, it's a bit awkward in text but the code should be straightforward (and the test vectors will help ensure that everybody gets this right).
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.
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: