Skip to content

Make max_total_cltv_expiry_delta include the final CLTV #1358

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Mar 17, 2022

Conversation

TheBlueMatt
Copy link
Collaborator

This fixes an integer underflow found by the router fuzz target
in CI.

@codecov-commenter
Copy link

codecov-commenter commented Mar 10, 2022

Codecov Report

Merging #1358 (b8c9029) into main (2bba1d4) will increase coverage by 1.25%.
The diff coverage is 62.50%.

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #1358      +/-   ##
==========================================
+ Coverage   90.60%   91.86%   +1.25%     
==========================================
  Files          72       73       +1     
  Lines       40324    47508    +7184     
==========================================
+ Hits        36536    43643    +7107     
- Misses       3788     3865      +77     
Impacted Files Coverage Δ
lightning/src/routing/router.rs 94.03% <50.00%> (+1.63%) ⬆️
lightning/src/ln/functional_tests.rs 98.35% <100.00%> (+1.22%) ⬆️
lightning/src/ln/priv_short_conf_tests.rs 96.84% <0.00%> (ø)
lightning/src/ln/onion_route_tests.rs 97.62% <0.00%> (+<0.01%) ⬆️
lightning/src/ln/msgs.rs 85.96% <0.00%> (+0.07%) ⬆️
lightning/src/util/scid_utils.rs 99.35% <0.00%> (+0.18%) ⬆️
lightning/src/ln/functional_test_utils.rs 96.66% <0.00%> (+1.33%) ⬆️
lightning/src/ln/mod.rs 96.96% <0.00%> (+1.96%) ⬆️
... and 3 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2bba1d4...b8c9029. Read the comment docs.

@tnull
Copy link
Contributor

tnull commented Mar 10, 2022

Yikes, of course the final CLTV delta needs to be accounted for at that point! My bad, glad the fuzzer caught this..
Thank you for the fix. LGTM (besides the failing benchmark)

@jkczyz jkczyz self-requested a review March 10, 2022 21:12
@TheBlueMatt
Copy link
Collaborator Author

Added a new commit which fixes the benchmark.

Comment on lines 5479 to 5481
for (first_hop, params, amt) in route_endpoints.iter() {
assert!(get_route(&payer, params, &graph.read_only(), Some(&[first_hop]), *amt, 42, &DummyLogger{}, &scorer, &random_seed_bytes).is_ok());
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this will significantly increase the benchmark runtime. I tried doing something similar when refactoring the benchmarks without much luck.

I have the benchmarks running on my machine now for over an hour and have only seen one result so far:

running 6 tests
test routing::router::benches::generate_mpp_routes_with_default_scorer       ... bench: 10,138,522,397 ns/iter (+/- 541,770,074)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Grrr, I'd somehow thought the bencher was smarter than that :(.

Comment on lines +5097 to +5105
let route = get_route(&our_id, &feasible_payment_params, &network_graph, None, 100, 0, Arc::clone(&logger), &scorer, &random_seed_bytes).unwrap();
let path = route.paths[0].iter().map(|hop| hop.short_channel_id).collect::<Vec<_>>();
assert_ne!(path.len(), 0);

// But not if we exclude all paths on the basis of their accumulated CLTV delta
let fail_max_total_cltv_delta = 23;
let fail_payment_params = PaymentParameters::from_node_id(nodes[6]).with_route_hints(last_hops(&nodes))
.with_max_total_cltv_expiry_delta(fail_max_total_cltv_delta);
match get_route(&our_id, &fail_payment_params, &network_graph, None, 100, 42, Arc::clone(&logger), &scorer, &random_seed_bytes)
match get_route(&our_id, &fail_payment_params, &network_graph, None, 100, 0, Arc::clone(&logger), &scorer, &random_seed_bytes)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why make final_cltv_expiry_delta zero here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cause the test was failing, and setting it to 0 is the most obvious change that doesn't change the test semantics at all by emulating the previous behavior.

Comment on lines -869 to +874
let max_total_cltv_expiry_delta = payment_params.max_total_cltv_expiry_delta
let max_total_cltv_expiry_delta = (payment_params.max_total_cltv_expiry_delta - final_cltv_expiry_delta)
.checked_sub(2*MEDIAN_HOP_CLTV_EXPIRY_DELTA)
.unwrap_or(payment_params.max_total_cltv_expiry_delta);
.unwrap_or(payment_params.max_total_cltv_expiry_delta - final_cltv_expiry_delta);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To help clarify my understanding, does $next_hops_cltv_delta include final_cltv_expiry_delta? Or is this needed because $candidate.cltv_expiry_delta() is actually for the previous hop as adjusted later on line 1534 and thus final_cltv_expiry_delta was not accounted for?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand correctly, the latter is the case: at this point the final_cltv_expiry_delta has not been added and therefore needs to be accounted for. This is in contrast to later usages of payment_params.max_total_cltv_expiry_delta, as for example in add_random_cltv_offset(), where final_cltv_expiry_delta is already part of the paths' CTLV deltas.

@jkczyz jkczyz added this to the 0.0.106 milestone Mar 11, 2022
jkczyz
jkczyz previously approved these changes Mar 14, 2022
If the scoring in the routing benchmark causes us to take a
different path from the original scan, we may end up deciding that
the only path to a node has a too-high total CLTV delta, causing us
to panic in the benchmarking phase.

Here we simply check for that possibility and remove paths that
fail post-scoring.
This fixes an integer underflow found by the `router` fuzz target
in CI.
@TheBlueMatt
Copy link
Collaborator Author

Squashed without change.

@TheBlueMatt TheBlueMatt merged commit c244c78 into lightningdevkit:main Mar 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants