Difference between revisions of "Transaction Pools"

Line 1: Line 1:
 
A ''transaction pool'' or ''mempool'' is a data structure used to store unconfirmed transactions prior to inclusion in a block.
 
A ''transaction pool'' or ''mempool'' is a data structure used to store unconfirmed transactions prior to inclusion in a block.
  
==Transaction Pools in Bitcoin==
+
==Transaction Pools in Bitcoin SV==
 
 
A bitcoin [[Node| node]] stores bitcoin transactions that have been validated but not mined  ... Mempool data are used extensively by block explorers, wallet servers and other Bitcoin related web services [https://jochen-hoenicke.de/queue/#3,24h].
 
  
 +
A bitcoin [[Node| node]] stores bitcoin transactions that have been validated but not mined. It can be thought of as a staging area for transactions prior to them being included in a block. When creating a new block to mine miners will gather transactions from their mempool using the rpc command ''getblocktemplate'' to construct a candidate block. Similarly, when recieving a block a validator can speed-up the validation process if the [[TXID|transactions IDs]] match the transaction IDs in the validator's mempool. Mempool transaction data is used extensively by block explorers, wallet servers and other Bitcoin SV related web services [https://jochen-hoenicke.de/queue/#3,24h].
  
 
==Secondary Transaction Pools and Genesis==
 
==Secondary Transaction Pools and Genesis==
Line 11: Line 10:
  
 
* '''Primary Mempool''' - Mempool containing transactions that pay above the miner configured ''minimum tx fee''
 
* '''Primary Mempool''' - Mempool containing transactions that pay above the miner configured ''minimum tx fee''
* '''Secondary Mempool''' - Mempool for transactions that are below the miner configured ''minimum tx fee'' limit but above the network-wide ''minimum relay fee'' limit. These transactions are likely to eventually be included in another miner's block and therefore should be stored to ensure fast [[Mining| block validation]].   
+
* '''Secondary Mempool''' - Mempool for transactions that are below the miner configured ''minimum tx fee'' limit but above the network-wide ''minimum relay fee'' limit. These transactions are likely to eventually be included in another miner's block and therefore should be stored to ensure fast [[Mining| block validation]] and optimize network performance.   
  
 
A further discussion of configurable minimum fee policy can be found here [https://bitcoinsv.io/2019/11/24/on-the-future-of-bitcoin-transaction-fees/].  
 
A further discussion of configurable minimum fee policy can be found here [https://bitcoinsv.io/2019/11/24/on-the-future-of-bitcoin-transaction-fees/].  
 
 
   
 
   
 
==See Also==
 
==See Also==

Revision as of 17:18, 7 January 2020

A transaction pool or mempool is a data structure used to store unconfirmed transactions prior to inclusion in a block.

Transaction Pools in Bitcoin SV

A bitcoin node stores bitcoin transactions that have been validated but not mined. It can be thought of as a staging area for transactions prior to them being included in a block. When creating a new block to mine miners will gather transactions from their mempool using the rpc command getblocktemplate to construct a candidate block. Similarly, when recieving a block a validator can speed-up the validation process if the transactions IDs match the transaction IDs in the validator's mempool. Mempool transaction data is used extensively by block explorers, wallet servers and other Bitcoin SV related web services [1].

Secondary Transaction Pools and Genesis

The Genesis upgrade to Bitcoin SV will introduce taxonomy within the mempool aimed at improving efficiency for transaction validators and miners.

  • Primary Mempool - Mempool containing transactions that pay above the miner configured minimum tx fee
  • Secondary Mempool - Mempool for transactions that are below the miner configured minimum tx fee limit but above the network-wide minimum relay fee limit. These transactions are likely to eventually be included in another miner's block and therefore should be stored to ensure fast block validation and optimize network performance.

A further discussion of configurable minimum fee policy can be found here [2].

See Also

References