Difference between revisions of "Dust Limit"

(Created page with "In Bitcoin’s past developers implemented a protective mechanism for Bitcoin transactions called the Dust Limit. This limit was put in place as an attempt to prevent people f...")
 
Line 3: Line 3:
 
A typical Bitcoin transaction looks something like this:
 
A typical Bitcoin transaction looks something like this:
  
 +
[[File:Bitcoin_transaction_example.png|centre|alt=Bitcoin transaction with multiple inputs and outputs]]
  
 +
In this typical Bitcoin transaction, the values paid (in satoshis) is very large in comparison to the fee. Microtransactions are possible in Bitcoin because the fee paid is so low that small outputs can be created that are still large in proportion to the fees paid. However, there does exist a lower bound to what makes sense economically when creating outputs in transactions. If an output is small enough, any fee required to spend that output could be higher than the amount of satoshis in the output:
  
In this typical Bitcoin transaction, the values paid (in satoshis) is very large in comparison to the fee. Microtransactions are possible in Bitcoin because the fee paid is so low that small outputs can be created that are still large in proportion to the fees paid. However, there does exist a lower bound to what makes sense economically when creating outputs in transactions. If an output is small enough, any fee required to spend that output could be higher than the amount of satoshis in the output:
+
[[File:Dust_limit_example.png|centre|alt=Dust Limit Transaction Not Allowed]]
  
 
In the above example, the dust limit, set by the node to be higher than 10 satoshis, prevents 10 satoshi outputs from being created to prevent a situation where an output is unspendable due to fee requirements. The dust limit is entirely set by miner policy, meaning it is not a consensus limitation, but instead is configurable by miners.   
 
In the above example, the dust limit, set by the node to be higher than 10 satoshis, prevents 10 satoshi outputs from being created to prevent a situation where an output is unspendable due to fee requirements. The dust limit is entirely set by miner policy, meaning it is not a consensus limitation, but instead is configurable by miners.   
Line 12: Line 14:
  
 
Beginning in Bitcoin SV Node software v1.0.5, the software automatically allows for the creation of “consolidation transactions” where dust outputs can be consolidated for free into larger usable inputs. Outputs below the dust limit are accepted if the node parameter acceptnonstdconsolidationinput is set to 1.  
 
Beginning in Bitcoin SV Node software v1.0.5, the software automatically allows for the creation of “consolidation transactions” where dust outputs can be consolidated for free into larger usable inputs. Outputs below the dust limit are accepted if the node parameter acceptnonstdconsolidationinput is set to 1.  
 +
 +
[[File:Consolidation_transaction_example.png|centre|alt=Consolidation Transaction Example]]
  
 
Because miners have to store the entire UTXO set, it is in their interest to reduce the size of the UTXO set whenever possible. It is for this reason that allowing these transactions without a fee is in both the customer and miners' interests.  
 
Because miners have to store the entire UTXO set, it is in their interest to reduce the size of the UTXO set whenever possible. It is for this reason that allowing these transactions without a fee is in both the customer and miners' interests.  

Revision as of 19:33, 20 July 2021

In Bitcoin’s past developers implemented a protective mechanism for Bitcoin transactions called the Dust Limit. This limit was put in place as an attempt to prevent people from creating outputs that could become unspendable. In short, the Dust Limit is a threshold of satoshis that cannot be spent in an output.

A typical Bitcoin transaction looks something like this:

Bitcoin transaction with multiple inputs and outputs

In this typical Bitcoin transaction, the values paid (in satoshis) is very large in comparison to the fee. Microtransactions are possible in Bitcoin because the fee paid is so low that small outputs can be created that are still large in proportion to the fees paid. However, there does exist a lower bound to what makes sense economically when creating outputs in transactions. If an output is small enough, any fee required to spend that output could be higher than the amount of satoshis in the output:

In the above example, the dust limit, set by the node to be higher than 10 satoshis, prevents 10 satoshi outputs from being created to prevent a situation where an output is unspendable due to fee requirements. The dust limit is entirely set by miner policy, meaning it is not a consensus limitation, but instead is configurable by miners.

Consolidation Transactions

Beginning in Bitcoin SV Node software v1.0.5, the software automatically allows for the creation of “consolidation transactions” where dust outputs can be consolidated for free into larger usable inputs. Outputs below the dust limit are accepted if the node parameter acceptnonstdconsolidationinput is set to 1.

Consolidation Transaction Example

Because miners have to store the entire UTXO set, it is in their interest to reduce the size of the UTXO set whenever possible. It is for this reason that allowing these transactions without a fee is in both the customer and miners' interests.

In the above example we see a normal transaction with additional 10 satoshi outputs attached. The recipient of these outputs simply collects enough of them to meet the criteria for a free consolidation transaction then converts the collective value of 1000 inputs into a single, higher-value output. The size of the UTXO database is reduced by 999 entries.

In order for a transaction to be classified as consolidation by the Bitcoin SV software, some strict conditions must be met. A consolidation transaction is a transaction that reduces the number of UTXO’s by a margin that is more valuable for the network than the implied fee. Hence we allow consolidation transactions free from any fees.

The conditions for a consolidation transaction are as follows:

  • The scriptPubKey sizes from the transaction outputs spent are compared to the scriptPubKey sizes of the consolidation transaction. The sum of the former must be greater than the sum of the latter multiplied by the consolidation factor (configuration parameter: minconsolidationfactor)
  • The transaction input count must be greater than the transaction outputs count multiplied by minconsolidationfactor
  • All inputs must have a confirmation count of at least minconsolidationinputmaturity.
  • scriptSig sizes of the consolidation transaction have an upper limit of maxconsolidationinputscriptsize bytes long to prevent gaming.
  • Inputs spent in consolidation transactions must meet the old test of isStandard() if acceptnonstdconsolidationinput equals 0
  • The default value for maxconsolidationinputscriptsize is 150 bytes.
  • The default value for minconsolidationfactor is 20
  • The default value for minconsolidationinputmaturity is 6 (equivalent to one hour)
  • The default value for acceptnonstdconsolidationinput is 0 meaning only standard inputs allowed
  • Setting minconsolidationfactor to 0 disables the free consolidation transactions feature

The condition as the formula is:


      c = minconsolidationfactor
      m = minconsolidationinputmaturity
      s = maxconsolidationinputscriptsize
      a = acceptnonstdconsolidationinput
      isFree =  nInputs >= c * nOutputs
             && confirmationCount(input) >= m for all inputs 
             && sum(inputTxScriptPubKeyBytesLen[]) >= c * sum(outputTxScripPubKeytBytesLen[])
             && inputTxScriptSig <= s for all inputTxScriptSig
             && isStandardInput(input) for all inputs unless a == 1


As a general rule of thumb:

  • Consolidate at least 100 inputs to one output.
  • Only use standard p2pkh inputs or bare multisig with no more than 2 signatures.
  • Only use inputs confirmed for at least 6 blocks.
    • This rule can be gotten around simply by constructing the transaction using all available inputs but not broadcasting it until 6 blocks after you made it.