51. On Flood Attack Prevention

51

On Flood Attack Prevention

THE CONCERN RAISED HERE is the equivalent of a denial of service attack on the Bitcoin network where one entity could send millions of transactions, each transferring a small amount, 1 satoshi (0.00000001 BTC) for instance. This thread is more technical than some others, and not all of the posts have been recopied here only those relevant to the topic and those about concerns addressed by Satoshi.

Flood attack 0.00000001 BC

Posted by Mionione, July 12, 2010, 12:04:24 PM

hi, what would happen if someone sends millions of0.00000001 BC to millions of address please ?

=> all of the networks peers must store all transactions? => are each 0.00000001 owner/hash stocked in blocks on all peers?

i don’t really understand how bitcoin handle fractions of bc

Re: Flood attack 0.00000001 BC

Posted by Gavin Andresen, July 12, 2010, 12:08:45 PM

From the source code:

main.h: // To limit dust spam, require a 0.01 fee if any output is less than 0.01

Re: Flood attack 0.00000001 BC

Posted by llama, July 12, 2010, 02:23:46 PM

Hmm, I didn’t realize that was in there, and I really don’t like that approach.

That pretty much ruins the possibility of using bitcoin for true micropayments. Wouldn’t it be better for clients to just ignore a spammy IP? Sure an attacker could get more, but he couldn’t get millions.

Re: Flood attack 0.00000001 BC

Posted by Gavin Andresen, July 12, 2010, 02:45:54 PM

But how would you distinguish between a legitimate micropayment-processing IP and a spammy “I want to make Bitcoin use so much bandwidth nobody is willing to run it any more” IP?

Really small micropayments seem to me to be a really hard problem, and I don’t think Bitcoin should try to solve too many very hard problems all at once.

Re: Flood attack 0.00000001 BC

Posted by Gavin Andresen, July 12, 2010, 02:45:54 PM

But how would you distinguish between a legitimatemicropayment-processing IP and a spammy “I want to make Bitcoin use so much bandwidth nobody is willing to run it any more” IP?

Re: Flood attack 0.00000001 BC

Posted by Insti, August 04, 2010, 02:58:31 PM

What exactly is this ‘dust spam’ that this 0.01BTC transaction fee “solving”? It seems to do more harm than good because it prevents micropayment implementations such as the one bytemaster is suggesting.

I’m not aware that the network is straining under the weight of the existing transaction volume. Anyone wishing to send a lot of transactions can already dothis by sending x BTC to themselves a lot.

Re: Flood attack 0.00000001 BC

Posted by satoshi, August 04, 2010, 04:25:36 PM

Quote from: Insti on August 04, 2010, 02:58:31 PM

It seems to do more harm than good because it prevents micropayment implementations such as the one bytemaster is suggesting.

Bitcoin isn’t currently practical for very small micropayments. Not for things like pay per search or per page view without an aggregating mechanism, not things needing to pay less than0.01. The dust spam limit is a first try at intentionally trying to prevent overly small micropayments like that.

Bitcoin is practical for smaller transactions than are practical with existing payment methods. Small enough to include what you might call the top of the micropayment range. But it doesn’t claim to be practical for arbitrarily small micropayments.

Re: Flood attack 0.00000001 BC

Posted by satoshi, August 05, 2010, 04:03:21 PM

Forgot to add the good part about micropayments. While I don’t think Bitcoin is practical for smaller micropayments right now, it will eventually be as storage and bandwidth costs continue to fall. If Bitcoin catches on on a big scale, it may already be the case by that time. Another way they can become more practical is if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms. Whatever size micropayments you need will eventually bepractical. I think in 5 or 10 years, the bandwidth and storage willseem trivial.

I am not claiming that the network is impervious to DoS attack. Ithink most P2P networks can be DoS attacked in numerousways. (On a side note, I read that the record companies would like to DoS all the file sharing networks, but they don’t want to break the anti-hacking/anti-abuse laws.)

If we started getting DoS attacked with loads of wastedtransactions back and forth, you would need to start paying a 0.01 minimum transaction fee. 0.1.5 actually had an option to set that, but I took it out to reduce confusion. Free transactions are nice and we can keep it that way if people don’t abuse them.

That brings up the question: if there was a minimum 0.01 fee for each transaction, should we automatically add the fee if it’s just the minimum 0.01? It would be awfully annoying to ask each time. If you have 50.00 and send 10.00, the recipient wouldget 10.00 and you’d have 39.99 left. I think it should just add it automatically. It’s trivial compared to the fees many other types of services add automatically.

Quote from: FreeMoney on August 04, 2010, 07:30:32 PM

Does including more slow down your hashing rate?

No, not at all.

Re: Flood attack 0.00000001 BC

Posted by satoshi, August 05, 2010, 04:30:20 PM

Quote from: bytemaster

Payments would generally be advanced, say 1 BTC at a time and when the connection closes any “change” would be returned. This rule makes it impossible to pay for a simple “search query” with no further transactions.

One alternative is to use a round-up system. You pay for, say,1000 pages or images or downloads or searches or whatever at a time. When you’ve used up your 1000 pages, you pay for another1000 pages. If you only use 1 page, then you have 999 left that you may never use, but it’s not a big deal because the cost per1000 is still small.

Or you could pay per day. The first time you access the site on a given day, you pay for 24 hours of access.

Per 1000 or per day may be easier for consumers to get their heads around too. They worry about per item because it’s harder to figure if it might add up too fast. Unlimited for 24 hours they know what the cost will be. Or if 1000 seems like plenty, they’re not worrying that it’s costing more with each click if they figure1000 is more than they’ll probably use.

Re: Flood attack 0.00000001 BC

Posted by satoshi, August 05, 2010, 04:39:58 PM

Quote from: bytemaster on August 05, 2010, 03:39:19 PM

The only solution to this problem is to make broadcasting of atransaction “non free”. Namely, if you want me to include it you have to pay me. The net (no pun intended) result is that each client would need to pay other clients to whom they even send their transaction, not just the individual who gets it in a block. In this way the laws of economics take over and no one gets a free ride on the transaction broadcast system.

I don’t know a way to implement that. The transaction fee to the block creator uses a special trick to include the transaction fee without any additional size. If there was a transaction for each transaction fee, then what about the transactions fees for the transaction fee’s transaction?

Re: Flood attack 0.00000001 BC

Posted by satoshi, August 05, 2010, 05:49:43 PM

Quote from: bytemaster on August 05, 2010, 04:46:52 PM

Right now the transaction fee address is left “blank” and theblock generator fills it out.Now you would fill it in with the address of the person you are asking to build the block.

If you’re only going to have one person work on building the block, that could take days. Oh, do you mean send a different variationto each node with the tx fee written to them?

The way it is now, it’s whoever builds this gets it.

If we needed to, we could have a BitTorrent-esque tit-for-tat for transaction broadcast. Relay paying transactions to me, or I won’t relay them to you. It probably won’t be an actual problem though. It only takes one node relaying like it should to cancel out 7 others greedily not relaying.

Re: Flood attack 0.00000001 BC

Posted by satoshi, August 11, 2010, 11:28:50 PM

It would be nice to keep the blk*.dat files small as long as we can.

The eventual solution will be to not care how big it gets.

But for now, while it’s still small, it’s nice to keep it small so new users can get going faster. When I eventually implement client-only mode, that won’t matter much anymore.

There’s more work to do on transaction fees. In the event of a flood, you would still be able to jump the queue and get your transactions into the next block by paying a 0.01 transaction fee. However, I haven’t had time yet to add that option to the UI.

Scale or not, the test network will react in the same ways, but with much less wasted bandwidth and annoyance.