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
contractcourt: stop lnd when received witness is empty #7811
Conversation
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 with a couple nits.
|
||
// witnessSpendLocal is the remote's witness used to spend the HTLC via | ||
// the second stage success tx path on the remote commitment. | ||
witnessSpendLocal := wire.TxWitness{ |
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.
Shouldn't we call this witnessSpendRemote
?
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.
named it to witnessSpendSuccess
instead. So what I want to differentiate here is not local vs remote but how the preimage is revealed - either via the second stage success tx, or a direct spend. And in the test case setup we then start paying attention to whether it's a local view or a remote view.
|
||
// witnessSpendDirect is the remote's witness used to spend the HTLC | ||
// via the preimage path on the local commitment. | ||
witnessSpendDirect := wire.TxWitness{ |
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.
How about witnessSpendLocal
?
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.
The direct spend can happen for both local and remote tho.
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.
You are right in general the Preimage Spent can happen by us on the remote, but refering to the naming of the file htlc_timeout_resolver
their are only two possibilities for the preimage spent. Either on the remote via the witnessSpendSuccess
or on our local via the witnessSpendLocal
?
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.
Updated the tests to more clearly express the testing objects.
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.
looks great now!
// on the local commitment transaction for an outgoing HTLC that is | ||
// swept on-chain by us with pre-image. |
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.
If it is the local commitment tx, and we are sweeping the pre-image path, then it must be an incoming HTLC. An outgoing htlc on our commitment tx can only be swept by us via the timeout path.
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.
updated.
I don't think this should be done, we should instead figure out why bitcoind isn't serving witness data and, if we're able to, refuse to startup. Also this skips potentially notifying on a preimage spend if the bitcoind were to later right itself via user running |
This PR seems valuable to me on its own -- why shouldn't we do a bounds check before accessing the array element? We already do the bounds check for the remote commitment. Whether this PR fixes the root cause is orthogonal. |
I think the PR is fine after we've fixed the issue. I'd prefer that before it's actually fixed, we fail loudly on missing witness data. Otherwise continuing rather than panic means a
I don't agree because if we fix this immediately, we may never fix the root cause as it'll fail silently |
Yeah we should fix it, tho I don't think it can be fixed inside |
isPreimageSpend
won't panic91cb102
to
90010c9
Compare
@Crypt-iQ: review reminder |
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.
Great work yy 🤝, had some minor nits. Gracefully shutting down LND when no witness data is present makes a lot of sense. Especially because we cannot guarantee the user setting -rpcserialversion
.
|
||
// witnessSpendDirect is the remote's witness used to spend the HTLC | ||
// via the preimage path on the local commitment. | ||
witnessSpendDirect := wire.TxWitness{ |
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.
You are right in general the Preimage Spent can happen by us on the remote, but refering to the naming of the file htlc_timeout_resolver
their are only two possibilities for the preimage spent. Either on the remote via the witnessSpendSuccess
or on our local via the witnessSpendLocal
?
a71591c
to
e94af84
Compare
e94af84
to
b9bc021
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.
Base-Branch can be changed to master.
LGTM 🚀
This commit adds a length check in `isPreimageSpend` to make sure it won't ever panic and adds a unit test to verify it.
This commit adds a check when receiving transactions from `BitcoindClient` so an error is returned when empty witness is found.
This commit uses `Criticalf` to gracefully stop `lnd` when the received witness data is empty.
b9bc021
to
28497e9
Compare
This is the first commit from #7615. Making a PR for it so affected users can apply the patch first.
This commit adds a length check in
isPreimageSpend
to make sure it won't ever panic and adds a unit test to verify it.