Bitcoin Forum

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?

nodes will drop excessive tx.

No.  That's why there are mandatory fees.

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.

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.

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


 - 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.

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.

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.

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)

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.

I think this applies to inclusion into blocks not relaying.

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?

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.

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.

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.

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.

Really?  Assuming that you have the transactions already, assembling them into valid blocks is incredibly easy.  Wasn't that the whole point of getblocktemplate?

It is not as easy as it sounds since you have to be carefully choosing those not only unconfirmed and valid, but those that have inputs confirmed in previous blocks and you have to order the rest such that they can be processed in that order (since outputs might be reused in the same block). You also have take into account various limits for the block in size and in number of signatures... to mention a few.

In addition you might have further preferences on transaction selection as miner. Even on the question on which block to build if two are competing.

There is a whole lot a server that prepares block templates can do for you.