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

Remove TransactionU16LenLimited

Public commit record

What the developer wrote

Authored by Jeffrey Czyz

60/100 · Adequate
Remove TransactionU16LenLimited

TransactionU16LenLimited was used to limit Transaction serialization
size to u16::MAX. This was because messages can not be longer than
u16::MAX bytes when serialized for the transport layer. However, this
limit doesn't take into account other fields in a message containing a
Transaction, including the length of the transaction itself.

Remove TransactionU16LenLimited and instead check any user supplied
transactions in the context of the enclosing message (e.g. TxAddInput).
✓ Descriptive subject✓ Provides detailed explanatory context✓ Explains rationale or failure mode! Too few words to establish purpose
The short version

What changed, and why it matters

This commit removes a wrapper that limited individual Bitcoin transactions to 65,535 bytes. The old limit was too generous in some places and too strict in others: it did not account for other fields in the same message, so a transaction just under the limit could still make the overall wire message too large. The patch moves the size check into the context of the enclosing message (TxAddInput) and lets the transaction field hold a normal Bitcoin transaction. It is a correctness/refactoring change for the Lightning protocol implementation, not a clear-cut remote exploit.

Recommended action

Review whether `LN_MAX_MSG_LEN` enforcement is also needed when receiving or forwarding `TxAddInput` from a peer, and confirm that all call sites constructing `TxAddInput` now validate the total message size. Otherwise, no urgent action is required; treat as a normal correctness improvement.

Security signals we found

01

Removed a coarse per-field length limit that did not reflect the real wire-level constraint

02

Added context-aware length check before constructing TxAddInput messages

03

Changed deserialization to use FixedLengthReader bounded by the declared u16 length

04

Potential concern: deserialization no longer rejects a transaction whose own serialized length exceeds u16::MAX, because the length field itself is u16; however, any such value cannot be encoded on the wire

05

Potential concern: the new check is only applied to user-supplied funding inputs in channel.rs; received peer messages are parsed but not re-checked against LN_MAX_MSG_LEN in this diff

Risk score

Why this scored 44/100

Our methodology →
Potential impact 12/30
Exploitability 8/25
Stealth signal 6/15
Affected reach 7/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.