-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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: Taproot Channel Bugfixes #8879
contractcourt: Taproot Channel Bugfixes #8879
Conversation
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configuration File (
|
5ff3516
to
ba465c8
Compare
@ProofOfKeags, remember to re-request review from reviewers when ready |
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.
Thanks for the fix! Looking good, just a few questions.
isLocalCommitTx = signDesc.WitnessScript[scriptLen-1] == | ||
txscript.OP_DROP | ||
delayKey := *c.localChanCfg.DelayBasePoint.PubKey | ||
nonDelayKey := *c.localChanCfg.PaymentBasePoint.PubKey |
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 like nonDelayKey
provides little utility but sanity checking an impossible 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.
If we allow ourselves to assume that the signing key MUST be one of these two keys, then all we need is for one of them to be there as we can infer that if it isn't one, then it is the other. I chose this approach for thoroughness but we can trim it down if you'd rather this either/or assumption to be documented in the comments rather than explicitly checked in the control logic.
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 🧲
As mentioned elsewhere, things end up working as is since the witness scripts are identical. We also have some added confidence with the various sweeping scenarios in the itest.
One potential follow up here would be to extract the routine that determines isLocalCommitTx
into a new function. Then we can write a unit test that directly calls NewUnilateralCloseSummary
with a realistic set of arguments to further bind the assumption we're making here re SelfOutputSignDesc.KeyDesc.PubKey
(that it's always set, and non-nil, etc).
This commit fixes an issue where we did not properly detect and therefore record the coop close transaction if it used the newer RBF coop close v2 scheme. This only affects coop closes of taproot channels today.
ba465c8
to
fc3aa5d
Compare
This commit fixes the heuristic we use for identifying the party that broadcast a Simple Taproot Channel commitment transaction. Prior to this change we checked if the last script element was an OP_DROP. However, both the local and remote commitment outputs have an OP_DROP at the end. The new approach checks the resolver's SignDescriptor and compares that key to the keys in the channel's local ChannelConfig. If the key is the delay key, we know that it is our commitment transaction.
fc3aa5d
to
09f5e08
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.
LGTM🦾
Found this new flake,
--- FAIL: TestChanStatusManagerStateMachine (0.00s)
--- FAIL: TestChanStatusManagerStateMachine/add_new_channels (4.05s)
chan_status_manager_test.go:765: received update for unexpected short chan id: 0:0:144
FAIL
Don't think it's related to this PR tho.
Change Description
This PR fixes two bugs with Taproot Channel closures. These bugs never had corresponding issue documentation so they will be described here:
SOLUTION: include the max RBF sequence number in the heuristic for identifying coop close transactions.
SOLUTION: check the signing key of the resolver and compare it to the channel config to see if we are using the delay key or the non-delay key.
Steps to Test
I'm unsure what our testing strategy should be here. Open to suggestions.
Pull Request Checklist
Testing
Code Style and Documentation
[skip ci]
in the commit message for small changes.📝 Please see our Contribution Guidelines for further guidance.