CommitWatch RSS
AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 34 Bitcoin

Add support for zero-fee commitment format (#3192)

AQ35403401 View source ↗
Public commit record

What the developer wrote

Authored by Bastien Teinturier

100/100 · Strong
Add support for zero-fee commitment format (#3192)

* Add support for zero-fee commitment format

We add support for the zero-fee commitment format specified in
https://github.com/lightning/bolts/pull/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.

* Rename `ClaimRemoteDelayedOutputTx`

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.

* Validate channel parameters

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.

* Handle force-closing zero-fee channels

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.

* Don't force-close on remote `error`

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).
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit adds an experimental new Lightning channel type to Eclair called 'zero-fee commitments.' It is a large feature patch implementing a draft BOLT specification (PR 1228), not a fix for a known vulnerability. The change introduces new transaction formats, validation rules, and force-close behavior. Because it is experimental, disabled by default, and extensively tested, it is unlikely to be an immediate security issue, but any large change to consensus-sensitive transaction code carries risk of subtle bugs.

Recommended action

Treat this as a high-risk feature addition requiring careful review and testing before enabling in production. Keep the feature disabled by default until the BOLT specification is finalized and the implementation has been audited. Monitor for follow-up fixes related to transaction validation, fee accounting, and edge cases in force-close paths.

Security signals we found

01

Large feature addition (+1618/-276 across 42 files) touching consensus-sensitive transaction construction and signing

02

New experimental channel type disabled by default; requires explicit opt-in via eclair.conf

03

Implements draft BOLT specification (lightning/bolts#1228), not a finalized standard

04

Changes force-close behavior: no longer auto-publishes local commit tx alone for zero-fee channels; bundles with anchor tx

05

Changes error handling: ignores remote 'error' message for zero-fee channels instead of force-closing

06

Adds new validation limits (max 114 HTLCs, 0 sat/byte feerate, no update_fee)

07

Renames and restructures claim transactions for remote commitment outputs

08

Adds new P2A (pay-to-anchor) redeem path and v3 transaction version handling

Risk score

Why this scored 34/100

Our methodology →
Potential impact 8/30
Exploitability 5/25
Stealth signal 4/15
Affected reach 6/15
Confidence 7/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.

More from Eclair

Related watches

Informational 22 AI analysisMessage 53 · Thin
AQ ACINQEclair BitcoinLightning Network

Use bitcoin-lib 0.48 (#3316)

This commit updates Eclair's underlying Bitcoin library from version 0.47 to 0.48 and makes small code adjustments to match the new library's API. The changes touch how private keys are derived and how test data is converted. There is no d…

Dependency version bump of cryptographic Bitcoin libraryPrivate key derivation code modifiedTaproot/MuSig2 test vector code adjusted
743dcdd1by Fabrice Drouin+8−44 files
No security note in commit
Open full analysis →Source commit ↗
Low 36 AI analysisMessage 81 · Strong
AQ ACINQEclair BitcoinLightning Network

Bump org.postgresql:postgresql version (#3305)

This commit updates the PostgreSQL database driver used by the Eclair Lightning node software from version 42.7.8 to 42.7.11. The commit message says this fixes a vulnerability that could allow denial-of-service (DoS) attacks if a node con…

Dependency version bump for security fixVendor-disclosed potential DoS vector via untrusted database hostChecksum file updated for reproducible builds
76da19f1by Bastien Teinturier+4−42 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 100 · Strong
AQ ACINQEclair BitcoinLightning Network

Fix flaky DER signature weight test (#3299)

This commit only adjusts a flaky unit test that checks transaction weight estimates. It widens the allowed tolerance for variable-length ECDSA signatures when two signatures are involved instead of one. There is no change to production cod…

0f5d4b89by Bastien Teinturier+4−51 file
No security note in commit
Open full analysis →Source commit ↗