Skip to content

Conversation

@jonasschnelli
Copy link
Contributor

Tiny optimization.
CheckFinalTx() gets always called in CWalletTx::IsTrusted().
Calling it together with IsTrusted() result in calling it twice.

CheckFinalTx() get's executed under cs_main (where it calls stuff like tips GetMedianTimePast(), `GetAdjustedTime().

@maflcko
Copy link
Member

maflcko commented Nov 12, 2016

utACK 1484993f691b0913d03154e2fdd0687736c65052

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If fOnlyConfirmed is false, IsTrusted() is not executed at all. Is this OK?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. Your right, was deluded by the OR further down.
I just removed that part.

@paveljanik
Copy link
Contributor

ACK 4512550

@morcos
Copy link
Contributor

morcos commented Nov 12, 2016

When I was adding the logic for sequence locks we decided it was not worth calculating those for wallet txs, primarily because it was near impossible to have a non-final transaction in your wallet (since you would never have accepted it to your mempool). Perhaps out of scope for this PR, but I think we should consider whether we want to support any notion of finality in the wallet at all. These existing CheckFinalTx checks are cheaper but still contribute to complication. Maybe we can just remove them all?

Or if we do want to support them, then maybe there is an efficient and general way we can support finality checks for both types of locks. Such as caching the time/height that the tx will be final and in the case of sequence locks, the hash that needs to remain on the main chain for that calculation to still be valid.

@mrbandrews
Copy link
Contributor

Code review ACK 4512550

@laanwj
Copy link
Member

laanwj commented Nov 23, 2016

we decided it was not worth calculating those for wallet txs, primarily because it was near impossible to have a non-final transaction in your wallet

This is true at the moment. Although non-final handling may make sense when the GUI, some day, allows producing transactions that are not final yet. But maybe they could just be flagged some way to keep them from being considered for balance computation until they're actually on the network.
So I tend to agree.

@laanwj laanwj merged commit 4512550 into bitcoin:master Nov 23, 2016
laanwj added a commit that referenced this pull request Nov 23, 2016
4512550 Remove unnecessary calls to CheckFinalTx (Jonas Schnelli)
codablock pushed a commit to codablock/dash that referenced this pull request Jan 15, 2018
4512550 Remove unnecessary calls to CheckFinalTx (Jonas Schnelli)
andvgal pushed a commit to energicryptocurrency/gen2-energi that referenced this pull request Jan 6, 2019
4512550 Remove unnecessary calls to CheckFinalTx (Jonas Schnelli)
CryptoCentric pushed a commit to absolute-community/absolute that referenced this pull request Feb 24, 2019
4512550 Remove unnecessary calls to CheckFinalTx (Jonas Schnelli)
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants