63. On Handling a Transaction Spam Flood Attack
Last updated
Last updated
IN THIS EXCHANGE, Satoshi talks about the introduction of changes in the software that will make it more economically difficult for someone to “spam” the network with multiple transactions.
Posted by jgarzik, November 19, 2010, 07:02:38 PM
Someone is apparently “testing” the main bitcoin network byflooding it with 0.01 BTC transactions from A->A and B->B, where A and B are two random public keys. You can watch at
We’ve hit the free transaction limit on each block, for many blocks nowappears to be ~219 free transactions per block. “real” transactions do not appear DoS’d at this time, presumably due to logic that prioritizes, in part, based on transaction value.
<soapbox>
Free TX’s are just asking for permanent level of spam. There should be a cost to each TX, even if it’s only 0.001 BTC or so.
</soapbox>
Posted by satoshi, November 19, 2010, 11:50:24 PM
Quote from: creighto on November 19, 2010, 08:29:12 PM
Perhaps in addition to the age priority rule recentlyimplimented, there should be a minimum age rule without a transaction fee. Said another way, perhaps a generation rule that says that a free transaction must be 3 blocks deep before it can be transfered again for free. This will still allow real users to immediately spend new funds if they have to, while still permitting real users to reshuffle funds to suit their needs without an overhead cost. I think that this would significantly inhibit the type of spamming attack that is currently underway.
I’m doing something like that. Priority is a more formalised version of the concept you’re describing.
Quote from: FreeMoney on November 19, 2010, 05:39:44PM
As it stands now 3.15 has a lot of free transaction space and that space is given first to transactions with the highest [age]*[value]/[size] correct? Would it be reasonable to make some arbitrary portion of the free space require [age]*[value]/[size] > C ?
Maybe set C so that a standard 1BTC transaction can get into the main free area on the next block. And a .1 can get in after waiting about 10 blocks. And make the area which allows [age]*[value]/[size] < C to let in about a dozen transactions or so.
Yes, like this. And the no-priority-requirement area is 3K, about a dozen transactions per block.
I just uploaded SVN rev 185 which has a minimal priority requirement for free transactions. Transaction floods are made up of coins that are re-spent over and over, so they depend ontheir own 0 conf transactions repeatedly. 0 conf transactions have0 priority, so free transactions like that will have to wait for one transaction to get into a block at a time.
Version 0.3.15 doesn’t write transactions using 0 conf dependencies unless that’s all it has left, so normal users shouldn’t usually have a problem with this.
I think this is a good compromise short of making the default fee0.01. It’s not so much to ask that free transactions can only be used to turn coins over so often. If you’re using free transactions, you’re taking charity and there has to be some limit on how often you can use it with the same coins.
We’ve always said free transactions may be processed more slowly. You can help ensure your transactions go through quickly by addingpaytxfee=0.01.