Prefer outbound SCID alias over real SCID when routing#4567
Prefer outbound SCID alias over real SCID when routing#4567Alkamal01 wants to merge 1 commit intolightningdevkit:mainfrom
Conversation
|
👋 I see @wpaulino was un-assigned. |
| no-std-check/target | ||
| msrv-no-dev-deps-check/target | ||
| lightning-tests/target | ||
| .claude |
There was a problem hiding this comment.
Nit: This .claude gitignore entry is unrelated to the SCID alias change. Consider dropping it from this PR and submitting it separately (or as part of a repo-housekeeping commit).
| let route_params = RouteParameters::from_payment_params_and_value(payment_params, recv_value); | ||
| let res = nodes[0].node.send_preflight_probes(route_params, None).unwrap(); | ||
|
|
||
| assert_eq!(res.len(), 2); |
There was a problem hiding this comment.
assert_eq!(res.len(), 2) is asserted here and again on line 1814 (assert_eq!(res.len(), expected_route.len())). The first one is redundant — consider removing one of them.
|
I've completed a thorough review of every file and hunk in this PR. All prior review comments have been addressed or are no longer applicable (the No new issues found. The core logic change (
|
b5156c6 to
181df48
Compare
TheBlueMatt
left a comment
There was a problem hiding this comment.
Thanks! One nit about comments but otherwise LGTM.
| // Our immediate peer sent UpdateFailMalformedHTLC because it couldn't understand the onion in | ||
| // the UpdateAddHTLC that we sent. | ||
| let short_channel_id = channels[0].0.contents.short_channel_id; | ||
| // get_outbound_payment_scid now prefers the alias SCID for the first hop, so the |
There was a problem hiding this comment.
claude loves to leave comments that describe what it did, describing things in terms of what it is changing and how things used to be, but that isn't actually a good comment. I'm not sure this needs a comment, but if it does it shouldn't be phrased as "X now does" but rather simply "The SCID in the failure should use the SCID alias as we specified in the route". This class of issues is repeated in a few places.
181df48 to
1ee9685
Compare
| /// | ||
| /// This is either the [`ChannelDetails::short_channel_id`], if set, or the | ||
| /// [`ChannelDetails::outbound_scid_alias`]. See those for more information. | ||
| /// This is either the [`ChannelDetails::outbound_scid_alias`], if set, or the | ||
| /// [`ChannelDetails::short_channel_id`]. The alias is preferred because with splices, | ||
| /// the real SCID can change when a splice confirms, whereas the alias remains stable. |
There was a problem hiding this comment.
Nit: The docstrings on short_channel_id (line 315-316) and outbound_scid_alias (lines 328-331) are now stale. They still say the alias is only used "in place of" the real SCID for 0-conf channels, but with this change the alias is now the preferred identifier for all outbound routes, not just a 0-conf fallback. Consider updating them to match the new semantics described here.
1ee9685 to
c49f1b4
Compare
| // Send a payment using the channel's alias SCID, which will be public in a few blocks once | ||
| // we can generate a channel_announcement. |
There was a problem hiding this comment.
Nit: The comment now reads "Send a payment using the channel's alias SCID, which will be public in a few blocks…" — but the alias SCID itself never becomes public. It's the channel that becomes public (announced via the real SCID in channel_announcement). The original wording ("real SCID, which will be public") was accurate for the real SCID; consider rewording to avoid implying the alias is what gets announced:
| // Send a payment using the channel's alias SCID, which will be public in a few blocks once | |
| // we can generate a channel_announcement. | |
| // Send a payment using the channel's alias SCID. The channel itself will be public in a few | |
| // blocks once we can generate a channel_announcement. |
c49f1b4 to
841d912
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #4567 +/- ##
==========================================
- Coverage 87.01% 87.00% -0.02%
==========================================
Files 163 163
Lines 108682 108742 +60
Branches 108682 108742 +60
==========================================
+ Hits 94572 94613 +41
- Misses 11631 11648 +17
- Partials 2479 2481 +2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| /// | ||
| /// For channels with [`confirmations_required`] set to `Some(0)`, [`outbound_scid_alias`] may | ||
| /// be used in place of this in outbound routes. See [`get_outbound_payment_scid`]. | ||
| /// [`outbound_scid_alias`] is preferred over this for outbound routes when set, as it remains |
There was a problem hiding this comment.
Just saying "X is preferred over this" is a bit of a weird doc for a POD struct field. THe comment before wasn't great either but let's be more explicit about why/when/how the other field is "preferred". Same below.
| // outbound alias, which is what acceptor's channel lookup uses. | ||
| let (route, payment_hash, _payment_preimage, payment_secret) = | ||
| get_route_and_payment_hash!(initiator, acceptor, 1_000_000); | ||
| get_route_and_payment_hash!(acceptor, initiator, 1_000_000); |
There was a problem hiding this comment.
This doesn't make any sense? Finding a route from the payee to the payer is going to result in the payment immediately failing cause we're trying to pay ourselves. That isn't solving the isue its just breaking the test.
There was a problem hiding this comment.
Good catch, that was a mistake on my side.
During the rebase, some unrelated changes slipped in (the test_splice_rbf_insufficient_feerate_high removal and div_ceil changes). I’ve reverted those.
On the routing issue: the problem wasn’t that we should route from payee to payer. The bug was that I was building the route from the initiator’s perspective, even though in this case the acceptor is the sender. That mismatch is what caused the confusion.
I’ve fixed it so the route is now constructed from the acceptor’s perspective, which keeps the direction correct and makes the test behave as intended.
I also updated the comment in onion_route_tests.rs to clarify the behavior.
e14566e to
f8f4404
Compare
…ent_scid With splicing, the real SCID changes when a splice confirms while the outbound_scid_alias remains stable. Prefer alias-first in get_outbound_payment_scid so routes built before a splice confirmation stay valid after. Also fix route direction in fail_splice_on_tx_complete_error and update onion_route_tests comment to state intent rather than describe change.
f8f4404 to
b91dd2d
Compare
Fixes #4249.
With splices, channels may spontaneously change SCIDs, making our assumption that SCIDs were more stable than SCID aliases in
ChannelDetails::get_outbound_payment_scidwrong. This swaps which we prefer, and fixes up the tests that break as a result.