-
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
sweep: start tracking input spending status in the fee bumper #9447
base: master
Are you sure you want to change the base?
Conversation
Important Review skippedAuto reviews are limited to specific labels. 🏷️ Labels to auto review (1)
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 using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
e8cb0c7
to
a738e7f
Compare
48d4631
to
bd0f218
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.
First pass, one thing that wasn't immediately obvious to me is: where do we fix the issue that the the state of the fee function is properly carried over into the new batch (instead of reset) when one of the inputs in a cohort is spent?
itest/lnd_sweep_test.go
Outdated
// Carol should have numPayments incoming HTLCs on channel Bob -> Carol. | ||
ht.AssertNumActiveHtlcs(carol, numPayments) | ||
|
||
// Suspen Bob so he won't get the preimage from Carol. |
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.
Suspen -> Suspend
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.
fixed!
continue | ||
} | ||
|
||
log.Warnf("Detected third party spent of output=%v "+ | ||
"in tx=%v", op, spend.SpendingTx.TxHash()) | ||
spendingTx := spend.SpendingTx |
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 wonder if we should actually block here, even if just for a moment, to allow the scheduler to run the goroutine that does the dispatch.
Spent a bit of time to re-familiarize myself with the notifier after the latest set of refactors, and I don't see an area where we'll insta dispatch the response before exiting the initial method call.
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 mean we perform a tiny sleep (sth likecase <- time.After(100ms)
) instead?
We did refactor this area a bit here 1200b75, which makes sure the block is always sent before the tx, but we cannot guarantee the order is maintained since pipeline is a bit deep we cannot be sure they are read in this order.
A previous attempt was to implement a method HasOutpointSpent
on Blockbeat
- the idea is that, whenever we are notified of a block, we can easily access the block data to see if the watched outputs are spent or not, hence eliminating the race, which guarantees we won't miss a spending event. However there was some difficult involved when implementing it in neutrino
, as discussed here. Now that you mention it I think it's still worthy to keep it as a TODO, since we can just register spend when it's neutrino to avoid fetching full blocks, and read the block data when it's a full node.
a738e7f
to
b98542b
Compare
0ca8914
to
18df4fb
Compare
To track the input and its spending tx, which will be used later to detect unknown spends.
This commit refactors the `processRecords` to always handle the inputs spent when processing the records. We now make sure to handle unknown spends for all backends (previously only neutrino), and rely solely on the spending notification to give us the onchain status of inputs.
We now rename "third party" to "unknown" as the inputs can be spent via an older sweeping tx, a third party (anchor), or a remote party (pin). In fee bumper we don't have the info to distinguish the above cases, and leave them to be further handled by the sweeper as it has more context.
18df4fb
to
af48039
Compare
There are two places tracking the spending status of a given input - one in the sweeper, the other in the fee bumper. We now move the tracking to be handled in the fee bumper so we always have a single source of truth. By the end of this fix, we should see that,
The fix is made of two PRs to keep the size small - the first PR will enable tracking the spending status of inputs in the fee bumper, and the second will fix the rest.
Depends on,
Failed
toFatal
and minor refactor #9446