Sure, we examine unconfirmed transactions to the complete extent of what’s attainable to do earlier than they’re included within the block, together with that the scripts are legitimate and enter scripts resolve the spending circumstances outlined within the corresponding output scripts. Something that we’ve in our mempool is legitimate to be included within the subsequent block. We even cache script validation, so after we get a brand new block, we don’t must examine the scripts once more for transactions that had been in our mempool, we simply want to make sure that the block is well-formed, no conflicting transactions are included within the block, and examine any beforehand unseen transactions in full.
As to what checks are carried out on transactions when they’re submitted to the mempool, I’ve been poking round a bit within the perform calls that observe a ProcessTransaction name. That is only a fast rundown from stepping by means of the capabilities and could also be incomplete or not fully so as.
It appears to me that through AcceptToMemoryPool and AcceptSingleTransaction first CheckTransaction does some fundamental context-free checks:
- The transaction has at the least one enter and one output
- The transaction shouldn’t be greater than the block measurement
- Every output quantity is at the least 0
- The outputs are in in sum lower than 21 M₿
- There aren’t any duplicate inputs
- That outpoints referenced in inputs are usually not undefined
- If it‘s a coinbase, the coinbase subject shouldn’t be too lengthy
After that PreChecks continues with:
- Checking that the transaction shouldn’t be a free coinbase transaction
- Rejecting outputs with extreme quantities of null knowledge, naked multisig, or mud outputs that trigger transaction to be non-standard
- Rejecting transactions shorter than 65 bytes of non-witness knowledge
- Refusing immature timelocked transactions
- Skipping transactions which are already within the mempool with the identical wtxid or txid
- Scanning for conflicting inputs and rejecting conflicts with non-replaceable transactions (in any other case teeing up a substitute try analysis)
- Checking whether or not the UTXOs spent by the inputs are in our UTXO set, putting any transaction with unknown inputs into the orphanage
- Checking whether or not any CSV-locked inputs are mature for mining
At this level, PreChecks calls CheckTxInputs:
- Checking that any coinbase outputs are mature
- Checking that enter quantities are in vary
- Checking that the enter quantities pays for the brand new outputs created
- Checking that the transaction charge is in vary
Again in PreChecks, it now checks:
- That the inputs are customary
- That the inputs have customary witnesses if relevant
- That the SigOps limits are met
- That the transaction meets the minimal feerate
- That any substitute makes an attempt don’t exceed the battle limits
- That any transactions don’t exceed ancestor or descendant limits
After the PreChecks, AcceptSingleTransaction:
- Checks that the utmost feerate shouldn’t be exceeded
- {That a} substitute would succeed
- and at last that the transaction passes coverage script checks and consensus script checks
So, in reality, any transaction that lands in our mempool is eligible to be picked into the following block.
