Zero-fee commitments using v3 transactions (feature 40/41)

[t-bast]

We introduce a new channel_type that leverages v3 (TRUC) transactions, pay-to-anchor outputs and ephemeral dust. With this change, commitment transactions don't pay any mining fee (in most cases), 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 (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 (outputs below the dust_limit, which are thus not included in the commitment transaction) and all millisatoshi amounts that have been rounded down to satoshis, capped at 240 sats (and may thus be 0 sat when there are no trimmed outputs or rounded down millisatoshi amounts). Note that when the sum of trimmed outputs and millisatoshi rounding exceeds 240 sats, the commitment transaction won't by 0-fees anymore: but the fees aren't deduced from any of the commitment transaction's outputs.

This anchor output is unkeyed: it simply uses the standard P2A output introduced in bitcoin/bitcoin#30352.

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, which simplifies wallet management and liquidity requirements).

Note that v3 transactions and pay-to-anchor outputs have been standard since the release of Bitcoin Core v28.0. Ephemeral dust has become standard in the Bitcoin Core v29.0 release. All of this is thus ready to use on the network now!

[saubyk]

We use a single anchor output whose amount is the sum of all trimmed outputs (and may thus be 0 sat).

Hi @t-bast can you elaborate this a bit?

[saubyk]

We use a single anchor output whose amount is the sum of all trimmed outputs (and may thus be 0 sat).

Hi @t-bast can you elaborate this a bit?

Never mind. This delving post has the details, makes for a good supplemental reading:
https://delvingbitcoin.org/t/which-ephemeral-anchor-script-should-lightning-use/1412

[t-bast]

Hi @t-bast can you elaborate this a bit?

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.

[morehouse]

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.

[TheBlueMatt]

This was actually a good bit easier to implement than I thought.

[tnull]

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 option_simple_close transactions (optionally) v3, i.e., require v3 close transactions for v3 channels.

[Roasbeef]

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 option_simple_close transactions (optionally) v3, i.e., require v3 close transactions for v3 channels.

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:

Any TRUC transaction's unconfirmed ancestors must all be TRUC

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.

[t-bast]

Compared to the HTLC case, are there any pinning concerns when it comes to coop close?

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.

[sble]

When do you expect zero-fee commitments to be released out?

And, which ephemeral anchor options are likely to be implemented? (https://delvingbitcoin.org/t/which-ephemeral-anchor-script-should-lightning-use/1412?utm_source=chatgpt.com)

[t-bast]

I have rebased to fix the merge conflicts, and squashed into a single commit. I have also:

• changed the explanation of the 240 sats cap in Bolt 3
• added a warning in Bolt 5 about batching HTLCs transactions and the 10kvB limit

I'm working on adding a set of Bolt 3 test vectors.

[t-bast]

When do you expect zero-fee commitments to be released out?

We cannot provide any estimate on timing.

And, which ephemeral anchor options are likely to be implemented? (https://delvingbitcoin.org/t/which-ephemeral-anchor-script-should-lightning-use/1412?utm_source=chatgpt.com)

This is explained in this PR, and in the description. We use the unkeyed version.

[t-bast]

@carlaKC I've addressed the remaining comments, rebased and added test vectors for transaction construction (in 9fa506e), let me know if they work for you and if I should clarify the different fields of the test vector to help implementations use them.

Once those test vectors are validated, we can move forward with cross-compat tests between LDK and eclair 🚀

[t-bast]

@carlaKC @tankyleo I've tested cross-compatibility between eclair (ACINQ/eclair#3192) and LDK (lightningdevkit/ldk-server#75) and everything is working like a charm:

• I'm able to open and close v3 channels
• I'm able to make payments in both directions
• Dust is correctly allocated to the anchor output, until it reaches 240 sat

That was simpler than I thought, good job!

I've added a test vector in ACINQ/eclair@8b2e2e3, because I actually had a bug in eclair, where I was incorrectly using a Set for HTLCs and thus ignoring dust HTLCs that have the same amount. I thought it could be useful to others as well (even though LDK already handles this correctly).

@tankyleo mentioned during the spec meeting that propagation of v3 force-close isn't satisfying yet, so this may not be ready to use safely on mainnet, but it looks like code and spec are ready to go 🚀 ⚡ 🔥

[carlaKC]

everything is working like a charm

🔥

LGTM! Last test vector passes in LDK, just some nits and a request for a general "beware V3 gremlins" warning 🙏

[Roasbeef]

This is still the case, why remove this section?

[t-bast]

I can't see which section you're referring to here, github doesn't link that comment to any code change...

[Roasbeef]

Should this actually be zero_fee_commitments? Don't understand this portion of the diff.

[t-bast]

No, this isn't for zero_fee_commitments, this is for existing anchor output channels. The spec here was missing this part, which was in other sections but should have been in this one as well. The introduction of the shared anchor forced me to "refactor" a bit this file to properly distinguish the shared anchor case from the local/remote anchor case.

[Roasbeef]

White space/format changes like this littered all over the PR adds noise, and makes the diff as a whole harder to review.

I sincerely hope that this is the last PR written in the style of an ever expanding document which specifies All Things. The extension BOLT format is a superior way to make spec changes, as the documents are self contained, carrying nearly all the context needed for review.

[Roasbeef]

IIUC, this doesn't apply if the transaction has already been confirmed before a sweep is attempted. AFAIK, we all currently wait for confirmation before attempting to sweep a channel's output.

[t-bast]

I'm not sure I understand your comment here. HTLC transactions are using v3, so if you batch a bunch of HTLC transactions together (using the fact that their input uses SIGHASH_SINGLE | SIGHASH_ANYONECANPAY), the resulting transaction is a batched HTLC transaction that is using v3. So regardless of whether the commitment transaction is confirmed or not, the batched HTLC transaction cannot exceed 10kvB. Does that make sense?

[Roasbeef]

It would be more precise to just enumerate the channel types here so option_anchors and zero_fee_commitments. Or in the glossary make a new entry for anchor_channels or something like that, and ref as necessary.

[t-bast]

I disagree, I think it makes more sense to state the condition that makes adding another input possible (it's only possible because of those sighash flags on the input). Also, it's more future-proof because as we add more channel types that also use SIGHASH_SINGLE | SIGHASH_ANYONECANPAY, we don't have to edit all the places where we list channel types, the requirements are automatically inherited by the fact that we specify what should happen for SIGHASH_SINGLE | SIGHASH_ANYONECANPAY inputs.

[Roasbeef]

Let's say a user has a zero conf channel, the funding transaction is currently unconfirmed and a v3 transaction. Are they able to do a coop close with a v2 transaction, or will the bitcoind logic reject that as its considered an ancestor of the funding transaction?

[t-bast]

It will be rejected since its parent transaction is an unconfirmed v3 transaction. That's one of the reasons we use "high" feerates for 0-conf transactions in Phoenix, especially when there are no change outputs available to CPFP.