github.com/lbryio/lbcd@v0.22.119/fees/doc.go (about)

     1  // Copyright (c) 2018-2020 The Decred developers
     2  // Use of this source code is governed by an ISC
     3  // license that can be found in the LICENSE file.
     4  
     5  /*
     6  Package fees provides decred-specific methods for tracking and estimating fee
     7  rates for new transactions to be mined into the network. Fee rate estimation has
     8  two main goals:
     9  
    10    - Ensuring transactions are mined within a target _confirmation range_
    11      (expressed in blocks);
    12    - Attempting to minimize fees while maintaining be above restriction.
    13  
    14  # Preliminaries
    15  
    16  There are two main regimes against which fee estimation needs to be evaluated
    17  according to how full blocks being mined are (and consequently how important fee
    18  rates are): _low contention_ and _high contention_:
    19  
    20  In a low contention regime, the mempool sits mostly empty, transactions are
    21  usually mined very soon after being published and transaction fees are mostly
    22  sent using the minimum relay fee.
    23  
    24  In a high contention regime, the mempool is usually filled with unmined
    25  transactions, there is active dispute for space in a block (by transactions
    26  using higher fees) and blocks are usually full.
    27  
    28  The exact point of where these two regimes intersect is arbitrary, but it should
    29  be clear in the examples and simulations which of these is being discussed.
    30  
    31  Note: a very high contention scenario (> 90% of blocks being full and
    32  transactions remaining in the mempool indefinitely) is one in which stakeholders
    33  should be discussing alternative solutions (increase block size, provide other
    34  second layer alternatives, etc). Also, the current fill rate of blocks in decred
    35  is low, so while we try to account for this regime, I personally expect that the
    36  implementation will need more tweaks as it approaches this.
    37  
    38  The current approach to implement this estimation is based on bitcoin core's
    39  algorithm. References [1] and [2] provide a high level description of how it
    40  works there. Actual code is linked in references [3] and [4].
    41  
    42  # Outline of the Algorithm
    43  
    44  The algorithm is currently based in fee estimation as used in v0.14 of bitcoin
    45  core (which is also the basis for the v0.15+ method). A more comprehensive
    46  overview is available in reference [1].
    47  
    48  This particular version was chosen because it's simpler to implement and should
    49  be sufficient for low contention regimes. It probably overestimates fees in
    50  higher contention regimes and longer target confirmation windows, but as pointed
    51  out earlier should be sufficient for current fill rate of decred's network.
    52  
    53  The basic algorithm is as follows (as executed by a single full node):
    54  
    55  Stats building stage:
    56  
    57    - For each transaction observed entering mempool, record the block at which it
    58      was first seen
    59    - For each mined transaction which was previously observed to enter the mempool,
    60      record how long (in blocks) it took to be mined and its fee rate
    61    - Group mined transactions into fee rate _buckets_  and _confirmation ranges_,
    62      creating a table of how many transactions were mined at each confirmation
    63      range and fee rate bucket and their total committed fee
    64    - Whenever a new block is mined, decay older transactions to account for a
    65      dynamic fee environment
    66  
    67  Estimation stage:
    68  
    69    - Input a target confirmation range (how many blocks to wait for the tx to be
    70      mined)
    71    - Starting at the highest fee bucket, look for buckets where the chance of
    72      confirmation within the desired confirmation window is > 95%
    73    - Average all such buckets to get the estimated fee rate
    74  
    75  # Simulation
    76  
    77  Development of the estimator was originally performed and simulated using the
    78  code in [5]. Simulation of the current code can be performed by using the
    79  dcrfeesim tool available in [6].
    80  
    81  # Acknowledgements
    82  
    83  Thanks to @davecgh for providing the initial review of the results and the
    84  original developers of the bitcoin core code (the brunt of which seems to have
    85  been made by @morcos).
    86  
    87  ## References
    88  
    89  [1] Introduction to Bitcoin Core Estimation:
    90  https://bitcointechtalk.com/an-introduction-to-bitcoin-core-fee-estimation-27920880ad0
    91  
    92  [2] Proposed Changes to Fee Estimation in version 0.15:
    93  https://gist.github.com/morcos/d3637f015bc4e607e1fd10d8351e9f41
    94  
    95  [3] Source for fee estimation in v0.14:
    96  https://github.com/bitcoin/bitcoin/blob/v0.14.2/src/policy/fees.cpp
    97  
    98  [4] Source for fee estimation in version 0.16.2:
    99  https://github.com/bitcoin/bitcoin/blob/v0.16.2/src/policy/fees.cpp
   100  
   101  [5] Source for the original dcrfeesim and estimator work:
   102  https://github.com/matheusd/dcrfeesim_dev
   103  
   104  [6] Source for the current dcrfeesim, using this module:
   105  https://github.com/matheusd/dcrfeesim
   106  */
   107  package fees