Add support for zero-fee commitment format #3192
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
t-bast
force-pushed
the
zero-fee-commitments
branch
3 times, most recently
from
107182e to
03d3ac3
Compare
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #3192 +/- ##
==========================================
+ Coverage 86.43% 88.95% +2.51%
==========================================
Files 242 218 -24
Lines 22607 20538 -2069
Branches 832 810 -22
==========================================
- Hits 19541 18270 -1271
+ Misses 3066 2268 -798
🚀 New features to boost your workflow:
|
t-bast
force-pushed
the
zero-fee-commitments
branch
from
7532699 to
169c7a6
Compare
t-bast
force-pushed
the
zero-fee-commitments
branch
2 times, most recently
from
de9520c to
b13e59b
Compare
pm47
reviewed
Nov 12, 2025
Member
pm47
left a comment
pm47
left a comment
There was a problem hiding this comment.
LGTM, didn't review the publishing/funding logic.
eclair-core/src/main/scala/fr/acinq/eclair/transactions/Transactions.scala
Show resolved
Hide resolved
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.
It isn't delayed anymore for v3 transactions. We could use static wallet public key, but in most cases it wouldn't work and adds extra complexity so we don't do it. We add a comment in the documentation of this class to explain why we're always making a 2nd-stage transaction.
We apply slightly different validation for zero-fee commitments: - the commit feerate must be `0 sat/byte` - the max number of accepted HTLCs must be at most 114 - `update_fee` cannot be used We verify those requirements during channel creation and add tests for normal channel operation.
We add support for force-close zero-fee channels. When publishing the local commit, this works mostly the same way as other channel types. The only difference is that we don't even attempt to publish the commit tx individually: we always bundle it with the anchor transaction. When we detect the remote commit though, we're able to introduce some new behavior: - if we have a large enough main output, we use that to pay the fees of the remote commit tx (unless it is already confirmed), which avoids using a wallet input - otherwise, we spend the anchor output, which competes with the remote peer package Since we're only using the anchor transaction or our main output to spend the ephemeral anchor, we cannot publish HTLC txs until the commit tx is confirmed. We will in the future make *all* transactions go through the `ReplaceableTxPublisher`, and at the point we'll be able to simplify this, but it's too early for this refactoring, so for now we simply wait for the commit tx to be confirmed before publishing HTLC txs.
When using zero-fee commitments, we don't force-close when receiving an `error` from our peer: if they want to force-close the channel, they can publish their commitment instead of forcing us to publish ours. It is especially true when the commit tx doesn't pay any fees, because the publisher will pay the entire fees for the force-close. Note that for wallet peers, we could introduce a mechanism where they send us their signed commit tx in the error message if they don't have any wallet input to pay the fees, and we could be nice and publish it while paying the fees from our main output (which isn't delayed since it is the remote commit from our point of view).
t-bast
force-pushed
the
zero-fee-commitments
branch
from
1e7b755 to
00eb098
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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_feemechanism, have less dust exposure risk, and use an overall simpler state machine.If our peer publishes their commitment transaction, we use our main output to CPFP it (by also spending the ephemeral anchor), which provides a very efficient way (no additional wallet inputs involved) to force-close a channel.
In the future, we may want to use the
ReplaceableTxPublisherfor all force-close transactions, and use any transaction available to pay the commit fees directly from channel funds. This would make our codebase more consistent, but is a bigger change.