Does any wallet software use the heuristic of adding a dust UTXO in each TX?

[Shymaa-Arafat]

Dust isn't that common actually.

In Jan 2020 dust was estimated to be 10-15% of I think 64m UTXO set, previous studies in 2018/2019 where the UTXOS set was 60m talk also about Similar ratio; ie about 6-10m UTXOS.

I guess maybe newer strategies of adding dust to fee almost prevented the accumulation of new dust UTXOS.
.
Maybe now the problem remains with:
1-Those previously accumulated millions not being completely sweeped yet.
2-Those recently mentioned "Dust Attacks" when someone deliberately generates & sends dust values to hack wallets.
.
So, maybe really a new coin selection strategy won't solve much; except the idea of taking the next closest match instead of the closest, .00013 instead of 0.00012 in my example, this way u'll keep ur money no matter how little instead of adding it to the fee.

»»»
Maybe I should add the suggestion of storing dust UTXOS separately, I think it would be an improvement for each full node if it can save 300-500 MB from the ~4 MB it has to save and just keep them on secondary storage (the same to their hashes); also Bloom filters and whatever UTXOS snapshots protocols out there could exclude those least expected to be verified from their sampling process
-Sorry, this is just a side note, I know it is not so much relevant to wallet software

[goatpig]

There has been proposals to identify provably unspendable outputs (say bit message kind of stuff) and prune them out of the UTXO set.

[Shymaa-Arafat]

There has been proposals to identify provably unspendable outputs (say bit message kind of stuff) and prune them out of the UTXO set.

Really?
Can u have references for that? This goes along very well with my suggestions.
.
I was also going to add before I saw ur reply, commenting on

The actual standardness limits actually puts the threshold native segwit transaction at 294 satoshis, not 546 satoshis. Electrum includes <546sat output as fees because they didn't want to change the threshold, which is understandable because more often than not, it costs more to spend it.

that the idea of 1 large & 1small UTXOS could be applied now to those
294 ≤ UTXOS ≤ 546
as they now became not dust
.
On 2nd thoughts this could be against just pruning all, just keep them in desk maybe another signature scheme could come & make them non dust

[goatpig]

Really?
Can u have references for that? This goes along very well with my suggestions.
.
I was also going to add before I saw ur reply, commenting on

Sorry I don't think there is an actual BIP for this. This is an idea that was floated among wallet devs a while back:

1. Merklerize the UTXO set for each new block
2. Commit the merkle root to the block's header
3. Maybe provide an alternate network to grab the full merkle tree per block from. This is debatable.
4. As a miner, modulate tx fees based on added UTXO proof.

Originally, committing the utxo tree merkle root to headers was to allow for lightweight UTXO proofs for offline signers (so that they can sign anything without requiring all tx data for each outputs). A corollary use would be to provide proofs for old outputs.

Say, miners and nodes only keep UTXOs for the last 3000 blocks in RAM (2 weeks worth). Transactions that spend from these can be use regular fees. Transactions that want to spend older UTXOs need to provide an added merkle proof that the output is spendable. Without the proof, they would have to hike the fee.

This allows nodes and miners to segregate older outputs out of the UTXO set in RAM, and comes at a negligible added cost to the transaction signer (they should have the proofs for their own UTXOs pre computed, this is static data for each block). It also improves security for offline signers. Since then, SegWit has mitigated that risk, but there still remains a few attack vectors that can leverage that (get an offline signer to sign anything).

[Shymaa-Arafat]

Instead of creating a new post/question I think this could fit here:


In this paper I mentioned before
that discusses dust in detail,
https://royalsocietypublishing.org/doi/10.1098/rsos.180817

it is stated that in Feb 2018, there was %1.4 UTXOS with value 1 Satoshi
-This by the UTXOS number in the same paper means
842,892 UTXOS
-my Q is How those UTXOS got generated in the 1st place when the Bitcoin Core stated the dust limit to 546 Satoshi?
-If they were generated before it, didn't the same version provide a mitigation or certain handling to them?
Otherwise those UTXOS r going to stay there forever???

[HCP]

-my Q is How those UTXOS got generated in the 1st place when the Bitcoin Core stated the dust limit to 546 Satoshi?

There wasn't always a "dust" limit. I think it was added in 0.9.0: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.9.0.md#090-release-notes

-If they were generated before it, didn't the same version provide a mitigation or certain handling to them?

No. Because, technically, they're still "valid" UTXOs. They could be included in a valid transaction and spent. The dust limit simply tells a node to reject and not relay transactions that attempt to create dust outputs... it doesn't stop transactions from trying to spend those transactions (common sense and the costs involved should do that! )

Otherwise those UTXOS r going to stay there forever???

At this point in time, I would imagine they won't be spent. However, it's not definite that they will never be spent. They're still "valid" UTXOs and could be spent if someone had the private keys to do so.

At current fee rates, it would obviously cost more in sats to be able to use one of those UTXOs, but "zero fee" transactions are still valid, so if you find a friendly miner, it's possible you could gather up all those UTXOs and create a non-dust output without incurring any cost (or for a very minimal cost) to yourself.

[goatpig]

-my Q is How those UTXOS got generated in the 1st place when the Bitcoin Core stated the dust limit to 546 Satoshi?

Dust is non-standard but valid: nodes won't relay such transactions but miners can include them.

[Shymaa-Arafat]

I'm asking to think/find a way for better handling of those very low probability of access UTXOS.
I 'm trying to figure out if there number worth the effort of separating them in another partition or not