What I understand as (Please correct me if any statement is wrong)

Every full node tries to generate a new block, in which different amount of transactions are included and what to be included will not be identical. This results in unidentical UTXO set and mempool for every full nodes.

If above statement is true, then is it okay to understand as that when the blockchain is replaced(because a new block was introduced by other node, or the blockchain branch I have became stale anymore), then the UTXO set and mempool I maintained is replaced subsequently?

If it is not the case, then how can a node resume mining after the new block is introduced? A UTXO which is known to be unspent beforehand can turn out to be spent after a new block is introduced.


Most of the full nodes are operating on normal CPUs which is now basically ineffective for mining. The mining process is handled by specific mining pools. So for full nodes that basically sees the same blockchain (there might be inconsistencies at the tip if two blocks are mined at the same time), they have the same UTXO set. This is because the UTXO set is built based on the transactions that are included in the blocks. Whenever a block is received by a full node, they delete the UTXOs which were consumed by the inputs in the transactions and add the UTXOs that were created in the output. For a mining node it is similar. If they mined the last block at the same time as the other miner, then the first miner would be building the next block using a different UTXO set than the other miner. However, after one or two blocks when the network converges (they cannot indefinitely generate blocks simultaneously) the network would have the same UTXO set.

For mempool the story is different. Bitcoin transactions are relayed on the network on a best effort basis. So it might be the case that some nodes do not see some transactions until they are finally included in the blocks. So, yes there are inconsistencies in the mempool.

how can a node resume mining after the new block is introduced?

As mentioned above, if two blocks are mined at the same time then some miners would be working on a different version versus others. The accepted principle is to build on the block that was received first. However, this is not always the case. So when a mining node who is still calculating the header hashes notice that a new block is mined, they realize that they have lost the 'race' for that particular block height and try to mine on the block that was most recently received.

  • I have two questions still not resolved: First, If two branched blockchains get merged, how do UTXO set are fixed? Is it just replaced by the mainstream blockchain's one(by the result of replacing the lost blockchain by the winning longest blockchain), or re-computed from not overlapped block to the most recent block(according to the updated new blocks ahead)? I guess the latter is not an practical way. – cadenzah May 17 at 1:55
  • Second, almost same question on mempool. As two branched blockchains have some of blocks different, the mempool they each have must not be identical before they are merged. How does this inconsistency be resolved? When a new block is generated, each node chooses txs from its mempool(decide to use transactions occured until certain point of time, and the rest will be included when another next block is generated). – cadenzah May 17 at 2:03
  • (Continuing from the previous comment) So right before the unidentical blockchains get merged, the elements of mempool could be different each other(while one tx may be included in blockchain A, the one may not be in blockchain B). In this situation, how does the node resolve the mempool difference issue? – cadenzah May 17 at 2:05
  • And thank you very much for the detailed answer and explanation! – cadenzah May 17 at 2:12
  • First UTXO set is built by the full node by it self. It is not broadcasted over the network. So when one node receives a block, it removes the input of the transactions from the UTXO set and adds the outputs. In case there is a branched chain and subsequent re-org, the node undoes the changes for transactions that are not included in the other block, but was present in the first block also adding the new transactions – Ugam Kamat May 17 at 5:44

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.