-
Notifications
You must be signed in to change notification settings - Fork 38.7k
wallet: Update transactions with current mempool after load #15652
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
Conversation
|
If it's the right fix then it needs:
|
|
Do we also need to think about how this interacts with restoring the mempool from disk? e.g. is there a race condition where some transactions being loaded would be missed? |
|
IIUC if the mempool is loaded after |
|
Ordering checks out:
As for concurrency:
Is the wallet already registered at this point (before |
|
Wallet is registered in Line 4386 in 7b13c64
which happens before CWallet::postInitProcess, so I think there's no race.
|
I also think that trying to improve that is not worth the pain/complexity. But it may cost a bit for large wallets and a large mempool. I'm happy to followup something to improve that. |
Github-Pull: bitcoin#15652 Rebased-From: 3cb4fb15bf0f97a9b40388254d8dc4c7c99868e8
I agree (it's not worth handling that explicitly), just wanted to cover all possible scenarios. |
363b383 to
a617ab3
Compare
|
Moved the fix to Also added a test. |
|
a617ab3 to
3f70633
Compare
|
@MarcoFalke fixed. |
3f70633 to
3e31d68
Compare
maflcko
left a comment
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.
Concept ACK
src/wallet/wallet.cpp
Outdated
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.
Could there be a race, since we don't take cs_main when removing txs from the mempool?
I.e. a tx is first removed due to eviction, the wallet is notified and then it is re-added here.
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.
Indeed, between getMemoryPoolTransactions and TransactionAddedToMempool a tx can be evicted.
I see 2 solutions:
- lock the wallet before the loop so that
TransactionRemovedFromMempoolcomes after this - add a way to lock the mempool in
interfaces::but not sure if this is wanted? cc @ryanofsky
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.
re: #15652 (comment)
I see 2 solutions:
I think more ideally the wallet doesn't have knowledge or control of node locks, and can just register for notifications and handle them as they come in. Maybe the ChainImpl::handleNotifications method can be changed to something like:
std::unique_ptr<Handler> handleNotifications(Notifications& notifications) override
{
LOCK2(::cs_main, ::mempool.cs);
for (const CTxMemPoolEntry& entry : ::mempool.mapTx) {
notifications.TransactionAddedToMempool(entry.GetSharedTx());
}
return MakeUnique<NotificationsHandlerImpl>(*this, notifications);
}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 you move the loop into postInitProcess, you can just take a LOCK(::mempool.cs) in there
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.
@MarcoFalke postInitProcess is wallet module, should not use that right? #15652 (comment)
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.
Yeah, you'd have to move it to the interface
Alternatively you could add it to handleNotifications as suggested by @ryanofsky, but then it would also be called for createwallet, which seems a bit wasteful
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.
@ryanofsky nice, I thought of something like replayMemoryPoolNotifications. However I'm not sure if these notifications should come after ReacceptWalletTransactions?
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.
re: #15652 (comment)
Alternatively you could add it to handleNotifications as suggested by @ryanofsky, but then it would also be called for createwallet, which seems a bit wasteful
Agree, this would be too wasteful. Having the separate method to replay notifications is probably better.
I'm not sure if these notifications should come after ReacceptWalletTransactions?
I'm not 100% sure, but I don't think I see a problem if notifications about what's already in the mempool happen before the wallet adds more transactions to the mempool. I think what you have now basically seems good though.
3e31d68 to
12fb550
Compare
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
12fb550 to
863a26d
Compare
This is just a code simplification and revert of 0440481 from bitcoin#15652. No behavior is changing.
This is just a code simplification and revert of 0440481 from bitcoin#15652. No behavior is changing.
This is just a code simplification and revert of 0440481 from bitcoin#15652. No behavior is changing.
This is just a code simplification and revert of 0440481 from bitcoin#15652. No behavior is changing.
This is just a code simplification and revert of 0440481 from bitcoin#15652. No behavior is changing.
This is just a code simplification and revert of 0440481 from bitcoin#15652. No behavior is changing.
This is just a code simplification and revert of 0440481 from bitcoin#15652. No behavior is changing.
This is just a code simplification and revert of 0440481 from bitcoin#15652. No behavior is changing.
This is just a code simplification and revert of 0440481 from bitcoin#15652. No behavior is changing.
This is just a code simplification and revert of 0440481 from bitcoin#15652. No behavior is changing.
This is just a code simplification and revert of 0440481 from bitcoin#15652. No behavior is changing.
This is just a code simplification and revert of 0440481 from bitcoin#15652. No behavior is changing.
This is just a code simplification and revert of 0440481 from bitcoin#15652. No behavior is changing.
This is just a code simplification and revert of 0440481 from bitcoin#15652. No behavior is changing.
This is just a code simplification and revert of 0440481 from bitcoin#15652. No behavior is changing.
This is just a code simplification and revert of 0440481 from bitcoin#15652. No behavior is changing.
This is just a code simplification and revert of 0440481 from bitcoin#15652. No behavior is changing.
This is just a code simplification and revert of 0440481 from bitcoin#15652. No behavior is changing.
This is just a code simplification and revert of 0440481 from bitcoin#15652. No behavior is changing.
This is just a code simplification and revert of 0440481 from bitcoin#15652. No behavior is changing.
This is just a code simplification and revert of 0440481 from bitcoin#15652. No behavior is changing.
This is just a code simplification and revert of 0440481 from bitcoin#15652. No behavior is changing.
This is just a code simplification and revert of 0440481 from bitcoin#15652. No behavior is changing.
This is just a code simplification and revert of 0440481 from bitcoin#15652. No behavior is changing.
Fixes #15591.