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. |
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.
|
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. |
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 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)
There was a problem hiding this comment.
Done in the latest rebase: I haven't linked to the bitcoin issue though, I'm reluctant to link to remote repositories (even bitcoin) since issues can be closed and even deleted, I'd rather add more rationale directly inside the BOLTs to explain why we're doing it that way. Let me know if the change is clear enough, otherwise feel free to suggest some changes!
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) |
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`), capped at 240 sats. When the sum of trimmed outputs 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 inputs). 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
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.
We add test vectors with fully signed commit and HTLC txs in various scenarios.
|
@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 🚀 |
| "per_commitment_point": "0275d12130c276b4274358a328901f8fc47e6c72629102e4b46c9f27dd2c1dda98", | ||
| "remote_payment_basepoint_secret": "580bff39085f3a6ae8b1f32905e67366c522ea8f2418391145b2e98f1a7cb3f2", | ||
| "remote_htlc_basepoint_secret": "32df9c4dd46ab6210e74e81e15282106f8db883f45674eabb3324166c6513062", | ||
| "revocation_pubkey": "03e1ea1b8f5e4cae2dbac454a341ad5c3323b5827054b7e8b0497600010b31f860", |
There was a problem hiding this comment.
Could you provide the revocation_basepoint rather than the revocation_pubkey that's already been created from revocation_basepoint + per_commitment_point?
It's a bit hacky for me to override with the already derived pubkey in LDK.
There was a problem hiding this comment.
That should be doable, I'll do that early next week.
There was a problem hiding this comment.
Done in 3213327, let me know if that works for you.
There was a problem hiding this comment.
That's great news! Do you have a branch of ldk-server that I can use for cross-compat tests?
There was a problem hiding this comment.
All passing in lightningdevkit/rust-lightning#4202 🎉
Do you have a branch of ldk-server that I can use for cross-compat tests?
@tankyleo should be able to help you out with interop testing!
There was a problem hiding this comment.
That's great news! Do you have a branch of ldk-server that I can use for cross-compat tests?
So far have tested on mainnet with the PR in ldk-node, but will get a ldk-server branch ready.
It is usually simpler for implementations to plug the revocation basepoint in the key derivation functions rather than directly inject the derived revocation public key, so we provide that. The revocation public key can be derived as detailed in Bolt3 based on this `revocation_basepoint` and the `commitment_point`.
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.
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), capped at240 sats(and may thus be0 satwhen there are no trimmed outputs). Note that when the sum of trimmed outputs 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).
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!