Removing the Dust Limit [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2022-03-12T13:02:24+00:00


Summary:

Jeremy Rubin and Matt are engaged in an ongoing debate about whether to remove the dust limit in Bitcoin. Jeremy argues in favor of removing the limit, presenting five reasons to support his stance.Firstly, he believes that removing the limit would enable new types of transactions and applications to be created. This would provide users with more flexibility in creating outputs for various purposes, including smart contracts.Secondly, Jeremy suggests that dust outputs can be utilized in various authentication and delegation smart contracts. By allowing dust-sized outputs, developers can leverage them in innovative ways to enhance functionality and expand the capabilities of the Bitcoin network.Furthermore, Jeremy proposes that thinly divisible colored coin protocols could utilize satoshis as value markers for transactions. This would allow for more efficient handling of colored coins within the Bitcoin ecosystem.He also argues that treating fund transfers agnostically would simplify regulatory classification of channels. By not imposing restrictions on the value of unspent transaction outputs (UTXOs), it becomes easier to categorize transactions from a regulatory standpoint.Lastly, Jeremy acknowledges concerns about dust being spam and dust fingerprinting attacks. However, he believes that these issues are preventable with proper measures in place.On the other hand, Matt raises concerns about the externality of the UTXO set size. He suggests implementing a relay policy to address this issue but acknowledges that hardcoding prices or feerates is undesirable. One possible solution he suggests is giving transactions a size or weight bonus/penalty, although he acknowledges the challenges in implementing this correctly.There is also a proposal to make all dust transactions invalid by some nodes. The author questions whether this would require a consensus change and suggests an alternative approach of keeping dust transactions in secondary storage for full nodes and using separate Merkle Trees for bridge servers. However, the author fails to see how this would reduce processing compared to outright rejecting all dust transactions.To find a compromise, it is suggested to keep dust transactions in secondary storage for full nodes and have a separate Merkle Tree for bridge servers. This would improve performance on bridge servers and reduce the risk of exhausting a node with denial-of-service (DoS) attacks. The goal of this proposal is to decrease the amount of dust in the UTXO set, while also considering worst-case behavior for resistance against attacks.Another perspective is presented by Lord His Excellency James HRMH, who argues against restricting the value of UTXOs in one's own wallet. They suggest transferring the value of any dust UTXO to the fee. Additionally, they propose rounding transaction values and sending the additional rounded amount to the recipient. They dismiss concerns about slow validation due to the dust set of UTXOs, suggesting that the solution lies in building a faster database.ZmnSCPxj suggests storing dust UTXOs in a separate Merkle tree or structure to reduce CPU cost. However, they caution that this technique may worsen worst-case CPU cost and time if secondary storage sacrifices speed for increased capacity per satoshi.The discussion also explores the idea of lightweight nodes that ignore dust-sized outputs but still validate proof-of-work and other transactions. Concerns are raised about how such nodes would treat transactions that spend multiple dust UTXOs, as they do not store dust UTXOs and cannot determine if the UTXO being spent is dust or invalid.David Harding argues that increasing the UTXO set size through dust outputs leads to increased validation work for full nodes, resulting in higher costs for miners and centralization of mining. A relay policy is proposed to discourage economically irrational behavior. The argument against colored coin protocols on the Bitcoin chain is presented, highlighting the little benefit for tokens with a trusted issuer. The feasibility of confidential transactions without compromising privacy is discussed, suggesting the use of range proofs.Pieter Wuille comments on David Harding's presentation, agreeing with the need for a relay policy to avoid economically irrational behavior. He disagrees with colored coin protocols on the Bitcoin chain, as they compete with using Bitcoin for BTC. Pieter expresses hesitancy to worsen scalability for misguided use.The conversations also address the impact of the dust limit on the Lightning Network, including price discovery issues and the cost of writing on the UTXO set in a distributed system. Different perspectives are presented regarding the handling of dust-sized outputs in Lightning Network channels and their impact on feerates and network topology.In terms of Bitcoin's design, ZmnSCPxj proposes a softforkable solution involving a non-Confidential Transactions (CT) block and a separately-committed CT block. This design allows for unconditional privacy and computational soundness when transferring funds between the legacy non-CT block and the CT block.The email thread also explores the potential value of dust in Bitcoin transactions and the challenges associated with its handling. The existence of a dust limit incentivizes miners to mine dust outputs due to their lower maintenance costs compared to immediate fees.


Updated on: 2023-08-02T04:31:39.825006+00:00