I am missing something so far in reading this (excellent resource). I read the part about transactions for the most part, but I don't understand the actual code evaluation part, and how long it takes. So if you have a low-priority transaction (because of a low-fee), it could take "a long time" to run, or potentially never. If you have a high-priority transaction (high fee), then it will get run "quicker" or "with higher probability". My question is what actually is happening between the moment of a transaction being "created" and it being "added to a block". I wonder if your code is actually run before the transaction is actually added to the block and validated, or it's never run until fully validated. I wonder because this seems like a huge performance slow-down in resource-intensive applications, and I wonder what people do there.

Here it says:

A new block, containing transactions that occurred since the last block, is "mined" every 10 minutes on average, thereby adding those transactions to the blockchain.

So my question then basically is, if your code doesn't evaluate until that 10 minutes passes, or when the code actually evaluates. Basically what happens between a transaction being created and when it is incorporated into a block.


When a transaction is published to the network, every node that hears about that transaction will check to see if it is a valid transaction according to the network's rules. If it is not valid, it will be discarded, but if it is valid it will be added to that node's mempool. Nodes will relay valid transactions to their peers in the network, but there is also no requirement for a transaction to be known to all nodes before it is included in a block. A miner can put their own valid, but otherwise not published transactions into a new block they have mined.

Similarly, when a node hears about a new block, it will check to see if the block is valid according to the network's rules. If it is, then the node will update it's blockchain record to reflect any state changes incurred by transactions in that block.

With each subsequent block that builds off the block of interest, there is a higher degree of certainty that the transactions included in the block of interest will be permanently included in the blockchain record.

| improve this answer | |
  • Wondering where I can find more information on this, I'm not seeing it here in the transaction section. – Lance Pollard Feb 17 '19 at 9:20
  • What other information are you looking for? @MCCCS added a good answer as well. But the crux of it is that when a new block is found, nodes will update their blockchain record (and thus UTXO set) to include the changes made by transactions that were included in that block. – chytrik Feb 17 '19 at 9:32
  • I guess I'm looking for "transaction validation process". – Lance Pollard Feb 17 '19 at 9:33
  • 1
    I'm not sure what other info to point you towards exactly... but the answer on this Q has some info about what constitutes a valid tx: bitcoin.stackexchange.com/questions/77912/… . There is a little more info about how transactions are serialized here: bitcoin.org/en/developer-reference#raw-transaction-format . The ultimate reference for expected behaviour of the network is the source code itself: github.com/bitcoin/bitcoin/tree/master/src – chytrik Feb 17 '19 at 9:56

Validation of a transaction is a sub-millisecond operation. The most critical part of a transaction's journey is when it'll be included in a block. There's a 1 MB (plus 3 MB witness) transaction limit in a block. The mempool is usually larger than the block size limit, and therefore the block space is a scarce resource. Thus, miners only choose the transactions with the highest fee/kb ratio. If there aren't many high-fee transactions, then transactions with less fee/kb will also be collected. Miners are free to choose their transactions to maximize their profit, but the choice of transactions is not related to the time it takes to validate a transaction.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.