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

Require `htlc_value_satoshis` in [pending] `HTLCUpdate`s

Public commit record

What the developer wrote

Authored by Matt Corallo

85/100 · Strong
Require `htlc_value_satoshis` in [pending] `HTLCUpdate`s

In 0.0.100 we started tracking the amounts being claimed in
`OnchainEvent::HTLCUpdate` and then also in
`MonitorEvent::HTLCUpdate`'s `HTLCUpdate`. It was always set, but
stored as an `Option` to support further downgrade. Because these
objects time out after `ANTI_REORG_DELAY` (6) blocks, there's not
really much reason to keep supporting backwards compatibility to
upgrade with such objects without an amount.

In 0.0.115, we started providing the amount in `PaymentForwarded`.
For whatever reason, despite the event only being generated in
cases where we had amounts, the field was added as an `Option`.

Still, in 0.0.118 we started generating them from both off-chain
and on-chain claims. For off-chain claims it was always set, but
for claims which originated from on-chain claims, the amounts came
from the `MonitorEvent::HTLCUpdate` and thus were always an
`Option`. If we no longer care about `MonitorEvent::HTLCUpdate`'s
without a claim amount, we no longer need to worry about
`Event::PaymentForwarded` either. Thus, we make it required here
as well.
✓ 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 removes the 'Option' wrapper from several HTLC amount fields, making them required instead of optional. It is a cleanup/refactoring change that simplifies the code by assuming the amount is always known. The commit message frames this as removing legacy downgrade support, not as fixing a security bug. There is no direct evidence in the diff of an exploitable vulnerability.

Recommended action

Treat as a compatibility/refactoring commit rather than a security fix. Reviewers should verify that all code paths that construct these objects indeed always populate the amount, and that the backward-compatibility break is acceptable for the supported upgrade window. No immediate security patch action is indicated by the commit itself.

Security signals we found

01

Removal of Option wrapper for financial amount fields

02

Serialization format change from optional to required TLV fields

03

Loss of backward compatibility with older serialized monitor/channel state

04

Potential deserialization failure if old state missing required amount fields

Risk score

Why this scored 25/100

Our methodology →
Potential impact 5/30
Exploitability 2/25
Stealth signal 3/15
Affected reach 4/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.