improve dust spamming prevention algorithm

coblee commented at 7:15 pm on June 29, 2012: contributor

This code helps with reducing dust spam. The original code will make the transaction fee become the minimum fee if any output is less than a cent. This makes it costly to send dust spam, but there’s an edge case. The attacker can send a transaction with 1000 outputs of one satoshi each. The transaction size is huge but the fee is only the base fee. This fix will increase the fee by the base fee amount for each output that’s less than a cent.

improve dust spamming prevention algorithm to add base fee for each output that's less than a CENT 9b11e48d5a

jgarzik commented at 7:24 pm on June 29, 2012: contributor

ACK – the economics seem to make sense, but I am interested in comments from others

coblee commented at 7:55 pm on June 29, 2012: contributor

Here’s a sample attack: http://abe.liteco.in/tx/48878749fa2bbad375cc5aa8332aabb262c0a98259e85bbdb20f42ab4fa38966

Only cost him 1 LTC to bloat the blockchain by 50kb

gmaxwell commented at 8:01 pm on June 29, 2012: contributor

This doesn’t sound bad— although generally I’d like to start talking about how to get the net-change-to-the-open-txn-set included in the free/priority structure.

This is a dual attack in that it both adds static blockchain data but it also adds a ton of data which is probably never going to get redeemed, thus also burdening pruned nodes. This could be discouraged using as the size metric of something like max(size/2,2*size-size_of_txouts_reedemed). This would also discourage this sort of attack, where the out data size is much larger than the redeemed inputs.

coblee commented at 8:06 pm on June 29, 2012: contributor

Yes, once you get a lot of dust spam, select coins can take forever. For Litecoin, I had to implement a workaround for people to ignore the dustspam and make them not count towards coins that they own. It was a huge pain.

gmaxwell commented at 8:12 pm on June 29, 2012: contributor

Sort of tangent— but wrt the select coins problem you might want to look at adding a post processing step: once you’ve prepared a txn with change and either a free txn with excess priority, or a with fee which isn’t right at the boundary, then add in additional of your smallest inputs in order to get them out of your wallet (and out of pruned chains).

gmaxwell commented at 2:22 pm on July 2, 2012: contributor

On further consideration: This will break the faucet, it will also remove an incentive to use sendmany.

coblee commented at 3:53 pm on July 2, 2012: contributor

As Bitcoin’s value increases, you will probably need to reduce the value in which a output is considered spam. For Litecoin, less than 0.01 LTC is pretty much worthless. Maybe for Bitcoin, we should change it so that we add a fee for any output less than 0.0001 BTC.

gavinandresen commented at 6:26 pm on July 2, 2012: contributor

This doesn’t feel like the right fix to me.

Fixing the coin selection algorithm so it works quickly with wallets containing gazillions of tiny transactions is part of the solution. Something simple like “If there are more than X unspent outputs, don’t use the fancy knapsack-problem-solver, just use the biggest-value unspent input(s) until you have enough to pay for the transaction+fee.”

See https://gist.github.com/2961409 for the direction I think will work. With the right priority algorithm (and a minimum-to-be-relayed-included threshold) I don’t think a dust spam fee is needed at all.

coblee commented at 6:31 pm on July 2, 2012: contributor

The coin selection fix does not fix the problem that someone can bloat the blockchain with only a small fee like this: http://abe.liteco.in/tx/48878749fa2bbad375cc5aa8332aabb262c0a98259e85bbdb20f42ab4fa38966

gavinandresen commented at 6:51 pm on July 2, 2012: contributor

Right, see the gist for the other part of what I think would be a better fix.

For a very-low-transaction-volume chain like LiteCoin, I think the right fix would involve miners specifying a small maximum block size (say 10K, enough space for 40 or so regular-sized transactions) and a high “forgo this amount of transaction fees” (so block space is dominated by transaction priority, not fee).

BitcoinPullTester commented at 4:01 pm on August 9, 2012: none

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/9b11e48d5a03662333c11c046017f9394b127cd5 for binaries and test log.

SergioDemianLerner commented at 3:22 pm on August 13, 2012: contributor

Remember there is a previously reported attack involving one connection sending txs with tiny amounts to increase the GLOBAL limit, thus preventing the other connections from sending free transactions. It’s necessary to review how this change may affect that attack, and if it can make it worse. I suggested using per-connection limits, and not a global limit.

jgarzik commented at 4:09 pm on September 4, 2012: contributor

It sounds like consensus is against merging this specific fix at this time.

jgarzik closed this on Sep 4, 2012

felipelalli commented at 5:24 am on July 8, 2015: none

It sounds good merging this specific fix at this time, after some attacks.

m-schmoock commented at 7:25 am on July 8, 2015: none

One only learns from mistakes

adv0r commented at 7:56 am on July 8, 2015: none

@felipelalli +1

mb300sd commented at 2:22 am on July 9, 2015: contributor

Whatever my opinion is worth… +1.

ghost commented at 7:41 pm on July 9, 2015: none

Consensus has changed. It’s back on the table. This could potentially resolve the backlog we have in transactions

pentarh commented at 8:39 pm on July 9, 2015: none

Txout should be compared not to CENT, which is very hardcoded value, but to nBaseFee imho. Like this

if (txout.nValue < nBaseFee) nMinFee += nBaseFee;

ABISprotocol commented at 3:08 am on July 14, 2015: none

This is certainly not back on the table at all, imho. There were very good reasons this pull request was closed out in 2012. I would encourage people to re-read the remarks (including those of @gavinandresen as shown here) and @gmaxwell’s.

It’s a bad idea to take a nuclear option with respect to fees and reject the opportunity that can be presented from analyzing microgiving potential. Odd also that people keep referring to this as “dust spam” when they could be reframing the language and the issue… the current “dust problem” (which I would argue should actually be called a “giving opportunity”) is an opportunity to re-examine transactions, transforming them into bursts of microgiving. Do not foreclose on the an opportunity to re-examine and re-envision transactions and thus change the system you are using.

In closing, I would also recommend you see issue #6402 as an example (of how this could be handled better, perhaps) and also some of the more recent comments on #6201 (including one that I’ve entered).

suprnurd referenced this in commit 6cb3fddcc1 on Dec 5, 2017

lateminer referenced this in commit be79988a8f on May 6, 2020

DrahtBot locked this on Sep 8, 2021

improve dust spamming prevention algorithm #1536