Difference between revisions of "Transaction Pools"
m |
|||
| 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 transaction processor (or '' | + | 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== | ||
| − | A | + | A Bitcoin [[Mining| 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 chain|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 [[TXID|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 [https://jochen-hoenicke.de/queue/#3,24h]. |
==Secondary Transaction Pools and Genesis== | ==Secondary Transaction Pools and Genesis== | ||
| − | The [[Genesis upgrade| Genesis]] upgrade to Bitcoin SV introduced a taxonomy within the transaction pool aimed at improving efficiency for transaction validators and | + | 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 meet the criteria to be included in a block (including the ''minimum transaction 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 | + | * '''Secondary Transaction Pool''' - transaction pool for transactions that 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 optimise 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 02:33, 18 November 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 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 optimise network performance.
A further discussion of configurable minimum fee policy can be found here [2].