Topic: What might an attack on the network via an implementation bug look like? (Read 835 times)

I think going into BFL headquarters with guns blazing after their ASICS arrive would be a better approach to what your worried about. In fact...
I think Im on to something  lol  J/K BFL

Thanks for the explanation.  That's very reassuring.  Despite having made investments intended for the long term in to bitcoin, I had been assuming that a single implementation bug could have catastrophic impact if exploited in the right way.

none

remote execution of a client might allow an attacker to steal some coins (the type of attack you don't want to discuss) but the amount of damage a "bad node" can accomplish is limited because nodes can only forward or not forward tx.  If enough nodes stop forwarding tx you could see some degradation in network performance but it is unlikely even with control over thousands of nodes you could prevent tx relaying.

Gaining remote control over 51%+ of miner's block generation could allow a 51% type of attack but that is even less likely as most miners don't use local bitcoind for block generation they rely on pool servers.  The fact that miners use a wide variety of mining software and use different pools (often with backups) means the probability you could remotely control that much hashing power is very remote.  You could attempt to gain remote control of pool servers but they tend to use proprietary implementations and reject incoming connections.  If you could compromise a single pool you probably couldn't compromise more than one and as members detected all the invalid blocks coming from a single pool you could expect to see the attached hashing power fall off rapidly (that assumes you could keep the admins from simply shutting down the pool).

I'm not talking about a deliberately trojaned client.  I'm talking about a defect in the software that allows remote control to be taken by an attacker.  Such bugs are discovered from time to time in most network programs.  Google for "X remote vulnerability" where X is openssh, apache, sendmail, bind, or whatever.  Ask a professional sysadmin, and they will tell you that the bitcoin software would be very unusual indeed if it were exempt from such bugs.

arent many clients opensource? So what would the worry be? If most people are using the official client then your concerns shouldnt be valid I would think.

I haven't so far seen any good descriptions of what attacks might be possible on the bitcoin network given a serious implementation bug in the client.  There has been much discussion of whether the design of the protocol is secure, but no real treatment (that I've seen) of the possible impact of an implementation bug in a widely used client.  This is particularly relevant when a single implementation accounts for most deployments, as is currently the case with bitcoin.

Most people are familiar with the characteristics of a "51% attack": the attacker needs to control a large proportion of the total hashing power; the higher the proportion they control, the more likely is their success; apparently non-mining nodes do not play a part in prevention of such attacks.  I wonder whether all possible attacks (on the network / blockchain as a whole) due to implementation bugs share these characteristics, or whether some of them are different in nature.

If we assume that an attacker is able to exploit a bug in the most widely used client that allows them to execute arbitrary code, what kinds of attacks might they be able to mount on the network as a whole?  I am not looking for "they could read any wallet data the client has access to and send it to the attacker" - that much is obvious, even to me.  I am looking for attacks that threaten the integrity of the blockchain.

Intuitively, having multiple independently developed implementations of the protocol in use would mitigate against such risks, but what are the details of this mitigation?  Would it still be good mitigation if lots of clients (say 70% of the total) used a mixture of various alternative implementations, but these clients only represented a tiny proportion of the network's hashing power (say 0.1%)?  What proportion of the total number of nodes (or total hashing power, as may be) would need to be using a single client in order for exploitation of a single implementation bug alone to seriously threaten the integrity of the blockchain?  What might the messages through the network look like during successful thwarting of such an attack from alternative implementations having been widely adopted?

Looking forward to hearing the experts' take on these questions.