Topic: Does any wallet software use the heuristic of adding a dust UTXO in each TX? (Read 318 times)

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

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

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


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! )


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.

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???

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).

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
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

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

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

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. However, it is still important to note that just because Electrum always doesn't include change <546 satoshis, it doesn't mean that it is done because it violates the standardness rules.
You can never eliminate dust, that is a fact. You cannot prune them because it makes no sense. Including better coin control will help but it would be marginally more useful at the expense of more privacy leakage from the user. Whether this is an area for improvement is a whole other issue.
Dust isn't that common actually. If you have a dust output, then more often than not, the transaction was once non-standard and miners had to manually include it. You're probably defining it in terms of either costing more to spend it than the actual value or just low value inputs. More often than not, wallets will eventually spend them but it is not always the case. Dust will always exist, while there are proposals for Electrum to start including those smaller and insignificant inputs, I highly doubt it would be widely implemented because the dusting attack will often link many addresses together.

Dust in Armory is defined as a change amount that is less than the transaction's fee. At the time of signing this tx, it is unlikely the change can be spent on its own. The privacy implication and why it is preferable to burn the dust rather than to keep it is that it will most likely lead to damaged privacy in a later transaction, that will combine the dust output with another UTXO. Note that in this assessment, only the fee amount in satoshi is relevant, not the fiat value.

The economics of fees in satoshi vs fiat is hard to predict. In the long term, fees in $$$ tend to stabilize around certain price points (instead of growing unbounded). Fees in satoshi are affected by network load rather than price (the two do tend to come together however), regardless of price point, and will cycle up and down. There is therefor a buffer of UTXOs that is within the reach of the dust threshold, in perpetuity.

To predict what will be in and out of that buffer in the future is about as hard as predicting the market. Armory errs on the side of caution and burns dust by default (you can disable this), while it tries to avoid UTXO consolidation. This is because I expect a user's privacy is worth more to him than a few cents/dollars, even if he might not think so at the moment.

For what it's worth, there is a dust "propagation rule" in Core. There is a minimum amount of satoshis per output Core will tolerate (something like 350, don't quote me on this). A transaction with outputs that have less than this limit will be valid but won't be propagated by default Core nodes (i.e. it is likely you'd have to mine it yourself).

Even if using one of the wallets discussed here, a user can choose not to burn their dust and receive it as change. There are also plenty of wallets which don't do this, and return the dust as change normally. There are also spammers which perform "dust attacks", sending out hundreds of thousands of dust outputs to try to deanonymize addresses when they are later consolidated.

One of my favorite ideas regarding dust, which unfortunately is not active, was Peter Todd's Dust-B-Gone. Everyone would sign a transaction spending all their dust, using SIGHASH_NONE and SIGHASH_ANYONECANPAY, and then send that transaction to Todd's server. Once he had a lot of transactions from a lot of different users, he would combine them all in to a single transaction which spent all the dust as fee and broadcast it. This effectively turned everyone's dust in to extra miner reward, while maintaining privacy and not linking two or more dust outputs together.

Others say this happens in Electrum wallet too, but if this is already happening & dust ~0.16$, and was even less when Bitcoin was less than 30,000$, where did the dust problem came from?
why there's ever dust ?

Not sure this fits the discussion. If change for a tx would come out as dust, Armory will burn that amount as fee instead.

I guess the case everyone agrees on is

.
If u plan to add ur dust change to the fee fine no problem with that, but when u still have dust UTXOS they constitute an overhead to the UTXO set
I don't know their exact ratio now, but previous studies in  2018-2020 estimated them to be 10-15% of UTXOS (at that time the UTXO set was 60 m, ie 6-9m)

Do u imagine every full node is storing & book-keeping unnecessary 6-9m UTXOs along with their hashes?
A Stateless node using proofs/ witnesses is on average getting an extra hash in every proof for that.
I think this may have an effect on every regular user, even if implicit.

This is what I do. If I cannot create a reasonable amount of change by selecting appropriate inputs, then I don't want to create a dust output. I'm going to lose a significant amount of the value of it anyway when I try to spend or consolidate it, and it will almost certainly compromise my privacy in the process. In the past I've either bought an extra item from the merchant or added something else to my basket to spend the dust, added it on to the payment as a tip or donation, added it to the fee, or redirected it to a donation address of a charity or organization I support.

Particularly since the wallet does not know what fee you will end up selecting for such a transaction, or even if you might bump the transaction fee in the future. I might end up wanting to send a transaction with very high priority for whatever reason, selecting a high fee, and then my wallet starts throwing in unnecessary inputs and costing me a lot of money.

That's where coin control features come in. If you don't want the change to be below the dust limit, use other inputs manually and learn how to do it. I wouldn't want to use a wallet that selects two or more inputs in order to avoid dust change, creating a bigger transaction with more fees, instead of just one input. But I do want to have the option to do that if that pleases me and coin control allows exactly that. 

I think from previous replies that what u r suggesting (of adding the change to the fee if it's dust) is already an implemented option in the Electrum wallet, and it goes along with the Bitcoin Core selection strategy of using the closest match ( no problem if the remainder is dust). This is like when u leave a small remaining change as a tip in fiat currency real life transactions.

However, I think this doesn't deal with existing dust or solve the problem completely. Although I don't know the exact current dust UTXOS ratio, I know it has been significantly reduced since 2019/2020 days; but I also kind of know it still exists because of all the dust sweeping/donation projects in the GitHub

I thought adjusting the output is part of it when you said "over-sized fit" and "(not) almost exact match" in the second paragraph.
Anyhow, the later replies further cleared what you are speaking about.

By the way, do you think my proposal of adding the dust change to the fee has better results in terms of UTXO set clutter, transaction size and possibly for privacy?
In respective order:

• if fewer txns produce change, there'll be less UTXO to save in the blockchain;
• less inputs will make smaller txns thus smaller fee;
• having one output might mislead blockchain analytics that it's "self-transfer" and having less change outputs in the wallet means less UTXO that may lead to privacy issue when used together.

I'm not going to discuss this heavily since it's not the topic here, just a suggestion for an alternative.

I should add that I'm not just thinking of the user best interest here, I'm also thinking of the burden of dust UTXOS to the whole UTXOS set

Yes, that's part of the idea; the other part if u have
UTXO A: 0.0010 BTC
UTXO B: 0.0011 BTC
UTXO C: 0.0012 BTC
UTXO D: 0.0013 BTC
My algorithm will choose D as it does not create dust change would be 0.000104)
.
If they're
UTXO A: 0.0010 BTC
UTXO B: 0.0011 BTC
UTXO C: 0.0012 BTC
UTXO D: 0.0013 BTC
UTXO E: 0.000005 BTC
I will choose D&E to accumulate E to the change 0.000109 BTC)
.
However, if user have only one more dust UTXO say D:

UTXO A: 0.0010 BTC
UTXO B: 0.0011 BTC
UTXO C: 0.0012 BTC
UTXO D: 0.000005
I may choose C&D as the change 0.000009 is not dust, but now I think in these tight cases the algorithm must calculate the cost accurately and add the dust only if it's profitable
 ( indeed yes one UTXO  above the dust limit is better than 2 below it, but not at extra cost since 0.000009 could be dust in some higher fee hours)
.
Ps.
Why r u referring to me by "OP"?