<p>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.</p>

<p>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.</p>

<blockquote>
  <p>how can a node resume mining after the new block is introduced?</p>
</blockquote>

<p>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.</p>

CC BY-SA 4.0
2019-05-17T01:55:57.477Z
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
CC BY-SA 4.0
2019-05-17T02:03:29.660Z
**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 `tx`s 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
CC BY-SA 4.0
2019-05-17T02:05:41.477Z
(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
CC BY-SA 4.0
2019-05-17T02:12:24.893Z
And thank you very much for the detailed answer and explanation!
cadenzah
CC BY-SA 4.0
2019-05-17T05:44:09.807Z
**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
CC BY-SA 4.0
2019-05-17T05:48:39.067Z
**Second** As I mentioned in the answer, mempool is not always consistent across nodes even if they are seeing the same view of the blockchain. Again, as I mentioned in my answer, mining nodes generate blocks. Full nodes verify that the blocks generated confine with the consensus protocol. When a block is received by a full node, it would remove transactions from its mempool that were included in the block. There is no one way of including transactions. If miners decide they can just mine the blocks without including any transactions (just the coinbase transaction)
Ugam Kamat
CC BY-SA 4.0
2019-05-17T05:50:06.130Z
@cadenzah In case of a chain re-org, when the node receives the other branch of the chain which should be the main chain, it would remove transactions from the mempool that are included in the current chain and add transactions from previous block back to the mempool if it was not included in the re-orged chain
Ugam Kamat
CC BY-SA 4.0
2019-05-17T06:56:55.270Z
So in terms of `mempool` and `UTXO set`, it is totally **un-do and adopt**restructuring procedure, not the kind of replacing. That clears my understanding. Thank you for your kind and detailed explanation!
cadenzah
CC BY-SA 4.0
2019-05-16T16:17:34.260Z
2019-05-16T16:17:34.260Z
Ugam Kamat
<h2>What I understand as (Please correct me if any statement is wrong)</h2>

<p>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 <code>UTXO set</code> and <code>mempool</code> for every full nodes.</p>

<hr>

<p>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 <code>UTXO set</code> and <code>mempool</code> <strong>I maintained</strong> is replaced subsequently?</p>

<p>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 <em>unspent</em> beforehand can turn out to be <em>spent</em> after a new block is introduced.</p>

<blockchain><proof-of-work><utxo><mempool><utxo-set>
How do blockchains in each nodes maintain consistency?
cadenzah
# How do blockchains in each nodes maintain consistency?

(Asked by: username_0 on 2019-05-16)

## 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.

**Tags:** blockchain, proof-of-work, utxo, mempool, utxo-set


---

## 1 answers

### Answer by username_1 on 2019-05-16. Score: 2 | Accepted answer

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.

> **Comments:**
> **username_0**: 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.  
> **username_0**: **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 `tx`s 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).  
> **username_0**: (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?  
> **username_0**: And thank you very much for the detailed answer and explanation!  
> **username_1**: **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  
> **username_1**: **Second** As I mentioned in the answer, mempool is not always consistent across nodes even if they are seeing the same view of the blockchain. Again, as I mentioned in my answer, mining nodes generate blocks. Full nodes verify that the blocks generated confine with the consensus protocol. When a block is received by a full node, it would remove transactions from its mempool that were included in the block. There is no one way of including transactions. If miners decide they can just mine the blocks without including any transactions (just the coinbase transaction)  
> **username_1**: @username_0 In case of a chain re-org, when the node receives the other branch of the chain which should be the main chain, it would remove transactions from the mempool that are included in the current chain and add transactions from previous block back to the mempool if it was not included in the re-orged chain  
> **username_0**: So in terms of `mempool` and `UTXO set`, it is totally **un-do and adopt**restructuring procedure, not the kind of replacing. That clears my understanding. Thank you for your kind and detailed explanation!  

---

