Enforce MPP/AMP records in QueryRoutes and SendToRoute

[kartikangiras]

Change Description

Description of change / link to associated issue.

This PR enforces the inclusion of MPP (Multi-Path Payment) or AMP (Atomic Multi-Path) records in routes as required by the Lightning Network specification. Previously, QueryRoutes, BuildRoute, and SendToRoute RPCs allowed routes without payment secrets, which could lead to payment failures at the recipient.

fixes: #9952

Steps to Test

TestUnmarshallRouteMPPValidation- Verifies enforcement logic with 5 scenarios:

1. no_mpp_or_amp: Correctly rejects routes without MPP/AMP records

   • Expected: Error containing "final hop must include either an MPP record"
   • Validates specification compliance enforcement

2. with_mpp: Accepts routes with valid MPP records

   • Tests with valid 32-byte payment_addr and total_amt_msat
   • Confirms MPP payments work as expected

3. with_amp: Accepts routes with valid AMP records

   • Tests with valid root_share, set_id, and child_index
   • Confirms AMP payments work as expected

4. both_mpp_and_amp: Correctly rejects routes with both records

   • Expected: Error containing "cannot have both MPP and AMP"
   • Validates mutual exclusivity enforcement

5. blinded_no_mpp: Correctly exempts blinded paths from MPP/AMP requirement

   • Uses valid blinding_point and encrypted_data
   • Confirms blinded payments aren't broken by new validation

Existing Tests

• Updated all NewRouteRequest call sites in routing/pathfind_test.go and routing/router_test.go

Pull Request Checklist

Testing

• Your PR passes all CI checks.
• Tests covering the positive and negative (error paths) are included.
• Bug fixes contain tests triggering the bug to prevent regressions.

Code Style and Documentation

• The change is not insubstantial. Typo fixes are not accepted to fight bot spam.
• The change obeys the Code Documentation and Commenting guidelines, and lines wrap at 80.
• Commits follow the Ideal Git Commit Structure.
• Any new logging statements use an appropriate subsystem and logging level.
• Any new lncli commands have appropriate tags in the comments for the rpc in the proto file.
• There is a change description in the release notes, or [skip ci] in the commit message for small changes.

📝 Please see our Contribution Guidelines for further guidance.

[gemini-code-assist]

Summary of Changes

Hello @kartikangiras, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces critical updates to the Lightning Network's routing mechanisms by mandating the presence of Multi-Path Payment (MPP) or Atomic Multi-Path (AMP) records in payment routes. This change is essential for adhering to the Lightning Network specification and aims to eliminate payment failures caused by missing payment secrets. It involves extending RPC requests with new fields for these records and implementing robust validation checks to ensure all non-blinded routes are correctly formed, thereby enhancing payment reliability and protocol compliance.

Highlights

• MPP/AMP Record Enforcement: The pull request enforces the inclusion of Multi-Path Payment (MPP) or Atomic Multi-Path (AMP) records in routes for QueryRoutes and SendToRoute RPCs, aligning with the Lightning Network specification to prevent payment failures.
• New RPC Fields: New fields payment_addr (for MPP) and amp_record (for AMP) have been added to QueryRoutesRequest in lnrpc/lightning.proto and BuildRouteRequest in lnrpc/routerrpc/router.proto to support these records.
• Route Validation Logic: Validation has been introduced in UnmarshallRoute and SendToRouteV2 to ensure that the final hop of a non-blinded route contains either an MPP or an AMP record, but not both, as per specification. Blinded payments are exempt from this requirement.
• Internal Routing Updates: The internal NewRouteRequest function and RouteRequest struct in routing/router.go have been updated to accept and validate these new paymentAddr and amp parameters, ensuring mutual exclusivity.
• Comprehensive Testing: A new test file, lnrpc/routerrpc/mpp_validation_test.go, has been added to thoroughly test the new validation logic across various scenarios, including valid and invalid combinations of MPP/AMP records and blinded paths.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request enforces the inclusion of MPP or AMP records in routes for QueryRoutes, BuildRoute, and SendToRoute RPCs, aligning with the Lightning Network specification. The changes are well-structured and include comprehensive tests for the new validation logic. My review focuses on improving code maintainability by addressing duplicated validation logic and ensuring adherence to the repository's documentation style guide.

[alexbosworth]

is this introducing required fields without a deprecation time?

[kartikangiras]

is this introducing required fields without a deprecation time?

@alexbosworth yes this code change is introducing required fields without depreciation time as it includes no api breakage along with proper depreciation period.

[lightninglabs-deploy]

@kartikangiras, remember to re-request review from reviewers when ready