Zero-fee commitments using v3 transactions (feature 40/41) #1228
Conversation
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. |
morehouse
left a comment
morehouse
left a comment
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.
TheBlueMatt
left a comment
TheBlueMatt
left a comment
There was a problem hiding this comment.
This was actually a good bit easier to implement than I thought.
|
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. |
We add support for the zero-fee commitment format specified in lightning/bolts#1228. Channels using this commitment format benefit from better protection against pinning attacks (thanks to TRUC/v3 transactions), don't need the `update_fee` mechanism, have less dust exposure risk, and use an overall simpler state machine.
We add support for the zero-fee commitment format specified in lightning/bolts#1228. Channels using this commitment format benefit from better protection against pinning attacks (thanks to TRUC/v3 transactions), don't need the `update_fee` mechanism, have less dust exposure risk, and use an overall simpler state machine.
|
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
force-pushed
the
zero-fee-commitments
branch
from
c3e6be1 to
6a832c5
Compare
|
I have rebased to fix the merge conflicts, and squashed into a single commit. I have also:
I'm working on adding a set of Bolt 3 test vectors. |
We cannot provide any estimate on timing.
This is explained in this PR, and in the description. We use the unkeyed version. |
We add support for the zero-fee commitment format specified in lightning/bolts#1228. Channels using this commitment format benefit from better protection against pinning attacks (thanks to TRUC/v3 transactions), don't need the `update_fee` mechanism, have less dust exposure risk, and use an overall simpler state machine.
We add support for the zero-fee commitment format specified in lightning/bolts#1228. Channels using this commitment format benefit from better protection against pinning attacks (thanks to TRUC/v3 transactions), don't need the `update_fee` mechanism, have less dust exposure risk, and use an overall simpler state machine.
We add support for the zero-fee commitment format specified in lightning/bolts#1228. Channels using this commitment format benefit from better protection against pinning attacks (thanks to TRUC/v3 transactions), don't need the `update_fee` mechanism, have less dust exposure risk, and use an overall simpler state machine. In this commit, we simply introduce the commitment format and create the corresponding transactions.
|
@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 🚀 |
We add support for the zero-fee commitment format specified in lightning/bolts#1228. Channels using this commitment format benefit from better protection against pinning attacks (thanks to TRUC/v3 transactions), don't need the `update_fee` mechanism, have less dust exposure risk, and use an overall simpler state machine. In this commit, we simply introduce the commitment format and create the corresponding transactions.
We add support for the zero-fee commitment format specified in lightning/bolts#1228. Channels using this commitment format benefit from better protection against pinning attacks (thanks to TRUC/v3 transactions), don't need the `update_fee` mechanism, have less dust exposure risk, and use an overall simpler state machine. In this commit, we simply introduce the commitment format and create the corresponding transactions.
We add support for the zero-fee commitment format specified in lightning/bolts#1228. Channels using this commitment format benefit from better protection against pinning attacks (thanks to TRUC/v3 transactions), don't need the `update_fee` mechanism, have less dust exposure risk, and use an overall simpler state machine. In this commit, we simply introduce the commitment format and create the corresponding transactions.
|
@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:
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 @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
left a comment
carlaKC
left a comment
There was a problem hiding this comment.
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 🙏
We add support for the zero-fee commitment format specified in lightning/bolts#1228. Channels using this commitment format benefit from better protection against pinning attacks (thanks to TRUC/v3 transactions), don't need the `update_fee` mechanism, have less dust exposure risk, and use an overall simpler state machine. In this commit, we simply introduce the commitment format and create the corresponding transactions.
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 rounded down millisatoshi amounts (and may thus be `0 sat`), capped at 240 sats. When the sum of trimmed outputs and rounded down millisatoshi amounts exceeds 240 sats, the remaining amount directly goes to on-chain fees (and in that case, the commitment transactions does pay some on-chain fees on its own). We do this to ensure that only miners can collect the excess from trimmed outputs, while respecting standardness rules. We remove the 1-block relative delay used by anchor output channels, because we don't need the CPFP carve-out rule when using v3 txs. This allows using our channel outputs (main balance or pending HTLCs) to CPFP a remote commitment transaction (no need to add external wallet inputs, which greatly simplifies liquidity management). v3 transactions and pay-to-anchor outputs have been standard since the release of Bitcoin Core v28.0. Ephemeral dust has been standard since the Bitcoin Core v29.0 release.
t-bast
force-pushed
the
zero-fee-commitments
branch
from
fc83fef to
b982ae7
Compare
12 participants
We introduce a new
channel_typethat 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 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 (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 at240 sats(and may thus be0 satwhen there are no trimmed outputs or rounded down millisatoshi amounts). Note that when the sum of trimmed outputs and millisatoshi rounding exceeds240 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!