Transaction / spam flood attack currently under way

Someone is apparently “testing” the main bitcoin network by flooding 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 http://theymos.ath.cx:64150/bbe

We’ve hit the free transaction limit on each block, for many blocks now — appears 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.

Perhaps in addition to the age priority rule recently implimented, 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.

In a free market for transaction fees, spamming the network will have the effect of increasing transaction fees for everybody.

Maybe Mr Burns is more than just a common griefer. Maybe he is a miner with more rational motivations.

A miner has more to gain than to lose by spamming. Yes, eventually a spam equilibrium will be reached where the marginal amount you lose in your spam to the transaction fees of competing miners equals the marginal amount gained from your own transaction fees. But that is still a macroeconomically subobtimal situation.

To escape this http://en.wikipedia.org/wiki/Social_trap social trap, more than a market is needed.

Some simple but effective rules should be hardcoded into the Bitcion protocol/specification itself, to discourage the excesses of spamming.

I know that this approach probably sounds too “top-down” for the free market enthusiasts in this forum, but the rules should of course be purely voluntary and consensus based, like the 21M rule we have already.

[Deleted] Quote from: davidonpda on November 19, 2010, 08:35:15 PM

Quote from: creighto on November 19, 2010, 11:29:12 AM UTC

Perhaps in addition to the age priority rule recently implimented, 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.

That could make people get tied up in their funds again. Think MtGox or even the bitcoin faucet. Faucet can only send out a nickel every 3 blocks, because each time it sends a nickel, it sends the change to a new address, tying up transaction fee free for 3 blocks.

Only a little. If the rule is generally known, and the reason for it, I think that those like the bitcoin faucet could adjust. I’m talking about limiting based upon the coins movement, if that’s possible, not a three block ban upon a particular address. The new client has 100 addresses, correct? If bitcoin faucet has more than BTC .05 in each address, and simply rotates the addresses as the requests come it, then it can service 100 requests in half an hour without delay, and more with delays. I’m not saying that transactions can’t be created, just that generators will not put them into blocks until the transaction that they depend upon is three blocks deep without a fee. With a fee, they can do whatever they want; and the generators probably wouldn’t honor a 3 block delay upon a fee paying transaction anyway. This leaves the possibility of free transactions an open possibility, while inhibiting spamming. If there is a technical reason that this rule cannot work, I wouldn’t know about that.

EDIT: Markets that are trying to service withdraw requests would know how many requests have been sent in the previous 30 minutes, and could choose to warn the requester that such requests may be delayed by this rule, or they can choose to pay a fee out of it.

In reply to some of RHorning’s comments:

Transaction fees should always be determined by the miner. If someone has a high limit, someone will do it cheaper and it will get accepted into a later block.

We need an easy way for people to add transaction fees from the GUI, and we need an easy way for miner’s to specific a minimum transaction fee if possible. The later less important than the first.

How do you “shop” for transaction fees under this system? I guess I’m getting very confused here over how this works.

For example, if a miner gets a successful hash, what stops them from “charging” a 95% transaction fee? What keeps those transactions from getting incorporated into the block and recognized by the network?

Is there a way for you to say “I don’t want to pay this fee” and “shop” for a miner that charges smaller fees by simply waiting?

It also sets up an interesting DOS attack where potentially a miner with a large bank of computers could charge very high transaction fees, slowing down or even potentially stopping trades. I guess the way to stop that would be to get a bunch of computers for yourself and hope you can squeeze in a successful hash at least for yourself to get your transactions put into the network without a fee (presuming you can be selective on the fees for your friends and own addresses).

Is this something that could be put into the user interface, where you can “select” what fees you would be willing to pay?

It also sets up an interesting DOS attack where potentially a miner with a large bank of computers could charge very high transaction fees, slowing down or even potentially stopping trades. I guess the way to stop that would be to get a bunch of computers for yourself and hope you can squeeze in a successful hash at least for yourself to get your transactions put into the network without a fee (presuming you can be selective on the fees for your friends and own addresses).

Well, you can do all sorts of stuff if you have >50% of network CPU power.

Well, you can do all sorts of stuff if you have >50% of network CPU power.

This wouldn’t even require 50% of the network CPU power. 20% would be enough to “slow the network down” with a significant degrading of service and ramp up the difficulty for the rest of the network considerably. Then again, you would be a fool to pass up on potential transaction fees simply by only accepting transactions that would permit a high fee or an impossible fee.

My understanding of this is really muddled and I’m not not really sure how the fees are decided or what happens when you type in an address, an amount, and try send some bitcoins to somebody.

Perhaps in addition to the age priority rule recently implimented, 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.

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 on their own 0 conf transactions repeatedly.  0 conf transactions have 0 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 fee 0.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 adding -paytxfee=0.01.

Outstanding!

We’ve always said free transactions may be processed more slowly. You can help ensure your transactions go through quickly by adding -paytxfee=0.01.

Good solution. And it would be even better to expose this clearly in the GUI! Instead of hiding it as a command line option 😊

MrBurns is probably just checking to see what happens before he buys 100,000 coins.

Maybe he is planning on buying back the Springfield nuclear plant?

😛