contractcourt: detect local force closes based on commitment outputs #2855
Conversation
This file contains 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
Roasbeef
force-pushed
the
output-based-force-close-detection
branch
from
b66d84e
to
203a394
Compare
cfromknecht
reviewed
Apr 2, 2019
There was a problem hiding this comment.
ACK for more generic commitment identification, changes themselves lgtm. Needs rebase tho now that #2313 is in
halseth
reviewed
Apr 8, 2019
|
needs rebase |
Roasbeef
force-pushed
the
output-based-force-close-detection
branch
from
203a394
to
46d7f93
Compare
|
Rebased with comments addressed. Planning on making a follow up PR to the DLP chain watcher tests to improve the execution time of the tests as I did these ones. |
Roasbeef
added
commitments
|
PTAL @cfromknecht @halseth |
cfromknecht
reviewed
Apr 23, 2019
Roasbeef
force-pushed
the
output-based-force-close-detection
branch
from
46d7f93
to
32569ef
Compare
halseth
suggested changes
Apr 25, 2019
Roasbeef
force-pushed
the
output-based-force-close-detection
branch
from
32569ef
to
4f5e23f
Compare
|
PTAL @halseth |
In this commit, we modify the way we detect local force closes. Before this commit, we would directly check the broadcast commitment's txid against what we know to be our best local commitment. In the case of DLP recovery from an SCB, it's possible that the user force closed, _then_ attempted to recover their channels. As a result, we need to check the outputs directly in order to also handle this rare, but possible recovery scenario. The new detection method uses the outputs to detect if it's a local commitment or not. Based on the state number, we'll re-derive the expected scripts, and check to see if they're on the commitment. If not, then we know it's a remote force close. A new test has been added to exercise this new behavior, ensuring we catch local closes where we have and don't have a direct output.
Roasbeef
force-pushed
the
output-based-force-close-detection
branch
from
4f5e23f
to
bdf1194
Compare
|
Rebased after the other related PR landed before this one. |
|
PTAL @halseth |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
In this commit, we modify the way we detect local force closes. Before
this commit, we would directly check the broadcast commitment's txid
against what we know to be our best local commitment. In the case of DLP
recovery from an SCB, it's possible that the user force closed, then
attempted to recover their channels. As a result, we need to check the
outputs directly in order to also handle this rare, but
possible recovery scenario.
The new detection method uses the outputs to detect if it's a local
commitment or not. Based on the state number, we'll re-derive the
expected scripts, and check to see if they're on the commitment. If not,
then we know it's a remote force close. A new test has been added to
exercise this new behavior, ensuring we catch local closes where we have
and don't have a direct output.