Skip to content
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

peel_payment_onion static fn in channelmanager #2700

Merged
merged 3 commits into from
Nov 16, 2023

Conversation

Evanfeenstra
Copy link
Contributor

Adds a public peel_payment_onion function that takes msgs::UpdateAddHTLC and returns PendingHTLCInfo.

I separated the internals of decode_update_add_htlc_onion, construct_recv_pending_htlc_info, and construct_fwd_pending_htlc_info into static functions, and used them to make the PendingHTLCInfo. There are two validation closures passed to peel_payment_onion... some of the outbound channel checking is done in these closures, so its up to the caller to validate against current channel state.

I am unsure about phantom_shared_secret and allow_underpay in create_recv_pending_htlc_info so i left them None/false when called from peel_payment_onion

Not sure if this is the best approach! But its much better than #2677

}
};

let validate_peer_chan = |
Copy link
Collaborator

Choose a reason for hiding this comment

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

Rather than making these lambdas and passing them into decode_incoming_update_add_htlc_onion, can we just check them after running decode_incoming_update_add_htlc_onion?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, its much cleaner now. I repeated the CLTV checks in the peel_payment_onion fn though, but I guess that's fine.

Also added a test for peel_payment_onion

@codecov-commenter
Copy link

codecov-commenter commented Nov 1, 2023

Codecov Report

Attention: 44 lines in your changes are missing coverage. Please review.

Comparison is base (1f399b0) 88.71% compared to head (192fe05) 88.72%.
Report is 63 commits behind head on main.

Files Patch % Lines
lightning/src/ln/channelmanager.rs 89.21% 37 Missing and 7 partials ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files
@@            Coverage Diff            @@
##             main    #2700     +/-   ##
=========================================
  Coverage   88.71%   88.72%             
=========================================
  Files         112      113      +1     
  Lines       88502    89533   +1031     
  Branches    88502    89533   +1031     
=========================================
+ Hits        78517    79434    +917     
- Misses       7752     7839     +87     
- Partials     2233     2260     +27     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Collaborator

@TheBlueMatt TheBlueMatt left a comment

Choose a reason for hiding this comment

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

Nice! This turned out pretty good. I think we'll basically be able to use this for LSP 4 too.

if msg.cltv_expiry > cur_height + CLTV_FAR_FAR_AWAY as u32 { // expiry_too_far
return Err("CLTV expiry is too far in the future");
}
if (outgoing_cltv_value) as u64 <= (cur_height + LATENCY_GRACE_PERIOD_BLOCKS) as u64 {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why keep the redundant one in decode_update_add_htlc_onion, can we just drop the redundant checks and leave it only doing the next-hop-channels-is-real checks.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Trying to figure out how to do this... the ChannelManager::decode_update_add_htlc_onion CLTV checks may generate a chan_update, while the checks in peel_payment_onion are simpler (since peel_payment_onion is called externally, without the context).

Are you saying we should move the checks inside the inner decode_incoming_update_add_htlc_onion fn?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok! got it figured out so there is no redundancy

}

/// Peel one layer off an incoming onion, returning PendingHTLCInfo (either Forward or Receive).
/// Validates the outgoing CLTV value against the cur_height.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Docs should describe some amount of "this does all the relevant context-free checks that LDK requires for payment relay or acceptance. If the payment is to be received, and the amount matches the expected amount for a given invoice, this indicates the UpdateAddHTLC, once fully committed in the channel, will generate an Event::PaymentReceived".

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok

@TheBlueMatt
Copy link
Collaborator

Oops, needs a small rebase after the other PR.

@TheBlueMatt TheBlueMatt self-assigned this Nov 7, 2023
Copy link
Contributor

@valentinewallace valentinewallace left a comment

Choose a reason for hiding this comment

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

Still making my way through

lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
@Evanfeenstra Evanfeenstra force-pushed the pub-htlc-routing branch 2 times, most recently from 1a37835 to 98bc9a9 Compare November 9, 2023 00:56
Copy link
Contributor

@valentinewallace valentinewallace left a comment

Choose a reason for hiding this comment

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

Almost there!

lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Show resolved Hide resolved
Copy link
Contributor

@valentinewallace valentinewallace left a comment

Choose a reason for hiding this comment

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

Needs rebase unfortunately :(

LGTM after this. Also fine with fixing these in follow-up.

lightning/src/ln/channelmanager.rs Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
/// Further routing details based on whether the HTLC is being forwarded or received.
pub routing: PendingHTLCRouting,
/// Shared secret from the previous hop.
pub incoming_shared_secret: [u8; 32],
payment_hash: PaymentHash,
Copy link
Contributor

Choose a reason for hiding this comment

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

Why leave this as the only unexposed field?

@Evanfeenstra
Copy link
Contributor Author

Needs rebase unfortunately :(

LGTM after this. Also fine with fixing these in follow-up.

OK, happy to do a follow-up on these items as soon as it gets merged

@TheBlueMatt
Copy link
Collaborator

Rather than using merge commits to rebase, please use rebase directly. See https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#rebasing-changes.

@Evanfeenstra Evanfeenstra force-pushed the pub-htlc-routing branch 2 times, most recently from 3a9fe46 to 3ddb6aa Compare November 14, 2023 19:50
@Evanfeenstra
Copy link
Contributor Author

Rather than using merge commits to rebase, please use rebase directly. See https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#rebasing-changes.

Oh, thanks for the tip. I reverted the merge commit. Also reverted the PeelOnionError stuff for a follow-up PR instead, per @valentinewallace's suggestion

@valentinewallace
Copy link
Contributor

Having done more research into CLN and LND's htlc interception APIs, I don't think we need to follow-up adding PeelOnionError.

Both APIs take either an error code or a decoded onion error packet, so our current error should be sufficient for that.

I was also thinking the LSPS4 spec may need better error info, but from talking to @TheBlueMatt it sounds like the LSP would always just error with "unknown next channel."

So excuse the misleading direction, I think this PR is fine as-is.

Copy link
Collaborator

@TheBlueMatt TheBlueMatt left a comment

Choose a reason for hiding this comment

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

LGTM, though the docs on newly-public fields and structs really need to communicate a lot more information. Generally, any public field or struct needs docs that explain (a) what it is (often in terms of how we calculated it) and (b) what its used for, often how a user would use it (if there's no reason for them to use it, it shouldn't be public).

incoming_cltv_expiry: u32, // Used to track when we should expire pending HTLCs that go unclaimed
/// Used to track when we should expire pending HTLCs that go unclaimed.
incoming_cltv_expiry: u32,
/// Optional shared secret for phantom node.
Copy link
Collaborator

Choose a reason for hiding this comment

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

This tells a user almost nothing about what this is or what its used for.

onion_packet: msgs::OnionPacket,
/// The SCID from the onion that we should forward to. This could be a real SCID or a fake one
/// generated using `get_fake_scid` from the scid_utils::fake_scid module.
short_channel_id: u64, // This should be NonZero<u64> eventually when we bump MSRV
},
/// An HTLC paid to an invoice we generated.
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit: might be worth noting that, at this point, we have not checked that the invoice being paid was actually generated by us, but rather its claiming to pay an invoice of ours.

phantom_shared_secret: Option<[u8; 32]>,
/// See [`RecipientOnionFields::custom_tlvs`] for more info.
custom_tlvs: Vec<(u64, Vec<u8>)>,
},
/// Incoming keysend (sender provided the preimage in a TLV).
Copy link
Collaborator

Choose a reason for hiding this comment

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

Only kinda specific to this PR, but the public interface is now kinda confused between keysend and spontaneous payments. We originally tried to use "spontaneous payments" for this publicly, but some keysend references slipped in, and now we're adding more. We should make everything consistent in a followup rename.

payment_metadata: Option<Vec<u8>>,
incoming_cltv_expiry: u32, // Used to track when we should expire pending HTLCs that go unclaimed
/// Used to track when we should expire pending HTLCs that go unclaimed.
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit: would be nice to also repeat what it is, not just what its used for.

pub struct PendingHTLCInfo {
/// Further routing details based on whether the HTLC is being forwarded or received.
pub routing: PendingHTLCRouting,
/// Shared secret from the previous hop.
Copy link
Collaborator

Choose a reason for hiding this comment

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

This doesn't really say much about what this is used for/why its here.

@@ -7906,6 +7713,346 @@ where
}
}

fn create_fwd_pending_htlc_info(
Copy link
Collaborator

Choose a reason for hiding this comment

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

Now that these are all freestanding functions, they (and the associated return/error structs) should probably move to some other file, if only to make channelmanager.rs slightly less huge.

@TheBlueMatt TheBlueMatt merged commit 870a0f1 into lightningdevkit:main Nov 16, 2023
13 of 15 checks passed
tnull added a commit that referenced this pull request Dec 6, 2023
Improve docs on newly-public structs after  #2700
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.

4 participants