doc.go raw

   1  /*
   2  Package mempool provides a policy-enforced pool of unmined bitcoin transactions.
   3  
   4  A key responsibility of the bitcoin network is mining user-generated transactions into blocks. In order to facilitate
   5  this, the mining process relies on having a readily-available source of transactions to include in a block that is being
   6  solved.
   7  
   8  At a high level, this package satisfies that requirement by providing an in-memory pool of fully validated transactions
   9  that can also optionally be further filtered based upon a configurable policy. One of the policy configuration options
  10  controls whether or not "standard" transactions are accepted. In essence, a "standard" transaction is one that satisfies
  11  a fairly strict set of requirements that are largely intended to help provide fair use of the system to all users.
  12  
  13  It is important to note that what is considered a "standard" transaction changes over time. For some insight, at the
  14  time of this writing, an example of SOME of the criteria that are required for a transaction to be considered standard
  15  are that it is of the most-recently supported version, finalized, does not exceed a specific size, and only consists of
  16  specific script forms.
  17  
  18  Since this package does not deal with other bitcoin specifics such as network communication and transaction relay, it
  19  returns a list of transactions that were accepted which gives the caller a high level of flexibility in how they want to
  20  proceed. Typically, this will involve things such as relaying the transactions to other peers on the network and
  21  notifying the mining process that new transactions are available.
  22  
  23  Feature Overview
  24  
  25  The following is a quick overview of the major features. It is not intended to be an exhaustive list.
  26  
  27   - Maintain a pool of fully validated transactions
  28     - Reject non-fully-spent duplicate transactions
  29     - Reject coinbase transactions
  30     - Reject double spends (both from the chain and other transactions in pool)
  31     - Reject invalid transactions according to the network consensus rules
  32     - Full script execution and validation with signature cache support
  33     - Individual transaction query support
  34   - Orphan transaction support (transactions that spend from unknown outputs)
  35     - Configurable limits (see transaction acceptance policy)
  36     - Automatic addition of orphan transactions that are no longer orphans as new transactions are added to the pool
  37     - Individual orphan transaction query support
  38   - Configurable transaction acceptance policy
  39     - Option to accept or reject standard transactions
  40     - Option to accept or reject transactions based on priority calculations
  41     - Rate limiting of low-fee and free transactions
  42     - Non-zero fee threshold
  43     - Max signature operations per transaction
  44     - Max orphan transaction size
  45     - Max number of orphan transactions allowed
  46   - Additional metadata tracking for each transaction
  47     - Timestamp when the transaction was added to the pool
  48     - Most recent block height when the transaction was added to the pool
  49     - The fee the transaction pays
  50     - The starting priority for the transaction
  51   - Manual control of transaction removal
  52     - Recursive removal of all dependent transactions
  53  
  54  Errors
  55  
  56  Errors returned by this package are either the raw errors provided by underlying calls or of type mempool.RuleError.
  57  Since there are two classes of rules (mempool acceptance rules and blockchain (consensus) acceptance rules), the
  58  mempool.RuleError type contains a single Err field which will, in turn, either be a mempool.TxRuleError or a
  59  blockchain.RuleError.
  60  
  61  The first indicates a violation of mempool acceptance rules while the latter indicates a violation of consensus
  62  acceptance rules. This allows the caller to easily differentiate between unexpected errors, such as database errors,
  63  versus errors due to rule violations through type assertions. In addition, callers can programmatically determine the
  64  specific rule violation by type asserting the Err field to one of the aforementioned types and examining their
  65  underlying ErrorCode field.
  66  */
  67  package mempool
  68