CommitWatch RSS
AQ
← All projectsACINQ

Eclair

Scala implementation of a Lightning Network node.

BitcoinLightning NetworkNormal
Source repository ↗
Repository coverage

167 commits in the local evidence base

Every captured commit receives deterministic security triage and a separate communication-quality score. Security candidates and broader second-pass signals receive full-patch Ollama analysis.

33security candidates40second-pass queue26AI analyses
14commits · 30 days
16commits · 60 days
76commits · 180 days
167commits · 365 days
Backfill bands
Aug 5 → Feb 691 seen11 candidatesComplete
Feb 6 → Jun 660 seen5 candidatesComplete
Jun 6 → Jul 62 seen0 candidatesComplete
Jul 6 → Aug 514 seen0 candidatesComplete
Commit communication

Does the history explain itself?

Message quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.

78/100 average clarity
100Strong · 80–100
47Adequate · 60–79
14Thin · 40–59
6Opaque · 0–39
1security candidate with opaque commit messaging
Read the scoring rubric →
Developer activity

Who is changing the project?

Public Git author strings; identities are not independently verified.

DeveloperCommitsCandidatesAnalyzedHigh riskMessage avg.
Bastien Teinturier1132219081
Fabrice Drouin1465077
pm471831067
Thomas HUET1610075
Nishant Bansal211084
rorp200077
ekzyis100058
Rusty Russell100081
Analysis record

Published AI watches

Last scanned 20 minutes ago

Low 47 AI analysisMessage 88 · Strong
AQ ACINQEclair BitcoinLightning Network

Ignore repeated invalid `tx_signatures` (#3328)

This update changes how the Eclair Lightning node handles repeated bad 'tx_signatures' messages from a peer during dual-funded channel opens and splices. Previously, every bad signature was processed and logged, which could waste CPU and d…

Rate-limiting of invalid peer messages (tx_signatures) to prevent repeated CPU/disk consumptionRemoval of unnecessary DB writes on shutdown receipt, reducing disk-wear and potential DoS surfaceNo channel force-close on invalid signatures; node remains open and waits for on-chain confirmation
823341e6by Bastien Teinturier+74−402 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
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 34 AI analysisMessage 88 · Strong
AQ ACINQEclair BitcoinLightning Network

Refactor attribution data (#3320)

This commit is a code refactor of how Eclair handles 'attribution data'—extra encrypted timing and accountability information attached to Lightning payment success and failure messages. It restructures the code to support future trampoline…

Refactor of cryptographic attribution-data creation/verificationNew shared-secret extraction path parses trampoline onion and path-key/blinded-path stateAttribution data now explicitly suppressed for blinded-route intermediate nodes
4b9ba010by Bastien Teinturier+228−1096 files
No security note in commit
Open full analysis →Source commit ↗
Low 34 AI analysisMessage 100 · Strong
AQ ACINQEclair BitcoinLightning Network

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

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 …

Large feature addition (+1618/-276 across 42 files) touching consensus-sensitive transaction construction and signingNew experimental channel type disabled by default; requires explicit opt-in via eclair.confImplements draft BOLT specification (lightning/bolts#1228), not a finalized standard
35403401by Bastien Teinturier+1618−27642 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 ↗
Low 35 AI analysisMessage 93 · Strong
AQ ACINQEclair BitcoinLightning Network

Add support for the official splicing protocol (#2887)

This commit adds official Lightning channel splicing support to Eclair and replaces an experimental protocol. It includes backwards-compatibility shims for older Phoenix wallets, changes how reconnection messages request retransmission of …

Protocol state machine changes for interactive transaction signing and reconnection retransmissionBackwards-compatibility shim that multiplexes two protocol versions based on peer feature bitsTLV type-number collision handling between official and experimental splicing protocols
68b0096aby Bastien Teinturier+867−30524 files
No security note in commit
Open full analysis →Source commit ↗
Low 32 AI analysisMessage 96 · Strong
AQ ACINQEclair BitcoinLightning Network

Store our closing_complete in the simple close session (#3289)

This commit changes how Eclair (a Bitcoin Lightning node) remembers its own closing signatures during a mutual channel close. Previously, the code re-generated signing nonces and re-signed closing transactions when the peer's signature arr…

MuSig2 nonce handling changed: local partial signatures are now stored and reused instead of regeneratedEarly signature validation added for peer's partial signature before final transaction aggregationRemoved CloserNonces helper that generated three random nonces per closing attempt
da7cd962by Fabrice Drouin+24−384 files
No security note in commit
Open full analysis →Source commit ↗
Low 35 AI analysisMessage 86 · Strong
AQ ACINQEclair BitcoinLightning Network

Add backwards-compatible parts of the official splicing protocol (#3261)

This commit updates the Eclair Lightning node software to support a new, backwards-compatible draft of the official Bitcoin Lightning 'splicing' protocol. It adds a funding transaction identifier to commitment signatures and introduces a '…

Adds disambiguation of commitment signatures by funding transaction ID, reducing risk of applying a signature to the wrong commitment during multi-funding splicingIntroduces a new odd-length message (start_batch) and odd TLV (FundingTx), which unknown peers should ignore per Lightning spec conventionsMaintains legacy experimental batch TLV for backwards compatibility
129df369by Bastien Teinturier+309−5112 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 76 · Adequate
AQ ACINQEclair BitcoinLightning Network

Add fuzzing infrastructure (#3276)

This commit adds a new testing-only module that uses a fuzzing tool called Jazzer to automatically throw random data at Eclair's Lightning message parsers. It does not change any production code, network behavior, or security logic. It is …

New test-only fuzzing module addedNo production code changesNo network-facing or cryptographic logic modified
e6c3d6efby Nishant Bansal+363−08 files
No security note in commit
Open full analysis →Source commit ↗
Informational 22 AI analysisMessage 76 · Adequate
AQ ACINQEclair BitcoinLightning Network

Use bitcoin-lib 0.47 (#3268)

This commit updates Eclair to use a newer version of its underlying Bitcoin library (bitcoin-lib 0.47). Most changes are mechanical: replacing local helper functions with new library-provided equivalents for encoding signatures and signing…

Dependency version bump for bitcoin-lib and secp256k1-kmpRefactor of ECDSA signature encoding/signing code pathsRemoval of local DER conversion helpers in favor of library-provided methods
5e741b1aby Fabrice Drouin+66−676 files
No security note in commit
Open full analysis →Source commit ↗
Informational 19 AI analysisMessage 81 · Strong
AQ ACINQEclair BitcoinLightning Network

Add duration information to payment events (#3241)

This commit is a refactoring and observability improvement for the Eclair Lightning node. It adds start/end timestamps to payment events and failures, renames some timestamp fields for consistency, and updates how payment hashes are derive…

Refactoring of payment event data model with new timestamp fieldsPayment hash now derived from preimage instead of passed separatelyRemoval of WaitingToRelayPayment from JSON type hints
9856db85by Bastien Teinturier+407−35532 files
No security note in commit
Open full analysis →Source commit ↗
Low 27 AI analysisMessage 81 · Strong
AQ ACINQEclair BitcoinLightning Network

Use bitcoin-lib 0.46 (taproot tweak refactor) (#3225)

This commit updates Eclair to use a newer version of its underlying Bitcoin library (bitcoin-lib 0.46). The main change is a code refactor in how Taproot addresses and scripts are created: instead of passing an optional script tree, caller…

Dependency version bump (bitcoin-lib 0.45.1 -> 0.46)Taproot script construction API refactorNo explicit security claim in commit message or diff
53747cc5by Fabrice Drouin+56−2912 files
No security note in commit
Open full analysis →Source commit ↗
Informational 12 AI analysisMessage 43 · Thin
AQ ACINQEclair BitcoinLightning Network

Update `bitcoin-lib` (#3213)

This is a routine dependency update for Eclair, a Bitcoin Lightning node. It bumps the internal 'bitcoin-lib' library from version 0.45 to 0.45.1 and its related 'bitcoin-kmp-jvm' component from 0.28.0 to 0.28.1. The commit message says th…

Dependency version bump onlyNo source code changes in commitNo security-related wording in commit message or diff
df75ed5aby Bastien Teinturier+5−52 files
No security note in commit
Open full analysis →Source commit ↗
Low 35 AI analysisMessage 100 · Strong
AQ ACINQEclair BitcoinLightning Network

Use 73 bytes der-encoded signatures in weight estimation (#3210)

This commit adjusts how Eclair estimates the 'weight' (a measure of transaction size used to calculate Bitcoin mining fees) for funding inputs in Lightning channel transactions. It increases the assumed signature size from 72 to 73 bytes, …

Fee-estimation mismatch between implementations could cause interactive-tx negotiation failuresUnder-estimated weight could lead to insufficient fees if a 73-byte high-S signature is accepted by minersChange aligns with BOLT 3 recommendation and LDK behavior
bfe34ab1by Bastien Teinturier+5−32 files
No security note in commit
Open full analysis →Source commit ↗
Low 47 AI analysisMessage 81 · Strong
AQ ACINQEclair BitcoinLightning Network

Allow aborting liquidity purchases after signing (#3206)

This commit fixes a bug in Eclair, a Bitcoin Lightning Network node implementation. When a user tried to buy extra spending capacity (a 'liquidity purchase') and the remote peer backed out after the local node had already signed, Eclair ke…

Fixes a denial-of-service / availability issue where upstream HTLCs were held until near CLTV expiry after a peer-aborted liquidity purchaseAdds explicit handling for tx_abort after local signing in dual-funded opens and splicesIntroduces LiquidityPurchaseAborted event and matching cleanup in Peer
5e1a4882by Bastien Teinturier+137−76 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 26 · Opaque
AQ ACINQEclair BitcoinLightning Network

Nits (#3203)

This commit is a small cleanup pull request titled 'Nits'. It fixes a typo in documentation, corrects a log message to show the right commitment format name, changes a debug log to info level for transaction signing, adds structured loggin…

7ef3c4b2by pm47+7−85 files
No security note in commit
Open full analysis →Source commit ↗
Low 34 AI analysisMessage 98 · Strong
AQ ACINQEclair BitcoinLightning Network

Remove support for non-anchor channels (#3173)

This commit removes support for older Lightning channel types ('static_remotekey' and 'default' channels) from the Eclair node software. It is a deliberate feature-removal change announced in the previous release. The main risk is operatio…

Removal of legacy commitment format support reduces attack surface for fee-manipulation and transaction-malleability issues present in pre-anchor channels.Simplified fee tolerance removes the 'too low' feerate check, relying on anchor/taproot CPFP/RBF behavior.Explicit channel_type requirement prevents silent downgrade to weaker channel types.
9911cb73by Bastien Teinturier+1129−394286 files
No security note in commit
Open full analysis →Source commit ↗
Low 34 AI analysisMessage 100 · Strong
AQ ACINQEclair BitcoinLightning Network

Configure bitcoind test instances to use bech32m addresses (#3195)

This commit updates Eclair's Bitcoin Core integration to use taproot (bech32m) addresses by default and fixes a fee-calculation bug where the anchor output amount was not being counted. The fee bug caused on-chain fees to be undercounted b…

Fee calculation bug fixed in ReplaceableTxFunder.scalaAnchor output amount (330 sats) now included in currentFee computationDefault bitcoind address type changed to bech32m/taproot
9771b2d8by Bastien Teinturier+25−247 files
No security note in commit
Open full analysis →Source commit ↗
Low 29 AI analysisMessage 81 · Strong
AQ ACINQEclair BitcoinLightning Network

Add `DATA_CLOSED` class when active channel is closed (#3170)

This commit refactors how Eclair stores closed Lightning channels. Instead of keeping all closed channel data in the same table as active channels, it moves them to a dedicated table with only essential summary information. The main stated…

DoS mitigation: channels that never confirmed or had nothing at stake are no longer persisted in the databaseDatabase schema migration removes foreign key constraint on htlc_infosNew closed-channel data class stores only minimal, stringified fields to avoid future backwards-compatibility issues
16a309e4by Bastien Teinturier+762−20426 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Repository ledger

Explore captured commits

Expand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.

AI review queuedBack to dev (#3197)by Bastien Teinturier · ddf75bc6 · Oct 27, 2025 · 7 filesMessage 36 · OpaqueTriage 0Details
Commit message · Bastien Teinturier

Back to dev (#3197)

After the v0.13.1 release.

36/100 · OpaqueMessage clarity
✓ Subject identifies a change✓ Links an issue, advisory, or supporting reference! No meaningful explanatory body
Why it was queued
second-pass: opaque commit message
AI review queuedCreate fresh shutdown nonce on reconnection (#3184)by Bastien Teinturier · d1863f94 · Oct 8, 2025 · 2 filesMessage 93 · StrongTriage 0Details
Commit message · Bastien Teinturier

Create fresh shutdown nonce on reconnection (#3184)

When we disconnect after sending `shutdown`, we must re-send `shutdown`.
When using taproot, we must generate a fresh nonce and store the private
nonce locally, otherwise we won't be able to create our `closing_sig`.

93/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Links an issue, advisory, or supporting reference
Why it was queued
second-pass: broader security terminology
AI review queuedNits (#3183)by pm47 · cc75b135 · Sep 30, 2025 · 2 filesMessage 26 · OpaqueTriage 7Details
Commit message · pm47

Nits (#3183)

26/100 · OpaqueMessage clarity
✓ Subject identifies a change✓ Links an issue, advisory, or supporting reference! Too few words to establish purpose! No meaningful explanatory body
Why it was queued
parser or protocol pathsecond-pass: opaque commit messagesecond-pass: security-sensitive path
AI review queuedFix encoding of channel type TLV in splice_init/splice_ack (#3178)by Fabrice Drouin · 5b4368a6 · Sep 23, 2025 · 2 filesMessage 81 · StrongTriage 7Details
Commit message · Fabrice Drouin

Fix encoding of channel type TLV in splice_init/splice_ack (#3178)

Fix encoding of channel type TLV in splice_init/splice_ack

The channel type codec that we use is a "TLV field codec", wrapping it in a tlvField() codec was wrong
and messed up the encoding.

Co-authored-by: Bastien Teinturier <31281497+t-bast@users.noreply.github.com>

81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
parser or protocol pathsecond-pass: security-sensitive path
AI review queuedReject offers with some fields present but empty (#3175)by Thomas HUET · abe2cc9c · Sep 22, 2025 · 6 filesMessage 81 · StrongTriage 7Details
Commit message · Thomas HUET

Reject offers with some fields present but empty (#3175)

Offers or invoices where the fields `offer_chains`, `offer_paths`, `invoice_paths`, `invoice_blindedpay` are present but empty are considered invalid.
While the spec does not necessarily rejects them explicitly, they can't be paid.

81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
parser or protocol pathsecond-pass: security-sensitive path
AI review queuedResign next remote commit on reconnection (#3157)by Bastien Teinturier · 379abc55 · Sep 12, 2025 · 11 filesMessage 88 · StrongTriage 0Details
Commit message · Bastien Teinturier

Resign next remote commit on reconnection (#3157)

We previously retransmitted our last `commit_sig` on reconnection if it
hadn't been received by our peer, without changing it. This can be an
issue for taproot channels when remote nodes don't use deterministic
nonce derivation, because their nonce may be different on reconnection
and our previous `commit_sig` would thus not be valid anymore.

We now re-sign the next commitment on reconnection, using the latest
nonces we receive from `channel_reestablish`.

88/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Links an issue, advisory, or supporting reference
Why it was queued
second-pass: broader security terminology
AI review queuedUpdate taproot commit weight to match `lnd` (#3158)by Bastien Teinturier · a7e57ea7 · Sep 11, 2025 · 1 fileMessage 81 · StrongTriage 12Details
Commit message · Bastien Teinturier

Update taproot commit weight to match `lnd` (#3158)

`lnd` uses a pessimistic weight estimate, assuming that varints take
5 bytes instead of 1 (when encoding the number of inputs and outputs
of the transaction).

81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI review queuedRemove legacy channel codecs and DB migrations (#3150)by Bastien Teinturier · ae3e44be · Sep 11, 2025 · 100 filesMessage 100 · StrongTriage 17Details
Commit message · Bastien Teinturier

Remove legacy channel codecs and DB migrations (#3150)

* Remove legacy channel codecs

We remove legacy channel codecs (versions earlier than v5). We also
remove the corresponding DB migrations: if node operators try to
upgrade from a version of eclair that is older than v0.13, we tell
them to first run the v0.13 version to migrate their channel data.

We regenerate serialization backwards-compatibility test vectors
based on anchor outputs or taproot channel types.

* Check channels DB version early

We check the channels DB version before running any DB migration, to
ensure that node operators can safely run the v0.13 release first.
Otherwise we may have started migrating an unrelated table to a newer
version that isn't included in the v0.13 release, which would thus
fail at start-up.

* Remove migration from `sqlite` to `postgres`

We now expect users to directly use `postgres` if they expect their node
to become large. The `sqlite` option should only be used for small nodes
for individuals, where it is performant enough.

100/100 · StrongMessage clarity
✓ 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
Why it was queued
fuzzing or regression evidencesigning or wallet pathsecond-pass: unusually broad changesecond-pass: security-sensitive path
AI review queuedBack to dev (#3155)by Bastien Teinturier · 3abc17f9 · Sep 10, 2025 · 7 filesMessage 36 · OpaqueTriage 0Details
Commit message · Bastien Teinturier

Back to dev (#3155)

After the v0.13.0 release.

36/100 · OpaqueMessage clarity
✓ Subject identifies a change✓ Links an issue, advisory, or supporting reference! No meaningful explanatory body
Why it was queued
second-pass: opaque commit message
AI review queuedRelax taproot feature dependency (#3161)by Bastien Teinturier · 60751962 · Sep 10, 2025 · 1 fileMessage 76 · AdequateTriage 0Details
Commit message · Bastien Teinturier

Relax taproot feature dependency (#3161)

It appears that `lnd` nodes don't always set `option_simple_close`
when setting `taproot_staging`, which creates disconnection issues.

We will enforce this for the official taproot feature bit, but we
should relax it for the staging bit.

76/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
second-pass: broader security terminology
AI review queuedCatch close commands in `Offline(WaitForDualFundingSigned)` (#3159)by pm47 · c9ff5019 · Sep 9, 2025 · 2 filesMessage 85 · StrongTriage 12Details
Commit message · pm47

Catch close commands in `Offline(WaitForDualFundingSigned)` (#3159)

They were previously ignored because we don't yet have a commitment.

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Explains rationale or failure mode✓ Links an issue, advisory, or supporting reference
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI review queuedUse helpers for feerates conversions (#3156)by pm47 · 70a2e297 · Sep 9, 2025 · 19 filesMessage 68 · AdequateTriage 7Details
Commit message · pm47

Use helpers for feerates conversions (#3156)

It saves tedious double parentheses: `FeeratePerKw(FeeratePerByte(1 sat))` -> `FeeratePerByte(1 sat).perKw`.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Links an issue, advisory, or supporting reference
Why it was queued
parser or protocol pathsecond-pass: security-sensitive path
AI review queuedFix minor incompatibilities with feature branches (#3148)by Bastien Teinturier · 3d5fd334 · Sep 1, 2025 · 9 filesMessage 81 · StrongTriage 7Details
Commit message · Bastien Teinturier

Fix minor incompatibilities with feature branches (#3148)

* Fix conflict with custom TLVs for `prevtxout`

We already use TLV types 1107 and 1109 for our experimental
swap-in-potentiam implementation.

* Store spent outpoints for confirmed funding txs

This can be used in feature branches to catch double-spending issues
across interactive-tx sessions early in the flow.

81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
parser or protocol pathsecond-pass: security-sensitive path
AI review queuedSplit commit nonces from funding nonce in `tx_complete` (#3145)by Bastien Teinturier · d7ee6638 · Aug 25, 2025 · 7 filesMessage 81 · StrongTriage 7Details
Commit message · Bastien Teinturier

Split commit nonces from funding nonce in `tx_complete` (#3145)

The commit nonces and funding nonce provided in `tx_complete` are
actually completely orthogonal:

- the commit nonces must be provided whenever the *next* commitment
format is using taproot
- the funding nonce must be provided whenever the *previous* commitment
format is using taproot

It thus makes more sense to split them into separate TLVs.

81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
parser or protocol pathsecond-pass: broader security terminologysecond-pass: security-sensitive path
AI review queuedOffers with currency must set amount. (#3140)by Thomas HUET · b651e5b9 · Aug 19, 2025 · 2 filesMessage 78 · AdequateTriage 7Details
Commit message · Thomas HUET

Offers with currency must set amount. (#3140)

Adds check and corresponding test from lightning/bolts#1279

78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
parser or protocol pathsecond-pass: security-sensitive path