Dust Expiry: Clean the UTXO set from spam

The discussion revolves around the complexities and challenges associated with implementing a UTXO (Unspent Transaction Output) commitment scheme within blockchain technologies, emphasizing the trade-offs between reducing storage requirements and the increased computational work needed to maintain such commitments. The conversation highlights that while reducing the size of the UTXO set appears beneficial, the resultant increase in computational work due to logarithmic factors negates these benefits. This complexity arises because the effort required to update the UTXO set grows significantly, making the overall system less efficient.

A proposed solution involves focusing on outputs that are unlikely to be spent or even unspendable, suggesting that incorporating the cost of spending these outputs directly into their transaction size could address the issues of resource inflation for nodes without compromising the system's integrity. This approach implicitly respects the principle against confiscation, acknowledging the importance of not undermining users' trust or the utility of the blockchain with policies that might allow for the confiscation of funds.

The concept of setting a threshold value for pruning outputs is introduced, with the idea that real wallets typically hold amounts above this threshold, thereby minimizing the impact on most users. This strategy aims to cater to outputs that are highly unlikely to be spent unless there's a significant increase in Bitcoin's value. By applying restrictions based on output age or transaction heights, the system retains flexibility, allowing for future adjustments through soft forks. However, the potential future value of even the smallest denominations is noted, emphasizing the challenge of deciding which outputs might be safely pruned without risking user assets.

Further considerations include the technical aspects of implementing such a system, like the treatment of proof data as "super-prunable" to reduce synchronization bandwidth. This acknowledges that if the entire blockchain history is available, proof data, redundant in this context, could be omitted during synchronization processes. This approach would require careful design to ensure no loss of critical information, suggesting that any serialized data related to this scheme should be constructed to eliminate unnecessary redundancy, thereby optimizing network resources.

Overall, the dialogue underscores the delicate balance between optimizing blockchain efficiency and ensuring the security and accessibility of user assets, pointing towards innovative yet cautious approaches to scaling blockchain technologies.