<p>The <code>getblocktemplate</code> is designed for miners, and is constructed from the local mempool. All miners necessarily need a validating full-node to provide them with unconfirmed, valid transactions.</p>

<p>The mempool differs from one node to the other, and this may not be so relevant for merchants or individuals validating transactions, but this is highly relevant for miners, increasingly so as the transaction fee part of the block reward increases over time. </p>

<p>The sooner your node is able to accept new valid transactions, the more efficiently you can mine for blocks with the highest fees. The blocktemplate function reflects this. A well-connected node will produce block templates optimised with better fees than one that only has a subset of the transaction mempool.</p>

<p>Some may argue that transactions make up only a small part of the miner reward, and in some cases today mining empty blocks may be worth the extra hashing time that would otherwise be idling whilst the most optimal block template is constructed. This may be true today, but the system security rests on the incentive of miners to confirm a given transaction. This is the confirmation fee-market between users and miners.</p>

<p>If miner rewards solely consisted of subsidy (inflation), there would be no opportunity cost to censorship, and therefore the system security would be zero. Therefore, a system that allows data to propagate across mempools as efficiently as possible, facilitating the creation of the most rewarding block templates is highly relevant for the confirmation fee-market to function efficiently.</p>

CC BY-SA 4.0
2019-01-11T12:07:04.850Z
2019-01-11T12:07:04.850Z
James C.
<p>The mempool of all nodes is different, but this isn't an issue. There will always be some inconsistency due to latency, network conditions, and differing configurations. This doesn't measurably impact your income and won't effect the validity of blocks you produce. </p>

CC BY-SA 4.0
2019-01-11T10:54:37.433Z
thanks, Im runnung a full node, with command `getblocktemplate` I get always the same bits o target since 1 week. I have the update the mempool?
monkeyUser
CC BY-SA 4.0
2019-01-11T11:02:08.353Z
The “bits” is the difficulty of the block, which is updated every 2 weeks. This is unrelated to the men pool.
Claris
CC BY-SA 4.0
2019-01-11T11:06:42.607Z
thanks, then the mempool auto-update every 2 weeks? Txs and bits ? or Txs update every time a new block created from the network ?
monkeyUser
CC BY-SA 4.0
2019-01-11T12:14:04.157Z
No the mempool updates whenever a new valid transaction is accepted, which originated from a connected node. The difficulty adjusts every 2016 blocks, to be precise, not every 2 weeks.
James C.
CC BY-SA 4.0
2019-01-11T12:16:25.613Z
Your mempool state will definitely affect your income as a miner, see answer below.
James C.
CC BY-SA 4.0
2019-01-11T12:17:49.520Z
If the difficulty adjustment occured every two weeks, there would never be an adjustment, and hashrate globally would need to be fixed, which is an impossibility.
James C.
CC BY-SA 4.0
2019-01-11T12:18:28.543Z
It’s a close enough approximation though.
Claris
CC BY-SA 4.0
2019-01-11T12:29:32.410Z
I know what u mean, but it masks the reason why the diff adjustment exists. It exists SO that 2016 blocks occur every approx 2 weeks.
James C.
CC BY-SA 4.0
2019-01-11T13:24:09.790Z
@JamesC. the mempool updated means  evend remove transactions confirmed in the tip block and add the new tx unconfirmed?
monkeyUser
CC BY-SA 4.0
2019-01-11T13:26:53.877Z
Correct. All transactions confirmed in blocks are removed from the mempool. And new unconfirmed ones added. Mempool is a misleading term, because it doesnt have to be in memory. The only differentiation needed to be made are confirmed (in blocks of the strong chain) and unconfirmed (valid, not in blocks of the steong chain). You could call the mempool all valid unconfirmed transactions your node has seen so far.
James C.
CC BY-SA 4.0
2019-01-11T10:50:28.917Z
2019-01-11T10:50:28.917Z
Claris
<p>I don't understand if each full node has different mempool inside.</p>

<p>With RPC command <code>getblocktemplate</code> I can Get the information about candidate block. 
I can Find all transaction verified but unconfirmed 
And I can find even <code>bits</code> and <code>target</code>, the value for mining.</p>

<p>My mempool is different from another node?
I have to Update my mempool before build candidate block ?</p>

<block><full-node><mempool>
Each full node has different mempool?
monkeyUser
# Each full node has different mempool?

(Asked by: username_0 on 2019-01-11)

I don't understand if each full node has different mempool inside.

With RPC command `getblocktemplate` I can Get the information about candidate block.
I can Find all transaction verified but unconfirmed
And I can find even `bits` and `target`, the value for mining.

My mempool is different from another node?
I have to Update my mempool before build candidate block ?

**Tags:** block, full-node, mempool


---

## 2 answers

### Answer by username_1 on 2019-01-11. Score: 1 | Accepted answer

The `getblocktemplate` is designed for miners, and is constructed from the local mempool. All miners necessarily need a validating full-node to provide them with unconfirmed, valid transactions.

The mempool differs from one node to the other, and this may not be so relevant for merchants or individuals validating transactions, but this is highly relevant for miners, increasingly so as the transaction fee part of the block reward increases over time.

The sooner your node is able to accept new valid transactions, the more efficiently you can mine for blocks with the highest fees. The blocktemplate function reflects this. A well-connected node will produce block templates optimised with better fees than one that only has a subset of the transaction mempool.

Some may argue that transactions make up only a small part of the miner reward, and in some cases today mining empty blocks may be worth the extra hashing time that would otherwise be idling whilst the most optimal block template is constructed. This may be true today, but the system security rests on the incentive of miners to confirm a given transaction. This is the confirmation fee-market between users and miners.

If miner rewards solely consisted of subsidy (inflation), there would be no opportunity cost to censorship, and therefore the system security would be zero. Therefore, a system that allows data to propagate across mempools as efficiently as possible, facilitating the creation of the most rewarding block templates is highly relevant for the confirmation fee-market to function efficiently.


---

### Answer by username_2 on 2019-01-11. Score: 2

The mempool of all nodes is different, but this isn't an issue. There will always be some inconsistency due to latency, network conditions, and differing configurations. This doesn't measurably impact your income and won't effect the validity of blocks you produce.

> **Comments:**
> **username_0**: thanks, Im runnung a full node, with command `getblocktemplate` I get always the same bits o target since 1 week. I have the update the mempool?  
> **username_2**: The “bits” is the difficulty of the block, which is updated every 2 weeks. This is unrelated to the men pool.  
> **username_0**: thanks, then the mempool auto-update every 2 weeks? Txs and bits ? or Txs update every time a new block created from the network ?  
> **username_1**: No the mempool updates whenever a new valid transaction is accepted, which originated from a connected node. The difficulty adjusts every 2016 blocks, to be precise, not every 2 weeks.  
> **username_1**: Your mempool state will definitely affect your income as a miner, see answer below.  
> **username_1**: If the difficulty adjustment occured every two weeks, there would never be an adjustment, and hashrate globally would need to be fixed, which is an impossibility.  
> **username_2**: It’s a close enough approximation though.  
> **username_1**: I know what u mean, but it masks the reason why the diff adjustment exists. It exists SO that 2016 blocks occur every approx 2 weeks.  
> **username_0**: @JamesC. the mempool updated means  evend remove transactions confirmed in the tip block and add the new tx unconfirmed?  
> **username_1**: Correct. All transactions confirmed in blocks are removed from the mempool. And new unconfirmed ones added. Mempool is a misleading term, because it doesnt have to be in memory. The only differentiation needed to be made are confirmed (in blocks of the strong chain) and unconfirmed (valid, not in blocks of the steong chain). You could call the mempool all valid unconfirmed transactions your node has seen so far.  

---

