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

Include MPP payment amount in `RecipientOnionFields`

Public commit record

What the developer wrote

Authored by Matt Corallo

95/100 · Strong
Include MPP payment amount in `RecipientOnionFields`

In some uses of LDK we need the ability to send HTLCs for only a
portion of some larger MPP payment. This allows payers to make
single payments which spend funds from multiple wallets, which may
be important for ecash wallets holding funds in multiple mints or
graduated wallets which hold funds across a trusted wallet and a
self-custodial wallet.

In order to allow for this, we need to separate the concept of the
payment amount from the onion MPP amount. Here we start this
process by adding a `total_mpp_amount_msat` field to
`RecipientOnionFields` (which is the appropriate place for a field
describing something in the recipient onion).

We currently always assert that it is equal to the existing fields,
but will relax this in the coming commit(s).

We also start including a payment preimage on probe attempts,
which appears to have been the intent of the code, but which did
not work correctly.

The bulk of the test updates were done by Claude.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit is a preparatory refactor in LDK's payment-sending code. It adds a new `total_mpp_amount_msat` field to `RecipientOnionFields` so that, in future commits, a payer can send an HTLC that is only one part of a larger multi-part payment. For now the new field is always required and is asserted to match the existing payment amount, so behavior is unchanged. The commit also fixes a small related bug where probe payments were not including a payment preimage as intended. There is no immediate security vulnerability here; it is a feature-building change with a minor bug fix.

Recommended action

No immediate action required. Treat as a normal feature refactor. Monitor the follow-up commits that will relax the equality assertion, because that is where actual MPP-split behavior and any associated security checks will be introduced.

Security signals we found

01

New required field added to a core payment API (`RecipientOnionFields`)

02

Serialization compatibility wrapper introduced for persisted `ClaimableHTLC` onion fields

03

Assertion added that new `total_mpp_amount_msat` must equal existing amount (currently enforced)

04

Probe preimage inclusion fixed

05

Large test-only refactor with no production logic change to payment validation

Risk score

Why this scored 36/100

Our methodology →
Potential impact 8/30
Exploitability 5/25
Stealth signal 5/15
Affected reach 8/15
Confidence 7/10
Evidence quality 3/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.