nodes will drop excessive tx.

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

http://bitcoin.org/dos

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

Found nothing about your issue.

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.

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

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.

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.

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?

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.

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.