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

xpay: take over pay invocations by default.

Public commit record

What the developer wrote

Authored by Rusty Russell

90/100 · Strong
xpay: take over pay invocations by default.

The main change here is the error messages got better. Where that was
the case, and the test was not completely redundant with existing xpay
tests, I explicitly converted to calls to xpay (meaning the tests
will be kept when `pay` is finally removed).

Test changes:
1. deschash checking is old-pay only, keep that there.
2. Add debug logs for checks for using forwarding via scid in injectpaymentonion.
3. Don't assert that not all sendpays should have the invoice string: xpay does not try to be clever there.
4. We no longer check if invoices are already paid before routing, since injectpaymentonion will catch that for us.
5. Removed `test_pay_get_error_with_update` which has xpay equiv.

Changelog-Changed: JSON-RPC: `xpay` now handles `pay` command by default (use `xpay-handle-pay=false` to prevent this)
Changelog-Removed: JSON-RPC: `exclude` parameter to `pay` (when `xpay-handle-pay` is True): craft a layer with desired modifications and pass it to `xpay` `layers`.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
✓ 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 changes Core Lightning so that the newer 'xpay' plugin silently handles most calls to the older 'pay' command by default. It is a feature migration, not a security patch. The old 'pay' command is marked deprecated, and some of its options (like 'exclude') are removed when xpay takes over. The change is mostly about routing and error-message behavior, not about fixing a vulnerability.

Recommended action

Treat this as a behavioral change requiring release-note documentation and operator awareness, not as a security fix. Users and integrations relying on 'pay' options such as 'exclude', specific retry/attempt reporting via paystatus, or old error codes should test against xpay or set 'xpay-handle-pay=false' during migration. Review xpay's handling of in-flight payments and duplicate-invoice detection to ensure it matches operational expectations.

Security signals we found

01

Deprecation of a long-standing RPC command ('pay') and change in default routing implementation

02

Removal of the 'exclude' parameter from 'pay' when xpay-handle-pay is true

03

Behavior change: duplicate in-flight payment detection now handled differently by xpay

04

Behavior change: pre-routing 'already paid' check removed because injectpaymentonion is expected to catch duplicates

05

Test expectations updated to match new error strings and retry semantics

Risk score

Why this scored 39/100

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