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

Support retired TLV fields in object-constructing macros

Public commit record

What the developer wrote

Authored by Jeffrey Czyz

85/100 · Strong
Support retired TLV fields in object-constructing macros

The retired field type was initially limited to manual
`write_tlv_fields!`/`read_tlv_fields!`-style implementations because the
macros which construct the deserialized object (`impl_ser_tlv_based!`,
the enum macros, and `impl_writeable_msg!`) emit a struct literal or
match pattern naming every field, and a retired field has no backing
struct field to name.

Extend the `lightning-macros` filters that already drop `legacy` fields
from those positions to also drop `retired` fields, and route
`impl_writeable_msg!`'s constructed literal through the same filter,
which it previously bypassed. This lets any TLV field list mark a
retired type number rather than falling back to a manual implementation
just to reserve one.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This commit is a feature enhancement for LDK's internal serialization macros. It allows developers to mark old protocol fields as 'retired' (reserved but no longer used) in more places, so those type numbers cannot be accidentally reused. The change itself is not a security bug fix; it is infrastructure that makes it easier to safely reserve obsolete TLV type numbers. There is no direct exploit here, but it helps prevent future protocol-versioning mistakes.

Recommended action

Treat as a normal feature/maintenance commit. Reviewers should confirm that the new retired-field handling does not accidentally drop fields that should still be parsed, and that the macro filters correctly distinguish 'retired' from active fields. No urgent security action is required.

Security signals we found

01

TLV type-number reservation mechanism extended to more macro-generated code paths

02

Prevents accidental reuse of retired protocol field type numbers

03

Avoids UnknownRequiredFeature decode failures for obsolete even-type fields

04

No memory-safety, cryptographic, or authentication changes present

05

No CVE, advisory, or vendor security disclosure referenced in commit

Risk score

Why this scored 29/100

Our methodology →
Potential impact 5/30
Exploitability 3/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.