-
Notifications
You must be signed in to change notification settings - Fork 342
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
Handle fallible per commitment point in channel establishment #3109
base: main
Are you sure you want to change the base?
Handle fallible per commitment point in channel establishment #3109
Conversation
3fbf2e6
to
1e5b210
Compare
Codecov ReportAttention: Patch coverage is
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #3109 +/- ##
==========================================
- Coverage 89.81% 89.78% -0.03%
==========================================
Files 121 119 -2
Lines 99314 97966 -1348
Branches 99314 97966 -1348
==========================================
- Hits 89195 87955 -1240
+ Misses 7514 7435 -79
+ Partials 2605 2576 -29 ☔ View full report in Codecov by Sentry. |
1e5b210
to
07991fa
Compare
the commits from #3115 are second from the end, will rebase on top later this week, but generally most of the stuff here is in place |
07991fa
to
744f2ca
Compare
73583e7
to
b798ffa
Compare
// TODO: add a variant for before our first commitment point is retrieved | ||
/// We have just created or accepted a channel and are pending our very | ||
/// first commitment point. | ||
Uninitialized { transaction_number: 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.
I thought we were going to first handle all the async cases post-funding and then add support for handling the async case during initial channel bring up in a separate PR?
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.
sorry for the delay, yea you're right, i just forgot! will be back to prioritizing this next week
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 put up #3150 - will rebase this PR on top of that when i get time
b798ffa
to
0bdd4cc
Compare
Includes simple changes to test util signers and tests, as well as handling the error case for get_per_commitment_point in HolderCommitmentPoint. This leaves a couple `.expect`s in places that will be addressed in a separate PR for handling funding.
Note: this does not test the CS -> RAA resend ordering, because this requires handling async get_per_commitment_point for channel reestablishment, which will be addressed in a follow up PR.
0bdd4cc
to
0ac4ad8
Compare
Builds on
#3086,#3096,#3115, #3149, #3150. First PR to handle fallibleget_per_commitment_point
signer method.We make
get_per_commitment_point
return a result type so that in theErr
case, we (LDK) can resume operation while an async signer fetches the commitment point. This will typically block sending out a message, but otherwise most state updates will occur. When the signature arrives, the user is expected to callChannelManager::signer_unblocked
and we will retryget_per_commitment_point
however this time the signer will return the commitment point withOk
, and we'll send out our message.This PR implements this flow for channel establishment, i.e.
open_channel
,accept_channel
, andchannel_ready
.Rough outline of how our
HolderCommitmentPoint
advances and gets new signatures:open_channel
- creates new outbound channel, immediately requests the first commit point, waits to have the first 2 commit points to be unblocked to send the messageaccept_channel
- same ^funding_created
- no op regarding commit pointsfunding_created
- uses point to verify first commitment, then advances commitment, requesting next pointfunding_signed
- no opfunding_signed
- same as above, verifies, advances, requests next pointchannel_ready
- waits to have the next commit point ready, then once unblocked sends the current point in thechannel_ready
messageTo do
channel_ready
upon the signer being unblockedchannel_ready
HolderCommitmentPoint
struct to track commitment points #3086