Topic: DoS attack against the entire Bitcoin network ? (Read 2187 times)

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.

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

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.

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.

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.

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.

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?

I think this applies to inclusion into blocks not relaying.

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.

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)

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.

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.

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

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

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.

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.

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

Found nothing about your issue.

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

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

http://bitcoin.org/dos

No.  That's why there are mandatory fees.