"But heres the question: how long would it take for governmental bureaucracy to amass the resources to execute such an attack without raising a flags from other nodes who then will take proactive measures to not only mitigate such attacks but also alert others nodes on the network?"
Do you really thing that purchasing a hundred million dollars worth of ASICs would alert anyone? The government spends far more than that in a given year, and there are government agencies that are good at keeping secret operations of that size secret. I would not rely on the inefficiency of bureaucracy when it comes to equipment procurement, certainly not as a security measure.
Also, what exactly would the honest nodes do to mitigate the attack? They can only buy more computing power to try to maintain control of the block chain. That is the real problem here: the effort needed to run the Bitcoin network is proportional to the effort needed to attack the system.
"It's trivial for an attacker to fill the network with clients controlled by him. This might be helpful in the execution of other attacks.
For example, an attacker might connect 100,000 IP addresses to the IRC bootstrap channel. You would then be very likely to connect only to attacker nodes. This state can be exploited in (at least) the following ways:
The attacker can refuse to relay blocks and transactions from everyone, disconnecting you from the network.
The attacker can relay only blocks that he creates, putting you on a separate network. You're then open to double-spending attacks.
If you rely on transactions with 0 confirmations, the attacker can just filter out certain transactions to execute a double-spending attack.
Low-latency encryption/anonymization of Bitcoin's transmissions (With Tor, JAP, etc.) can be defeated relatively easy with a timing attack if you're connected to several of the attacker's nodes and the attacker is watching your transmissions at your ISP.
Bitcoin makes these attacks more difficult by only making an outbound connection to one IP address per /16 (x.y.0.0). Incoming connections are unlimited and unregulated, but this is generally only a problem in the anonymity case, where you're probably already unable to accept incoming connections.
Looking for suspiciously low network hash-rates may help prevent the second one.
"
One could even go further to do signal analysis on the network looking for nodes whose hash rates are more similar than others and hash rates per period of time (which will happen if such a large scale operation were in process), point them out to other nodes, and require that that node verify themselves with information which could allow for an independent audit by others before unflagging the node(s) in question.
EDIT: if anyone is interested in possible working on an open source project for rogue node mitigation that miners can install on their rigs, im game :P besides i think it would be more fun than going solo with my algos on the BTCUSD cross exchanges :P
Comments
"But heres the question: how long would it take for governmental bureaucracy to amass the resources to execute such an attack without raising a flags from other nodes who then will take proactive measures to not only mitigate such attacks but also alert others nodes on the network?"
Do you really thing that purchasing a hundred million dollars worth of ASICs would alert anyone? The government spends far more than that in a given year, and there are government agencies that are good at keeping secret operations of that size secret. I would not rely on the inefficiency of bureaucracy when it comes to equipment procurement, certainly not as a security measure.
Also, what exactly would the honest nodes do to mitigate the attack? They can only buy more computing power to try to maintain control of the block chain. That is the real problem here: the effort needed to run the Bitcoin network is proportional to the effort needed to attack the system.
This goes into cancer nodes: https://en.bitcoin.it/wiki/Weaknesses#Cancer_nodes
"It's trivial for an attacker to fill the network with clients controlled by him. This might be helpful in the execution of other attacks. For example, an attacker might connect 100,000 IP addresses to the IRC bootstrap channel. You would then be very likely to connect only to attacker nodes. This state can be exploited in (at least) the following ways: The attacker can refuse to relay blocks and transactions from everyone, disconnecting you from the network. The attacker can relay only blocks that he creates, putting you on a separate network. You're then open to double-spending attacks. If you rely on transactions with 0 confirmations, the attacker can just filter out certain transactions to execute a double-spending attack. Low-latency encryption/anonymization of Bitcoin's transmissions (With Tor, JAP, etc.) can be defeated relatively easy with a timing attack if you're connected to several of the attacker's nodes and the attacker is watching your transmissions at your ISP. Bitcoin makes these attacks more difficult by only making an outbound connection to one IP address per /16 (x.y.0.0). Incoming connections are unlimited and unregulated, but this is generally only a problem in the anonymity case, where you're probably already unable to accept incoming connections. Looking for suspiciously low network hash-rates may help prevent the second one. "
One could even go further to do signal analysis on the network looking for nodes whose hash rates are more similar than others and hash rates per period of time (which will happen if such a large scale operation were in process), point them out to other nodes, and require that that node verify themselves with information which could allow for an independent audit by others before unflagging the node(s) in question.
EDIT: if anyone is interested in possible working on an open source project for rogue node mitigation that miners can install on their rigs, im game :P besides i think it would be more fun than going solo with my algos on the BTCUSD cross exchanges :P