-
Notifications
You must be signed in to change notification settings - Fork 370
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
peel_payment_onion static fn in channelmanager #2700
Conversation
lightning/src/ln/channelmanager.rs
Outdated
} | ||
}; | ||
|
||
let validate_peer_chan = | |
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.
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
?
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.
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 ReportAttention:
❗ 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. |
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.
Nice! This turned out pretty good. I think we'll basically be able to use this for LSP 4 too.
lightning/src/ln/channelmanager.rs
Outdated
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 { |
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.
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.
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.
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?
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.
ok! got it figured out so there is no redundancy
lightning/src/ln/channelmanager.rs
Outdated
} | ||
|
||
/// Peel one layer off an incoming onion, returning PendingHTLCInfo (either Forward or Receive). | ||
/// Validates the outgoing CLTV value against the cur_height. |
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.
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
".
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.
ok
Oops, needs a small rebase after the other PR. |
947590c
to
729e5a7
Compare
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.
Still making my way through
1f5a5f7
to
c173aaf
Compare
1a37835
to
98bc9a9
Compare
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.
Almost there!
d3cc8a3
to
3ddb6aa
Compare
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.
Needs rebase unfortunately :(
LGTM after this. Also fine with fixing these in follow-up.
/// 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, |
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.
Why leave this as the only unexposed field?
OK, happy to do a follow-up on these items as soon as it gets merged |
Rather than using merge commits to rebase, please use rebase directly. See https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#rebasing-changes. |
3a9fe46
to
3ddb6aa
Compare
ad173b3
to
4b5db8c
Compare
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 |
Having done more research into CLN and LND's htlc interception APIs, I don't think we need to follow-up adding 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. |
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.
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. |
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.
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. |
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.
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). |
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.
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. |
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.
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. |
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.
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( |
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.
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.
Improve docs on newly-public structs after #2700
Adds a public
peel_payment_onion
function that takesmsgs::UpdateAddHTLC
and returnsPendingHTLCInfo
.I separated the internals of
decode_update_add_htlc_onion
,construct_recv_pending_htlc_info
, andconstruct_fwd_pending_htlc_info
into static functions, and used them to make thePendingHTLCInfo
. There are two validation closures passed topeel_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
andallow_underpay
increate_recv_pending_htlc_info
so i left them None/false when called frompeel_payment_onion
Not sure if this is the best approach! But its much better than #2677