Topic: A lucrative attack on bitcoin? (Read 13253 times)

In any case, ArtForz controls 30%+ of the network's CPU, and he would immediately adjust his fee rates in response to a block flood. Eventually dedicated companies will own the network's CPU and will be able to do likewise.

I forgot to move the decimal over for the fee per KB.  

Currently the client forwards transactions that it considers valid as long as it is the first time that it's seen it.  It doesn't have to.

I must correct you jgarzik when you said that you stood corrected!

I believe that theymos has made a mistake in his calculations.
We're assuming that we can generate transactions as close as possible under 1000 bytes long.
The basic charge is 0.01 for 1KB which applies after the block size exceeds 50KB.
So the 200KB between the 50KB and 250KB block size would cost 0.01*200=2BTC. We agree!

After 250KB if the block size is x (in KB) then the charge is approximately multiplied by 500/(500-x)
This means that the charge jumps to 0.01 * 500/(500-250) = 0.02 BTC after 250KB ramping up to 0.01 * 500 /(500-300) = 0.025 BTC at 300K. For the fifty 1KB blocks between 250 and 300 the most expensive one only costs 0.025 BTC so the total can't possibly be more than 1.25 BTC so theymos is easily out by a factor of 100.


More detailed calculations (neglecting the real rounding used in the code and being somewhat cavalier about other details) give

Block Size	Cumulative Cost
KB	BTC
50	0.00
250	2.00
300	3.14
350	4.58
400	6.62
450	10.12
499	32.53
500	5032

So the last transaction of 999 bytes to take the block size to 499999 bytes costs 5000BTC and the preceeding one costs just 5 BTC!

ByteCoin

This might be a valid attack at the moment, but it's not like it can't be handled by real people should the need arise.  There is nothing that says that a particular generating client can't be set to ignore transactions based on certian parameters beyond the current Bitcoin settings.  One particular client that ignores transactions over half a meg in size, for example, does nothing; but as other generating clients take take a similar approach that kind of attack becomes progressively less successful.  It's not like the rules are set in stone, this is a community.  The majority will rule.

That said, it's not a particular problem now because there is nothing that says that the spamming agent is the one to benefit from his efforts.  Classic game theory, so I don't think that it's ever going to be an issue, as that would imply collusion, or at least that one particular generator has begun to monopolize the network.


There is no way to cancel a transaction, nor should there be.


Transactions are not persistent per se.  The client can be modified to clear the transactions older than an arbitrary time limit, or simply rebooted.


Bitcoin doesn't have many countermeasure against spamming, because there is little real evidence of what kinds of attacks are effective against it.  Try and break it, you will help future users.

Nice!  I stand corrected.

Driving a block to 1MB costs 21 million BTC. I don't think attackers are going to pay...


Here's how much it would cost (estimates) to make the block size go to various levels:
-50 KB: Free
-250 KB: 2 BTC
-300 KB: 127 BTC
-350 KB: 293 BTC
-400 KB: 543 BTC
-450 KB: 1043 BTC
-490 KB: 3543 BTC
-495 KB: 8543 BTC
-499 KB: 33543 BTC

Attackers can feel free to pay 500 BTC every 10 minutes to make sending transactions expensive...

Because not everyone will use such a client, there will always be some generation that is not entirely profit motivated.  Search for the thread about generation for heat.  Some will always be motivated in other ways, such as keeping the other major players honest.  This is an open source project after all, no one has produced such a client yet, thus far the reward is enough of an economic incentive to get people to generate honestly; the additional transaction fees are tears in the ocean compared to that reward.  All that added to the fact that the regular block reward doesn't expire for about 120 years, after which the competition will set the price for transaction fees.

Damned it.  Do you mean that Governments could harm the bitcoin network with this kind of DoS attack ?

Large blocks are a valid DoS attack against bitcoin, presently.  Transaction fees kick in at higher block sizes, but it still remains quite inexpensive to flood the network, even if you are paying full TX fees right up to the 1MB (?) block limit.  I dunno about lucrative, but...

That's about transactions in blocks, which are further protected by transaction fees. I'm talking about transactions waiting to get into a block.

Regarding the attack discussion, I don't know how the client behaves, but it has no reason to keep in the pool transactions that it wouldn't add to any block anyway. Actually, ByteCoin has just pointed a reason for not doing so.
The unacceptable transactions should be forwarded and forgotten. It's up to the stingy sender to retry if the transaction is completely forgotten by the network.
Those doing "charity work" (adding transactions with no fees) would be vulnerable to this sort of denial of service attack, yes. And if they ever generate a block - before running out of memory/disk space -, it will be a damn huge block!
But I see no "lucrative incentive" for such an attack, though. If you want to forbid free transactions, just publish a free version of the client that allows its users to specify minimum transactions fees.

Transactions are forgotten over time, to prevent just this problem! Nodes delete transactions in their memory pool on shutdown, and they never rebroadcast transactions that they already know about. This causes most of the network to forget about a transaction in about a week. If your transaction isn't going through, you would restore from an old wallet backup, wait for the network to forget your transaction, and re-send.

Why?
That would happen as soon as there is a client that allows the user not to add transactions with no fees to the block it generates.

I don't understand everything but somehow I have the feeling that what ByteCoin says is not completely rubish.

Could someone examin all this seriously and make a clear report ?  Ideally it would be Satoshi but I guess he can't be everywhere.


PS.  I think there is an intrinsic limit to the number of transactions per second.  I guess it was in order to resist this kind of attack.

You seem to be holding two mutually contradictory postions, creighto.

On the one hand, in response to my observation that hashers are rewarded for using up the free transaction quota, you reply that the fee schedule could be altered to discourage it. On the other hand in your response to caveden you imagine that fees will not be charged for all transactions until we're all long dead.

For this to be true one or more of the following would have to occur:

• Bitcoin ceases before fees are levied on all transactions.
• We all die rather sooner than we expect!
• Hashers will forever altruistically refrain from maximising their profit and nobody uses Bitcoin for data storage/distribution purposes.

Please explain.
Ok perhaps not all transactions would have fees but the free ones would immediately be used up by the hasher spam so effectively all transactions would need fees.

The point I was making about buying something expensive urgently is the following:
Suppose I have 90 BTC. My friend is in desperate need of 50 BTC so I send it to him without including a fee. All the "free" transactions in the block are taken and, as it doesn't include a fee it's not included in the block. I realize my mistake and would like to cancel the transaction and am willing to reissue it with a 10BTC fee payment to get it in the next block for sure. However, I don't think I can do that as I've already spent the 50BTC and I only have 40 left. There may be a workaround for this. What is it?

More fundamentally, let's say someone for whatever reason spams the network with lots of transactions with no fee at 1MB per second. Most of the transactions don't get into blocks because they don't have the necessary fee, but they are not forgotten! They have to persist in all the clients to try to get into the next block. Are they stored on disc? If they are stored in memory then the client consumes memory at 3.6 GB every hour! If they are stored on disc then it's the same problem as if they were hashed in the block chain.

Unless there is a scheme for forgetting transactions that have insufficient fee then it's still a big problem. I said that Bitcoin doesn't have effective countermeasures against spamming. I think I have shown that fees are not effective and that the current fee schedule make the problem worse, not better.


ByteCoin

Yes, but that future is a long way off.  Likely we will all be long dead.

I doubt it, more likely it will just be extended as neccessary.


This assumes a static fee schedule.  If such a thing started to become a problem, the fee schedule could be altered to deal with it; perhaps even in an automatic fashion like the difficulty level.


Interesting situation, but it's not likely to matter.  If a transaction needs to be included in a block, the design allows the client to issue a fee anyway, which encourages that transaction to be included in any generator's block that sees it.  And unfeed transactions might have to wait until a less busy block to be included, but don't disappear.  Re-issuing a transaction with a fee would be another transaction.  If you desperately need your transaction processed, in a Bitcoin future, you are likely to click the "add a fee" option.  If you are sending money to someone who trusts you, to someone for which you can wait for the processing, or as a gift/donation; there is no need to pay a fee.  This is a major advantage of Bitcoin over other methods of electronic payment.

The only reason why you can make free transactions so far is because the only client that exists doesn't allow the user to specify transaction fee rules.
If people generating could specify their own rules regarding fees, they wouldn't accept transactions with no fees (ok, there are always the exceptions, but they would be few...)

So, in the future, we may expect that all transactions will have to pay fees anyway.

The current fee structure is acknowledged to be tentative and I had assumed that in order for the system to work properly as the transactions ramp up, the fees would mostly be scrapped. The current fee system for example actually encourages abuse by block hash generators as follows:

People trying to earn money hashing blocks have an incentive to spam the network with enough small transactions (1 in and 1 out) to fill up the 50kb "small transactions are free" limit. If any real users of Bitcoin want their transactions to go confirmed then they have to pay the 0.01 fee to get them included in the next block in preference to the spam transactions. The cumulative fees reward the block hashers for their spamming.

When fees start to be effectively mandatory under the above scheme, some interesting cases need to be handled. For example, if someone tries to buy something expensive that they need urgently with bitcoin but they don't include a fee, can they then reissue the transaction with the fee, using the same coins or will the network regard the original unfeed transaction as having already spent them?

ByteCoin