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

Sure it does, the transaction fee schedule is written with the purpose of limiting DOS attacks upon the network by making compunding transactions increasingly expensive, without actually prohibiting them.  Not only does this make DOS/spamming the network prohibitively expensive for the attacker, it also provides an incentive for honest clients to throttle their transactions whenever the network is loaded down (delaying additions to blockchain, not preventing them) as well as provide an additional incentive for generators to accept the burdens.

Kids these days, always thinking that their revelations are original.

Bitcoin currently provides excellent security guarantees against forgery or other tampering but no effective countermeasures against spamming or other denial of service attacks. Spamming the network with valid transactions at 1MB per second results in a disc usage of at least 2TB per month.  This would cause probably all hash generation to stop after a couple of months. What would happen subsequently is less certain.

Possibly if the attackers ramped their spamming up slowly then people would sell their Bitcoins just before they stopped their client and deleted the transaction data taking up all their disc space. This would drive the price of Bitcoins down and the attackers could buy them cheaply. Then a client more resistant to spamming is released (such as a client using "balance sheets" ). Harmony is restored and the value of Bitcoins soars to its normal level!

ByteCoin

Compromising the bitcoin network is the fastest way to make your investment in a botnet worthless. Better to just mine it and sell it for bitcoins.

Why does it seem to me that botnets would do nothing but improving the security of the network ??

I mean those guys controlling those botnets would earn money by mining, but I doubt they could steal anyone.

The ANDS aren't meant to prove anything. They are milestones for a plan that give a probable difficulty in reach each milestone in anecdotal form. Meaning, if my goal was to buy up the world's gold supply. The plan would be as simple as step 1, buy all the gold, step 2, I have all the gold. But we know there would be a lot of steps in between to achieve that goal.

This topic had a 5 step plan for the goal on how to profit from a Bit Coin attack using a Bot Network and filling in the in-between stuff just further documents the difficulty in it, that's all. 

But I know what you mean and I agree, the botnet guys are making enough money not to really care about a Bit Coin scam at the moment.

Yes, those things are easy.

I'm not a botnet creator, so I really have no idea on the economics of it.  I also wouldn't assume you're not being paid for 2 months, as you'd likely have income from whatever previous scams you've created.  The two month estimate was an extremely conservative one.  The other end of the spectrum is something like a couple weeks to get out Version 1.

The point being, listing out a bunch of AND AND AND's proves nothing.  You're quite right that it has to be economical, we just simply disagree that something like this isn't potentially extremely economical.  The biggest hurdle is likely that bitcoin is just too small for a serious botnet guy to make any money off of and do anything with.  As it grows the profit potential only grows larger.

Are these things suppose to be easy? People don't operate botnets because they are hard, but because it makes them money for the amount effort they are going to put into it. I read in the news from time to time about botnet operators getting busted. They weren't doing it for the *rush* of the challenge, but to make a living.

2 months of dev work is like not getting paid for 2 months. The investment would have to be worth it to someone with that much free time. Plus there is a movement out there to root out botnets. So all your work could go up in a electron should someone shut you down or wipe our/take control of your botnet.

Risk vs Reward, right now there really isn't a reward for a Botnet operator.

Huh?  Are these things supposed to be difficult?  You make it sound like it would take years of development to do this.  I've developed software for 10+ years, and in my estimation it'd take a skilled programmer perhaps a month or two to do this from scratch.  Possibly much less.  Anyone that has created botnets has already created the remote control libraries, so that's just a matter of linking them in.

Someone else mentioned a botnet hearder not wanting individual nodes to be discovered because of the CPU usage.  Well, most people don't EVER bring up a CPU usage meter, so the risks of that are minimal.  If you REALLY cared about that sort of thing, just stick in some code to shut down the usage whenever you detect keyboard/mouse activity. 

These are not difficult problems to solve at all.

Botnets would ideally attack the network while the difficulty is low, stop while the difficulty is high and repeat. I would imagine that botnet operators value their botnets enough to not risk many nodes being discovered from the computers running full blast all day everyday while producing bitcoins, but I might be wrong. I suppose they could run all the clients on half their cores, which would cut down on visibility. Anyway, bitcoins may be worth a lot right now, they're only worth that much because no one is flooding the market with bitcoins. They would have to withdraw only a small amount of money each day by only selling their bitcoins when someone offers to buy a small amount of them at a good price. If you were to look at the confirmed volume of trades occurring and adjust for possibly fake traders trading with themselves to alter people's impressions, I think you'd be surprised how few people are actually spending their hard earned cash on bitcoins each day.

It would take a botnet larger than the current CPU pool (which might be possible), but it takes 100% CPU to make it happen, even if it's running on idle CPU time.

So first, someone will have to take the source code AND compile a version that will remain hidden AND produce bogus blocks AND be able to be remotely controlled AND be able to restart itself after a system reboot/shutdown AND coordinate this properly to have *all* bots online at the same time AND be able to funnel those fake blocks to a central fake client AND be compile another client that will accept those fake blocks AND it will have to be setup to only work as private/local nodes AND you'll need another compile for a client that will connect to the public network AND the fake network to start loading up the fake blocks AND, AND, AND...

I think getting the botnet will be the easiest part of this attack before one could move forward with it. 

Bogus blocks? o_O

Doing it my way should be able to give you around 10% of the value of all bitcoins in a short amount of time = more efficient

1. Acquire access of large botnet
2. Have bots join bitcoin.
3. Speculate against bitcoin somehow
4. Have all of you clients transfer huge amount of bitcoin to an account controlled by you using bogus blocks
Now either two of these will happen
*Massive loss of trust in bitcoin
  5. Profit from speculation
*Little or no loss of trust
  5. Profit from theft

Works?