https://bitcointalk.org/index.php?topic=1174768.0
It seems that we might be able to optimize some transaction checkings.
Many checkings are done twice:
Most check in CheckInputs() are unnecessary when
connect block to block-chain if we already check
when accepting to memory(transaction) pool.
CheckTransaction() check the format of transaction.
While hash of transaction can guarantee transaction will not to be modified.
So, CheckTransaction() becomes unnecessary when in CheckBlock()
if we already check it when accepting to memory(transaction) pool.
Hi! Thanks for your interest in working on this! Have you benchmarked these changes? We have caching in verification which I expect would moot most performance gains here. (As the transaction enters the mempool the verification cache is primed, and the transaction is a hit when it shows up in a block).
One reason we have not previously done this is because doing so imports the mempool bugs into the consensus of the system. There have previously been bugs that, e.g. caused transactions to fail to be removed from the mempool when they should have. Not a reason to preclude doing this, but if there isn't a performance gain over the pre-existing caching approach then the reduced isolation may not be a win.
Clever! Unfortunately in the big picture the tricky part about this kind of change is we don't have a clear definition (yet) of what exactly is consensus-critical validation and what isn't. The mempool code isn't written in a way to really strongly respect that, so as @gmaxwell points out it's quite possible for the mempool to have bugs in it that allow transactions into the mempool that are invalid. In fact, I fixed one such bug last December: #5253
We are working to refactor out the consensus-critical codebase/protocol definition into a separate library which will use self-contained consensus-state objects. While it's a ways off, at that point you could cache a validation success when a transaction entered the mempool against that consensus state and use that cached result later on to be 100% sure that the transaction is valid when you see it again in a block; as @gmaxwell pointed we already part of that by caching signature validation. (see https://github.com/bitcoin/bitcoin/blob/master/src/script/sigcache.cpp for details) The state of the sigcache is quite well defined - the transaction and the signatures - so being sure the state is the same when we see the signature again in a block is a lot easier.
So yeah, unfortunately even if this change was a significant speedup, we couldn't merge it yet. :( But a good way forward if you want to continue this work would be to help review the libconsensus-related changes, and help with designing a validation state API that would allow for caching intermediate states appropriately. This won't be easy, because the UTXO state is fairly large and is changed incrementally as transactions in a block are validated from beginning to end, but maybe there's some good way to split it up?
Yes, as @gmaxwell and @petertodd explain, this is too risky at this point.