-
Notifications
You must be signed in to change notification settings - Fork 37.8k
wallet: Actually treat (un)confirmed txs as (un)confirmed #24067
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
faa60bf
to
fa73381
Compare
Why drop |
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. |
If coin selection were to include coins that are neither confirmed in the chain nor are in the mempool, then that is a separate bug to fix. |
I think the two issues should be split up. Even if we later add a general "mempool rejection reason" to the GUI, the current intended behaviour tells more information (how many blocks left / when it becomes eligible for confirmation). I would prefer fixing that rather than removing it. The second issue seems like a strict bugfix, so should get merged faster/cleaner. |
Using the right time for tx.lock_time comparisons would be an improvement, but create even more confusion than it fixes. You'd also have to check nSequence to find non-final txs.
Fixing this for the GUI will open up trivial DoS vectors for no benefit. To check for nSequence timelocks, the whole utxo set + mempool needs to be scanned for each input for each unconfirmed wallet transaction.
Overall I don't understand why a questionable feature in the GUI is used as an argument against a patch that is:
|
Good point. Concept ACK. (This seems like a bug, but probably non-trivial to fix, and it's not like the new behaviour is wrong, just less detailed) |
Interesting pull request. I was able to reproduce the issue using the below steps manually based on test added in
|
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.
tACK fa73381 This PR fixes the issue described above.
partial ACK fa73381 Partial because I ignored the GUI commit. Otherwise reviewed the code and confirmed that the tests fail on master. |
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.
Reviewed first 2 commits.
Still trying to understand the wallet part. The test fails on master but it's hard to find where it's checking with mocktime instead of MTP?
Good q. The time is set in |
ACK fa73381 |
fa73381
to
fac8165
Compare
The python test I wrote was too cringe (#24067 (comment)), so I force pushed a simpler version. I left all C++ and Qt code the same. Should be relatively easy to re-ACK. |
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.
reACK fac8165
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.
code review ACK fac8165, I understand now how this fixes both issues.
bool checkFinalTx(const CTransaction& tx) override | ||
{ | ||
LOCK(cs_main); | ||
return CheckFinalTx(chainman().ActiveChain().Tip(), tx); |
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 time is set in CheckFinalTx
Thanks. Hell, default arguments really are the worst.
Lines 207 to 209 in bd482b3
const int64_t nBlockTime = (flags & LOCKTIME_MEDIAN_TIME_PAST) | |
? active_chain_tip->GetMedianTimePast() | |
: GetAdjustedTime(); |
ACK fac8165 |
Summary: ``` Unconfirmed txs in the GUI The GUI clumsily attempts to guess if unconfirmed txs are locked until a future time. This is currently based on the locktime only, not nSequence, thus wrong. Fix this by removing the clumsy code and treat all unconfirmed txs as unconfirmed. The GUI already prints whether a tx is in the mempool, in which case the user knows that the tx wasn't locked until a future time. If the tx is not in the mempool, it might be better to report the exact reject reason from the mempool instead of using incorrect heuristics. Confirmed txs in the wallet The wallet drops coins that it incorrectly assumes to be locked until a future time, even if they are already confirmed in the chain. This is because the wallet is using the wrong time (adjusted network time) instead of MTP, due to the -1 default argument of CheckFinalTx. The issues are fixed in separate commits and there is even a test. ``` Backport of [[bitcoin/bitcoin#24067 | core#24067]]. Test Plan: ninja all check-all Reviewers: #bitcoin_abc, sdulfari Reviewed By: #bitcoin_abc, sdulfari Differential Revision: https://reviews.bitcoinabc.org/D12949
The wallet has several issues:
Unconfirmed txs in the GUI
The GUI clumsily attempts to guess if unconfirmed txs are locked until a future time. This is currently based on the locktime only, not nSequence, thus wrong. Fix this by removing the clumsy code and treat all unconfirmed txs as unconfirmed. The GUI already prints whether a tx is in the mempool, in which case the user knows that the tx wasn't locked until a future time. If the tx is not in the mempool, it might be better to report the exact reject reason from the mempool instead of using incorrect heuristics.
Confirmed txs in the wallet
The wallet drops coins that it incorrectly assumes to be locked until a future time, even if they are already confirmed in the chain. This is because the wallet is using the wrong time (adjusted network time) instead of MTP, due to the
-1
default argument ofCheckFinalTx
.The issues are fixed in separate commits and there is even a test.