Topic: Adding a feature to decline dust transactions (Read 1479 times)

It's really a fairly complicated problem to keep the utility of Bitcoin because you want low fee transactions for "micropayments" (which may not be "micro" for some parts of the world) while protecting the system as it scales and keeping the incentives for miners via transaction fees.

Oh, now I see. I did not consider re-sending the coins or the strain on the network. Thank you!

It would also fill up all the blocks with transactions and push out the regular transactions.  Block size is limited so it can only currently handle 7 transactions a second.  Also increase traffic for the nodes and increased storage space.  

You fail to understand how bitcoin works, then.

Every time you receive bitcoin, it's like receiving a "bill" in that amount.

So imagine I receive 1 BTC...

A. but in one situation I just receive 1 BTC over the span of 1 transaction.

B. In the other situation I receive the 1 BTC over the span of 100 transactions.


Now let's send the 1 BTC to a friend in each case.

A. There is 1 input, so the transaction is likely around 250 bytes, and does not require a fee if you wait a day after receiving it... or 0.00001 BTC if you want to send right away.

B. There are 100 inputs, so the transaction is likely around 14978 bytes to 18178 bytes ish... which disqualifies the amount for a free transaction, AND the fee will be about x15 to x19 times the previous fee. (0.00015 to 0.00019)

But more importantly... the transaction in B is so large that some miners will pass over it in order to save the block from getting too large.


If you have a ton of 1 satoshi inputs in your wallet, and the wallet is dumb... it will try to use those every time you try to send a few dollars out during normal usage, and the fees will become very large.

I guess I am confused... What is the problem with someone sending you a million little bits of btc? Besides flooding your transaction history, I guess I fail to see the negative side. 

Apparently what happened was that the dust transactions got into Armory before I had upgraded QT.  Armory has its own memory pool and it stayed there until I manually cleared it.  With the current version of QT it should not show up all now.

I wasn't talking about any specific wallet, just that a wallet could just have parameters not to display things. I have always used Armory and it displays the unconfirmed dust transactions.  In fact I have 2 of them sitting there for a month.  Not sure if this means they are being rebroadcast because most of them drop off after a couple days. I haven't had a chance to investigate why.

Smart wallets won't even *display* the dust (let alone use it for a tx) so I don't think it is a big worry (in the end you might be able to *spend it* if BTC goes a lot higher in value).

I guess the only real issue here is that if people get sent many thousands of such *dust txs* then it might be a problem for the "listunspent" API.

That is a feature of Bitcoin-Qt. Unconfirmed dust transactions don't enter the memory pool, so they are not relayed, not included in blocks being mined, and not displayed by the wallet.

If I recall correctly, if they DO get mined into a block by somebody then they are displayed. Ignoring them and not adding them to the wallet in that case might be a nice feature, although today's dust might be tomorrow's treasure if prices rise another couple orders of magnitude.

Most don't get confirmed so you just see the transaction sitting there. 

That could be a feature of the wallet:  do not to display any unconfirmed (or even confirmed) transaction less than x

How about this: make a TX without fee and send the Satoshi back to the spammer. Its still blockchain bloat, but at least the spammers have to deal with it.

The Bitcoin network doesn't know anything about the recipient of money. There is no way to set any persistent knowledge about recipients that would do something. A transaction cannot be made invalid or blocked because it has a pay-to address that is undesired.

That means it is up to the recipient to either ignore or deal with payments sent to them. The preference is that you deal with it so that the payment to your address doesn't remain unprunable in the blockchain.

You can include them in other transactions, and about 75% of the time doing so would have no additional cost. Coin control features in wallets let you select inputs to specifically include (or exclude) the dust in future payments.

A possible automated wallet solution would be to include a feature like Peter Todd's dust-b-gone, where a certain dust threshold can be set and the dust auto-swept to a community mining fee transaction. However, this currently transmits a desire to spend the dust directly to Peter's server. That's a fine feature for proprietary wallets to implement themselves. The broadcast transactions needed for this don't work with the relay rules of normal bitcoin though, and we must not create mandatory centralization or specialized nodes, so adding such a function to the p2p network or the reference client would be a good amount of brainwork to implement.

I hate getting spammed with this dust. It would be great if I could put in my wallet a feature to say "dont accept anything less than 10 satoshis) or something like that.. I mean, 1 bitcoin would have to be worth like a million bucks to be worth a penny.  With spamming happening all the time, it would be a nice function. Let the user define what they will accept or reject, if its rejected it goes back to the sending address.