-
Notifications
You must be signed in to change notification settings - Fork 404
BaseSign + ChannelMonitor temporary error support #1538
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
Closed
devrandom
wants to merge
3
commits into
lightningdevkit:main
from
lightning-signer:2022-06-sign-error
Closed
Changes from all commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 to confirm if we agree all on the direction, in case of
SignError::Temporary
yielded byfinalize_claim_tx
, we return aPendingEvent::SignTransaction
toChannelMonitor
queued on a new internal buffer ?How we would dry-up the queue ? Inside
block_confirmed
or with a newmonitor_timer_tick_occured()
, I lean to favor the latter as blocks elapsing is a bit precious in Lightning.If we get an
SignError::Internal
maybe we should flow it back up toChannelManager
with aChannelMonitor::TemporaryFailure
and stop accepting HTLCs we won't be able to claim anyways ?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.
Initially, I thought we would just call
ChannelMonitor.update_claims_view
with empty inputs and the current logic would have it retry the requests inself.pending_claim_requests
. It seemed like the least invasive approach.However, it seems that @TheBlueMatt prefers if we just retry the signing/broadcasting part, and not the rest of the logic. Maybe he can clarify how his envisions the triggering of the retry.
As to implementation details - there are already three buffers in
ChannelMonitorImpl
:I'm wondering if any of these could be used for this purpose.
The signer may connect at any time, which may not overlap with the block arrival time. So it's probably best that the
BackgroundProcessor
tick gets triggered by the signer connecting so we can catch up on all housekeeping tasks.ChannelMonitor
already implementsEventsProvider::process_pending_events
, so perhaps it makes sense to add the code there. Or it may be cleaner to add another call as you say.The
Internal
error is just a renaming of the existingResult<_, ()>
error returns fromBaseSign
. It seems like we currently almost always panic, or we should, because it's caused by a key derivation failing, which has an infinitesimal chance of happening and probably indicates a hardware / RNG problem. In any case, it's out of scope of the current effort to change the handling of this case.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'd imagine we'd leave that up to the user or maybe even do it on every block (though that will basically break ~every test, so maybe we don't do that by default in tests?). If the signer is connected intermittently, hopefully the user has some mechanism to learn when the signer is available so they can re-sign.
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.
IIUC the idea as just retrying the signing/broadcasting part I'm good with that, it's more likely the
update_claims_view
logic is going to be more complex in the future (e.g locking fee-bumping UTXOs) though to break it to avoid dependency bug like the one above.I think the last one
onchain_events_awaiting_threshold_conf
would fit, all the events are destinied to be consumed byChannelMonitorImpl
. Maybe can be recall something like "monitor_events_awaiting_time_point` where time point is either a blockchain height or the signer waking up.Yeah
ChannelMonitorImpl::get_and_clear_pending_events
sounds a good temporary location for now.Sure, we can deferred how we react to catastrophic hardware failures to the future.