Sure, we verify unconfirmed transactions to the total 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 got 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 have to verify 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 verify 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 operate calls that comply with a ProcessTransaction name. That is only a fast rundown from stepping by means of the features and could also be incomplete or not utterly so as.
It appears to me that by way of AcceptToMemoryPool and AcceptSingleTransaction first CheckTransaction does some primary context-free checks:
- The transaction has not less than one enter and one output
- The transaction is just not larger than the block dimension
- Every output quantity is not less than 0
- The outputs are in in sum lower than 21 M₿
- There are not any duplicate inputs
- That outpoints referenced in inputs aren’t undefined
- If it‘s a coinbase, the coinbase subject is just not too lengthy
After that PreChecks continues with:
- Checking that the transaction is just not a unfastened 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 might be 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 alternative try analysis)
- Checking whether or not the UTXOs spent by the inputs are in our UTXO set, inserting 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 payment 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 alternative 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 is just not exceeded
- {That a} alternative would succeed
- and at last that the transaction passes coverage script checks and consensus script checks
So, the truth is, any transaction that lands in our mempool is eligible to be picked into the subsequent block.