Route blinding: add min_final_cltv_delta to aggregated CLTV delta

[valentinewallace]

Previously we were not including the min_final_cltv_delta in the aggregated BlindedPayInfo::cltv_expiry_delta.

This requirement was missing from the spec. It's now been added in lightning/bolts#1131.
IIUC, the spec is currently missing this requirement -- spec authors may have thought that it was implied. Another look at t-bast's gist https://gist.github.com/t-bast/b1371d357a2c5f3e8c09514a62db7079 tipped me off that it was missing in LDK.

[coderabbitai]

Walkthrough

The recent updates focus on enhancing the BlindedPath struct across various files, introducing a new parameter min_final_cltv_expiry_delta to improve the construction of blinded paths for payments. This modification is consistently applied in method calls and tests, ensuring the parameter's integration throughout the related functionality, especially in payment routing and testing scenarios.

Changes

Files	Change Summary
.../blinded_path/mod.rs, .../payment.rs	Added min_final_cltv_expiry_delta parameter to one_hop_for_payment and new_for_payment methods.
.../blinded_payment_tests.rs	Included TEST_FINAL_CLTV in function calls and adjusted cltv_expiry assertion in a test function.
.../routing/router.rs	Added MIN_FINAL_CLTV_EXPIRY_DELTA to imports and method calls related to BlindedPath.

🐇💫
In the realm of code, where paths are blind,
A rabbit hops, leaving old routes behind.
With a tweak and a twist, a new parameter in sight,
Ensuring payments journey through the night.
🌙✨

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

Share

• X
• Mastodon
• Reddit
• LinkedIn

---

Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>.
  • Generate unit-tests for this file.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit tests for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai generate interesting stats about this repository from git and render them as a table.
  • @coderabbitai show all the console.log statements in this repository.
  • @coderabbitai read src/utils.ts and generate unit tests.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (invoked as PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger a review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• The JSON schema for the configuration file is available here.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/coderabbit-overrides.v2.json

CodeRabbit Discord Community

Join our Discord Community to get help, request features, and share feedback.

[coderabbitai]

Review Status

Actionable comments generated: 0

Configuration used: CodeRabbit UI

Commits

Files that changed from the base of the PR and between 51d9ee3 and 2809ad7.

Files selected for processing (4)

• lightning/src/blinded_path/mod.rs (2 hunks)
• lightning/src/blinded_path/payment.rs (7 hunks)
• lightning/src/ln/blinded_payment_tests.rs (4 hunks)
• lightning/src/routing/router.rs (3 hunks)

Additional comments: 15

lightning/src/blinded_path/mod.rs (3)

• 88-96: The addition of min_final_cltv_expiry_delta in the one_hop_for_payment method correctly implements the requirement to include the minimum final CLTV expiry delta in the calculation for blinded payments. This change ensures that the CLTV delta calculation for route blinding is accurate.
• 111-119: The new_for_payment method has been updated to include the min_final_cltv_expiry_delta parameter, which is essential for correctly calculating the CLTV expiry delta for blinded payments. This modification aligns with the PR's objective to correct the oversight in the handling of min_final_cltv_delta.
• 117-119: The compute_payinfo function call within the new_for_payment method correctly includes the min_final_cltv_expiry_delta parameter. This ensures that the calculation for the CLTV expiry delta in blinded payments takes into account the minimum final CLTV expiry delta, aligning with the PR's objectives.

lightning/src/blinded_path/payment.rs (6)

• 218-219: The modification to the compute_payinfo function to include the min_final_cltv_expiry_delta parameter is correct. This change is necessary for accurately initializing the cltv_expiry_delta variable within the function, ensuring the inclusion of the minimum final CLTV expiry delta in the aggregated CLTV delta calculation.
• 344-347: The test case compute_payinfo in payment.rs has been correctly updated to include the min_final_cltv_expiry_delta parameter when calling the compute_payinfo function. This ensures that the tests validate the correct handling of the min_final_cltv_delta, aligning with the PR's objectives.
• 361-364: The test case compute_payinfo_1_hop has been correctly updated to pass the min_final_cltv_expiry_delta parameter to the compute_payinfo function. This update is necessary for testing the function's behavior with the inclusion of the minimum final CLTV expiry delta in the calculation.
• 415-415: The test case simple_aggregated_htlc_min correctly includes the min_final_cltv_expiry_delta parameter in its call to the compute_payinfo function. This ensures the test case aligns with the updated logic for calculating the CLTV expiry delta.
• 468-468: The test case aggregated_htlc_min has been updated to include the min_final_cltv_expiry_delta parameter when calling the compute_payinfo function. This change ensures the test accurately reflects the updated logic for handling the min_final_cltv_delta.
• 519-519: The test case aggregated_htlc_max correctly passes the min_final_cltv_expiry_delta parameter to the compute_payinfo function. This inclusion is crucial for testing the correct aggregation of the CLTV deltas with the updated logic.

lightning/src/ln/blinded_payment_tests.rs (3)

• 103-104: The usage of TEST_FINAL_CLTV in BlindedPath::one_hop_for_payment call ensures that the test accurately reflects the handling of min_final_cltv_delta. This change aligns with the PR's objective to correct the oversight in min_final_cltv_delta handling.
• 145-146: Similar to the previous comment, the usage of TEST_FINAL_CLTV in another BlindedPath::one_hop_for_payment call is consistent with the PR's objective and enhances the test's accuracy in reflecting the handling of min_final_cltv_delta.
• 694-694: The assertion to check the cltv_expiry value in the do_multi_hop_receiver_fail function with the ProcessPendingHTLCsCheck case is a critical addition. It ensures that the cltv_expiry is calculated correctly, considering the TEST_FINAL_CLTV. This change directly addresses the oversight in handling min_final_cltv_delta and is essential for validating the correctness of the implementation.

lightning/src/routing/router.rs (3)

• 19-19: The addition of MIN_FINAL_CLTV_EXPIRY_DELTA to the import statement from channelmanager is correctly aligned with the PR objectives to include the min_final_cltv_delta in the calculation of cltv_expiry_delta. This change ensures that the necessary constant is available for use in the router.rs file, which is crucial for the correct implementation of the route blinding feature as described.
• 142-143: The inclusion of MIN_FINAL_CLTV_EXPIRY_DELTA as an argument in the BlindedPath::new_for_payment method call is consistent with the PR's goal to correct the aggregated cltv_expiry_delta calculation. This ensures that the minimum final CLTV expiry delta is considered in the construction of a blinded path for payments, aligning with the intended functionality of route blinding. The change is logically placed and correctly implemented.
• 154-155: Similarly, the use of MIN_FINAL_CLTV_EXPIRY_DELTA as an argument in the BlindedPath::one_hop_for_payment method call is in line with the PR's objectives. This modification ensures that the route blinding feature correctly incorporates the minimum final CLTV expiry delta in its calculations, enhancing the privacy and efficiency of routing in the Lightning Network. The implementation here is correct and follows the intended logic.

[TheBlueMatt]

Didn't compare it to the spec changes but this makes sense to me. @jkczyz ?

[valentinewallace]

Rebased due to conflict and removed the last commit which was done in #2847.

[coderabbitai]

Review Status

Actionable comments generated: 0

Configuration used: CodeRabbit UI

Commits

Files that changed from the base of the PR and between a9d73c2 and fff1aa7.

Files selected for processing (4)

• lightning/src/blinded_path/mod.rs (2 hunks)
• lightning/src/blinded_path/payment.rs (7 hunks)
• lightning/src/ln/blinded_payment_tests.rs (4 hunks)
• lightning/src/routing/router.rs (3 hunks)

Additional comments: 10

lightning/src/blinded_path/mod.rs (2)

• 88-96: The addition of min_final_cltv_expiry_delta to one_hop_for_payment and its propagation to new_for_payment correctly implements the updated specification requirements. Ensure that all calls to these functions throughout the codebase are updated to include this new parameter.

Verification successful

---

The examination of the specific lines where one_hop_for_payment and new_for_payment are called within the codebase reveals that the min_final_cltv_expiry_delta parameter is indeed included in all calls to these functions. This confirms that the changes made to include min_final_cltv_expiry_delta in the function signatures are correctly implemented across the codebase, aligning with the updated specification requirements for route blinding in the Lightning Network.

• In router.rs, both functions are called with MIN_FINAL_CLTV_EXPIRY_DELTA as the parameter for min_final_cltv_expiry_delta.
• In blinded_payment_tests.rs, the test cases use TEST_FINAL_CLTV as u16 for the min_final_cltv_expiry_delta parameter, which is appropriate for testing purposes.
• The internal call within mod.rs itself correctly passes min_final_cltv_expiry_delta as a parameter.

This confirms that the review comment is accurate and the implementation adheres to the updated specifications, ensuring that all calls to these functions throughout the codebase are updated to include the new parameter.

Scripts Executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Search for calls to one_hop_for_payment and new_for_payment without the new parameter.
rg --type rust 'one_hop_for_payment\('
rg --type rust 'new_for_payment\('

Length of output: 538

---

---

Script:

#!/bin/bash
# Extract the specific lines of code for one_hop_for_payment and new_for_payment function calls
rg --type rust -C 3 'one_hop_for_payment\(' lightning/src/routing/router.rs
rg --type rust -C 3 'one_hop_for_payment\(' lightning/src/ln/blinded_payment_tests.rs
rg --type rust -C 3 'new_for_payment\(' lightning/src/routing/router.rs
rg --type rust -C 3 'new_for_payment\(' lightning/src/ln/blinded_payment_tests.rs
rg --type rust -C 3 'new_for_payment\(' lightning/src/blinded_path/mod.rs

Length of output: 1957

* 111-119: The inclusion of `min_final_cltv_expiry_delta` in `new_for_payment` and its use in `compute_payinfo` is correctly implemented. This change ensures the accurate calculation of `cltv_expiry_delta` for blinded payments. Verify that the handling of this parameter does not introduce any integer overflows or underflows in `compute_payinfo`.

lightning/src/blinded_path/payment.rs (1)

• 215-226: > 📝 NOTE

This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [218-347]

The update to compute_payinfo to include min_final_cltv_expiry_delta and its use in initializing cltv_expiry_delta is correctly implemented. The tests have been appropriately updated to pass this new parameter, validating the correct handling of min_final_cltv_expiry_delta in various scenarios. Ensure comprehensive test coverage for edge cases related to min_final_cltv_expiry_delta, such as extremely high or low values.

lightning/src/ln/blinded_payment_tests.rs (4)

• 64-64: TEST_FINAL_CLTV is added as a parameter to BlindedPath::new_for_payment function call. Ensure TEST_FINAL_CLTV is properly defined and initialized in this file or imported from a module where it is defined.
• 103-104: TEST_FINAL_CLTV is added as a parameter to BlindedPath::one_hop_for_payment function calls. Verify that TEST_FINAL_CLTV is correctly used and matches the expected type and value as per the updated specification.
• 145-146: Similar to previous comments, TEST_FINAL_CLTV is added to another BlindedPath::one_hop_for_payment call. Confirm consistency and correctness in its application across all test cases.
• 700-700: The assertion on line 700 checks the cltv_expiry against a calculated value including TEST_FINAL_CLTV. This is part of a test case designed to simulate a failure scenario. Ensure that the logic for calculating the expected cltv_expiry value is correct and aligns with the intended test scenario.

lightning/src/routing/router.rs (3)

• 17-17: Ensure that MIN_FINAL_CLTV_EXPIRY_DELTA is used consistently across the file and that its import aligns with the project's import organization conventions.
• 137-138: Verify that the addition of MIN_FINAL_CLTV_EXPIRY_DELTA as a parameter to BlindedPath::new_for_payment aligns with the method's updated signature and that the value passed is appropriate for the context.
• 148-150: Confirm that MIN_FINAL_CLTV_EXPIRY_DELTA is correctly applied in BlindedPath::one_hop_for_payment and that its inclusion does not introduce any logical errors or inconsistencies.

[jkczyz]

Probably could squash the commits, but otherwise LGTM.