Sorry I haven't replied. Yeah for sure, I think deregulating ISPs would allow them to have a lot more control over the cryptocurrencies running over the internet
Although I think net neutrality isn't that great either, it's just preferring companies like Netflix over ISPs. Taxpayer money went into developing the technology at DARPA, but then we just pass it along to private companies to profit from, instead of having it structured like a public utility
Now we have soft forks, hard forks and MALICIOUS FORKS.
Of course the principle is applicable to any open blockchain. Attacks will be potentially profitable for any distributed blockchain dealing with items of value. This could be stock and shares or commodities. The attack only needs to delay real time information for profit in these kinds of situations and, as the article says, a lot of this will pass under the radar as assumed random delays or glitches.
Is this another chapter for /u/dgerard on Blockchain vulnerabilities ? Any comments, David?
This is actually old. It's a theoretical attack, but I doubt it'd be a practical one:
1. Nobody cares about bitcoin, particularly ISPs.
2. Messing with the BGP tables gets your fellow Internet providers very pissed off at you. The networking at that level is run by the sort of engineers who consider the network important public infrastructure that *you do not fuck with*.
You'd need a state-level actor to want to force this upon ISPs. Maybe China. But even then, they don't actually care about Bitcoin much.
There are three issues here: Is it possible to force certain mining nodes off the network (partition the hash power)? Is it possible to fool a user into accepting the wrong chain? Is it possible to fool a user into getting old data?
First: when it comes to the miners, the good news is that there are few mining pools and they are interconnected in various ways. There can be private connections that aren't generally visible, making it difficult for an attacker to partition the miners.
Second, when it comes to fooling people as to the wrong chain. This depends on how one's code works and how one thinks the protocol evolves. If one believes the philosophy that there is one set of rules put out by a central authority, then one needs the entire contents of the blockchain to avoid being fooled. (Under this philosophy one can not reasonably trust an SPV client.) If one believes the philosophy that the longest chain defined by hash power rules, then one needs very little data to tell whether one is on the correct chain, albeit not necessarily up to date. All that is needed to detect a spoof attack is a single 256 block hash. It would not be very difficult to broadcast this information widely, effectively defeating this spoof attack.
Blocking access to the blockchain or other denial of service attacks is part and parcel of the Internet. A business can be taken off line by taking its web site down or by cutting off ability to accept payments from Visa, Paypal or Bitcoin. Nothing new here. If one keeps one's own private keys safe then the worst that will happen is that one will miss new payments or confirmation thereof.
If one uses level 2 networks such as LN or middlemen such as Bitcoin exchanges, then DoS attacks could definitely cause losses. DoS attacks cause business and trading losses with other payment systems. Nothing new here. But this does illustrate why level 2 networks that use timers are not as safe as Bitcoin.
I don't see how either attack vector could be successful.
Due to the meshed nature of the Bitcoin network, it's highly unlikely that an attacker could pull off scenario 1. Even with 60% of Bitcoin traffic traversing 3 ISPs, block relay information would propagate via other routes and would quickly lead to short orphaned chains and reconvergence via other paths.
An attacker would need to completely isolate part of the network to have any success.