DoS attack against the entire Bitcoin network ?

[Meizirkki]

Sorry if this is duplicate thread, I searched first but couldn't find it.

Is it possible for an attacker to crash the entire Bitcoin network by flooding transactions? Like, infect thousands of computers with a software sending coins around between few wallets?

[hamdi]

nodes will drop excessive tx.

[Revalin]

No.  That's why there are mandatory fees.

[Akka]

There was a Vulnerability until Version 0.6.2 where it has been fixed.

http://bitcoin.org/dos

[Meizirkki]

There was a Vulnerability until Version 0.6.2 where it has been fixed.

http://bitcoin.org/dos

I found this yea. But isn't it about isolating a single client from the network? Not about trying to flood the blockchain.

[Akka]

There was a Vulnerability until Version 0.6.2 where it has been fixed.

http://bitcoin.org/dos

I found this yea. But isn't it about isolating a single client from the network? Not about trying to flood the blockchain.

Year, right. Missed that. So forget my post.

Found nothing about your issue.

[notme]

This was possible but now many miners require fees for transactions whose inputs are the output of another recent transaction.  Essentially, if you don't let your coins sit for a day or two you will have to pay a fee.  If you have to pay a fee, you can only "attack" for so long because every transaction costs you a penny or so.   Additionally, the larger the transaction (in KB) the higher the fee that will be required.

[Stephen Gornick]

Is it possible for an attacker to crash the entire Bitcoin network by flooding transactions? Like, infect thousands of computers with a software sending coins around between few wallets?

Here are the types of denial-of-service attacks the bitcoin.org client and others that behave similarly will protect against:
 - http://en.bitcoin.it/wiki/Weaknesses#Denial_of_Service_.28DoS.29_attacks

Spamming transactions

It is easy to send transactions to yourself repeatedly. If these transactions fill blocks to the maximum size (1MB [Edit: 0.5 MB if I remember correctly]), other transactions would be delayed until the next block.

This is made expensive by the fees that would be required after the 50KB of free transactions per block are exhausted. An attacker will eventually eliminate free transactions, but Bitcoin fees will always be low because raising fees above 0.01 BTC per KB would require spending transaction fees. An attacker will eventually run out of money. Even if an attacker wants to waste money, transactions are further prioritized by the time since the coins were last spent, so attacks spending the same coins repeatedly are less effective.

 - http://en.bitcoin.it/wiki/Weaknesses#Spamming_transactions

So the network doesn't know the difference between your flooded transaction sent from older coins in your wallet and my transaction sent from older coins in my wallet where both of us are paying the same fees and sending at the same time.     But after you've spend that transaction, your change that you've received  is now a newer coin.  And if you try to spend the change, your transaction does not look like mine and if a miner has to start choosing which transactions to include in a block, your spam-like transaction doesn't get chosen.  

The bitcoin network is handling 50K transactions per day easily now.  So to properly prepare for this attack you might want to have a wallet with a couple hundred thousand addresses (or more) each with a bitcoin or so of funds for each address.

So harassing bitcoin as it exists today is certainly possible, it is just requires resources normally outside the range of someone curious if it could be done.  Additionally, if there is a pattern seen as being disruptive, there are changes to the client that the miners can perform to give preference to transactions that don't look like yours -- though you too might be able to adjust in response.  And an arms-race proceeds.  You would need to be determined to have a lasting impact.

[Remember remember the 5th of November]

This was possible but now many miners require fees for transactions whose inputs are the output of another recent transaction.  Essentially, if you don't let your coins sit for a day or two you will have to pay a fee.  If you have to pay a fee, you can only "attack" for so long because every transaction costs you a penny or so.   Additionally, the larger the transaction (in KB) the higher the fee that will be required.

Paying a fee is hard coded no matter if you have the oldest coins.

[notme]

This was possible but now many miners require fees for transactions whose inputs are the output of another recent transaction.  Essentially, if you don't let your coins sit for a day or two you will have to pay a fee.  If you have to pay a fee, you can only "attack" for so long because every transaction costs you a penny or so.   Additionally, the larger the transaction (in KB) the higher the fee that will be required.

Paying a fee is hard coded no matter if you have the oldest coins.

Not true.  Many transactions will accepted by nearly all miners without a fee if they are small and the inputs are old enough.

[DannyHamilton]

. . . if a miner has to start choosing which transactions to include in a block, your spam-like transaction doesn't get chosen . . .

Correct me if I'm wrong, but it is my understanding that it isn't just miners that might ignore a fee-free transaction with recent (young) coins or large number of inputs.

Don't many of the clients also refuse to relay these transactions?  Meaning that most of the network won't even see (and have to deal with) the transactions, preventing them from flooding the network.

[Stephen Gornick]

. . . if a miner has to start choosing which transactions to include in a block, your spam-like transaction doesn't get chosen . . .

Correct me if I'm wrong, but it is my understanding that it isn't just miners that might ignore a fee-free transaction with recent (young) coins or large number of inputs.

Don't many of the clients also refuse to relay these transactions?  Meaning that most of the network won't even see (and have to deal with) the transactions, preventing them from flooding the network.

Miners can do whatever they want, including "ignoring" transactions.  

I'm not sure the exact behavior of the Bitcoin.org client.

Using the description from the Wiki (posted above), the
 
If a fee of 0.0001 BTC is paid, the client will relay it.   If that fee is not paid, the client will still relay it even if no fee is paid as long as all outputs are 0.01 BTC or larger and the total size is less than 10KB.  It does not appear that the age of a coin has any affect on whether or not the node will relay the transaction.

Now just because a node will relay the transaction doesn't mean the fee is sufficient to get it included in a block in a timely manner.

[gmaxwell]

If a fee of 0.0001 BTC is paid, the client will relay it.   If that fee is not paid, the client will still relay it even if no fee is paid as long as all outputs are 0.01 BTC or larger and the total size is less than 10KB.  It does not appear that the age of a coin has any affect on whether or not the node will relay the transaction.

It does— the transaction will not be relayed if it doesn't pass all the free criteria: no dust outputs, small size, and priority greater than 57600000 (COIN * 144 / 250).  Priority is the sum(value*confirms)/data_size. (Otherwise someone could flood out the whole network easily)

[grau]

I wonder if zero fee transactions should be relayed at all, since the minimum fee is so low (0.0001 BTC) it should not prohibit any legit use.

[grau]

the transaction will not be relayed if it doesn't pass all the free criteria: no dust outputs, small size, and priority greater than 57600000 (COIN * 144 / 250).  Priority is the sum(value*confirms)/data_size. (Otherwise someone could flood out the whole network easily)

I think this applies to inclusion into blocks not relaying.

[farlack]

What if you have a botnet of.. 25,000 computers?
I feel like even if they did pay the fee, the fact they could mine that fee back pretty fast with the botnet anyway it would not matter.


All I'm seeing posted (What I think?) is if I have 3 computers, and I'm repeatedly sending coins back and forth between all 3 the servers will block it, but if you're switching coins between 25,000 whats stopping it then?

[grau]

You only need one computer to create any number of payments.

In case you pay fees they will be guaranteed relayed. The fees you pay go to the miner not your other computer.

You might get tired of subsidizing them.

[kjj]

the transaction will not be relayed if it doesn't pass all the free criteria: no dust outputs, small size, and priority greater than 57600000 (COIN * 144 / 250).  Priority is the sum(value*confirms)/data_size. (Otherwise someone could flood out the whole network easily)

I think this applies to inclusion into blocks not relaying.

There are no "requirements" for getting into a block, beyond having valid signatures and not-yet-spent inputs.*

But, if you aren't mining yourself, or don't have sufficient hashing power to get somewhat frequent blocks, then the rules for transaction relaying are effectively the rules for getting other people to put your transactions into their blocks.

* I suspect that we long ago passed the point where the majority of blocks are generated by software other than the reference client.  I could very easily be wrong about that, but I think that most pools are running custom software to generate blocks according to their own local rules.

[grau]

the transaction will not be relayed if it doesn't pass all the free criteria: no dust outputs, small size, and priority greater than 57600000 (COIN * 144 / 250).  Priority is the sum(value*confirms)/data_size. (Otherwise someone could flood out the whole network easily)

I think this applies to inclusion into blocks not relaying.

There are no "requirements" for getting into a block, beyond having valid signatures and not-yet-spent inputs.*

The rules gmaxwell cited are in the Satoshi code where compiling new blocks. I do not know if miner use this.
They are not used for relaying, and that was my point.

[gmaxwell]

* I suspect that we long ago passed the point where the majority of blocks are generated by software other than the reference client.  I could very easily be wrong about that, but I think that most pools are running custom software to generate blocks according to their own local rules.

I'm certain that you're wrong there. The attempts that I'm aware of that have gone even somewhat close to this have resulted in invalid blocks, so if it was widely being done the invalid blocks would probably be noticeable.