Difference between revisions of "Transaction Pools"

Line 1: Line 1:
A ''transaction pool'' or ''mempool'' is a data structure containing the set of transactions that are unconfirmed but have been validated by a miner. Transactions are stored in a node's mempool prior to inclusion in a block.
+
A ''transaction pool'' or ''mempool'' is a data structure containing the set of transactions that are unconfirmed but have been validated by a transaction processor (or ''miner''). Transactions are stored in a node's transaction pool prior to inclusion in a block.
  
 
==Transaction Pools in Bitcoin SV==
 
==Transaction Pools in Bitcoin SV==
Line 9: Line 9:
 
The [[Genesis upgrade| Genesis]] upgrade to Bitcoin SV introduced a taxonomy within the transaction pool aimed at improving efficiency for transaction validators and miners.
 
The [[Genesis upgrade| Genesis]] upgrade to Bitcoin SV introduced a taxonomy within the transaction pool aimed at improving efficiency for transaction validators and miners.
  
*  '''Primary Transaction Pool''' - transaction pool containing transactions that pay above the miner configured ''minimum tx fee''
+
*  '''Primary Transaction Pool''' - transaction pool containing transactions that meet the criteria to be included in a block (including the ''minimum transaction fee'')
  
*  '''Secondary Transaction Pool''' - transaction pool 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.
+
*  '''Secondary Transaction Pool''' - transaction pool for transactions that are do not meet the criteria to be included in a block, but may meet another transaction processors criteria (such as having below the ''minimum transaction fee'' limit but above the network-wide ''minimum relay fee'' limit). These transactions could eventually be included in another transaction processor'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/].

Revision as of 08:45, 5 May 2020

A transaction pool or mempool is a data structure containing the set of transactions that are unconfirmed but have been validated by a transaction processor (or miner). Transactions are stored in a node's transaction pool 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 their inclusion in a block. When creating a new block to mine, miners will gather transactions from their transaction pool using the rpc command getminingcandidate or the older getblocktemplate to construct a candidate block. Similarly, when receiving a block, a validator can speed-up the validation process if the transactions IDs match the transaction IDs in the validator's transaction pool. The transaction pool 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 introduced a taxonomy within the transaction pool aimed at improving efficiency for transaction validators and miners.

  • Primary Transaction Pool - transaction pool containing transactions that meet the criteria to be included in a block (including the minimum transaction fee)
  • Secondary Transaction Pool - transaction pool for transactions that are do not meet the criteria to be included in a block, but may meet another transaction processors criteria (such as having below the minimum transaction fee limit but above the network-wide minimum relay fee limit). These transactions could eventually be included in another transaction processor'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