-
Notifications
You must be signed in to change notification settings - Fork 456
Prefer outbound SCID alias over real SCID when routing #4567
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -312,8 +312,8 @@ pub struct ChannelDetails { | |
| /// Note that if [`inbound_scid_alias`] is set, it must be used for invoices and inbound | ||
| /// payments instead of this. See [`get_inbound_payment_scid`]. | ||
| /// | ||
| /// 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 | ||
| /// stable across splices. See [`get_outbound_payment_scid`]. | ||
| /// | ||
| /// When a channel is spliced, this continues to refer to the original pre-splice channel | ||
| /// state until the splice transaction reaches sufficient confirmations to be locked (and we | ||
|
|
@@ -323,12 +323,10 @@ pub struct ChannelDetails { | |
| /// [`outbound_scid_alias`]: Self::outbound_scid_alias | ||
| /// [`get_inbound_payment_scid`]: Self::get_inbound_payment_scid | ||
| /// [`get_outbound_payment_scid`]: Self::get_outbound_payment_scid | ||
| /// [`confirmations_required`]: Self::confirmations_required | ||
| pub short_channel_id: Option<u64>, | ||
| /// An optional [`short_channel_id`] alias for this channel, randomly generated by us and | ||
| /// usable in place of [`short_channel_id`] to reference the channel in outbound routes when | ||
| /// the channel has not yet been confirmed (as long as [`confirmations_required`] is | ||
| /// `Some(0)`). | ||
| /// preferred over [`short_channel_id`] for outbound routes when set. Unlike the real SCID, | ||
| /// the alias remains stable across splices. | ||
| /// | ||
| /// This will be `None` as long as the channel is not available for routing outbound payments. | ||
| /// | ||
|
|
@@ -337,7 +335,6 @@ pub struct ChannelDetails { | |
| /// exchange `splice_locked` messages with our peer). | ||
| /// | ||
| /// [`short_channel_id`]: Self::short_channel_id | ||
| /// [`confirmations_required`]: Self::confirmations_required | ||
| pub outbound_scid_alias: Option<u64>, | ||
| /// An optional [`short_channel_id`] alias for this channel, randomly generated by our | ||
| /// counterparty and usable in place of [`short_channel_id`] in invoice route hints. Our | ||
|
|
@@ -496,12 +493,13 @@ impl ChannelDetails { | |
| /// This should be used in [`Route`]s to describe the first hop or in other contexts where | ||
| /// we're sending or forwarding a payment outbound over this channel. | ||
| /// | ||
| /// 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. | ||
|
Comment on lines
495
to
+498
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nit: The docstrings on |
||
| /// | ||
| /// [`Route`]: crate::routing::router::Route | ||
| pub fn get_outbound_payment_scid(&self) -> Option<u64> { | ||
| self.short_channel_id.or(self.outbound_scid_alias) | ||
| self.outbound_scid_alias.or(self.short_channel_id) | ||
| } | ||
|
|
||
| /// Gets the funding output for this channel, if available. | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -2678,7 +2678,7 @@ fn fail_splice_on_tx_complete_error() { | |
|
|
||
| // Queue an outgoing HTLC to the holding cell. It should be freed once we exit quiescence. | ||
| 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); | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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.
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good catch, that was a mistake on my side. 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 |
||
| let onion = RecipientOnionFields::secret_only(payment_secret, 1_000_000); | ||
| let payment_id = PaymentId(payment_hash.0); | ||
| acceptor.node.send_payment_with_route(route, payment_hash, onion, payment_id).unwrap(); | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.