Dear Sir,
I'm not discussing the dust limit here, but I'm suggesting some mitigations to the dust problem which tackles almost the same points mentioned here especially the scalability of the UTXOS set and the corresponding Merkle proofs/witnesses in Utreexo or any similar design .... . I suggest: 1-Dust UTXOS, along with burned & non-standard UTXOS, to be stored separately in secondary storage; their Hashes in a separate Merkle too in any accumulator design (an earlier draft of the idea https://bitcointalk.org/index.php?topic=5343748.new#new) . -In fact, the idea of separating the real UTXO values was first suggested in https://royalsocietypublishing.org/doi/10.1098/rsos.180817 In their words "Similarly, one can think of a two-tier data structure where a UTXO subset containing UTXOs with a low probability of being selected such as dust is kept on disk, while the other UTXOs are kept in memory." . 2-I suggest also that existing dust UTXOS (from the same paper, in some cases a UTXO could be added as an extra input with the cost of 68*fee/byte) , to be selected with large UTXO whenever they fit in a spending ( use one large & one small to get rid of the small) . 3-In general when user is not willing to leave the dust to the fee, and if there's no dust UTXOS, do not let the coin selection algorithm select the closest match; let it choose the smallest that doesn't create dust. For example if there's UTXOS 0.00013 & 0.00012 and user want to spend 0.0001198 choose 0.00013 so that the change is not dust (with same cost). . Thank you for your time, This is the first time I send a suggestion to your emailing list, so sorry if I missed any regulations . Shymaa M. Arafat
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
