|
|
|
|
|
|
by feichtinger
4360 days ago
|
|
|
Thanks for taking the time to read through! The wording on that could be improved a little because there's a bit of a distinction between total computing power and number of nodes. It's a proven result that in asynchronous systems with potentially malicious nodes, 1/3 is the maximum number of faulty replicas that can be tolerated. Here's a paper with a proof: http://zoo.cs.yale.edu/classes/cs426/2012/bib/bracha85asynch... Bitcoin mixes things up a bit by also taking into account total computing power, but is still vulnerable to attacks where more than 33% of nodes are controlled, like selfish mining: http://hackingdistributed.com/2013/11/04/bitcoin-is-broken/ If more than 33% of nodes are compromised at the same time the good nodes will not accept bad transactions, they will simply wait until the consensus pool is fixed or removed and then continue normally. Of course, with enough nodes it should be very unlikely for an attacker to get control of that many nodes at once. |
|
|
I wouldn't bet on it. Look at the warnings that have gone out about the last couple of Rails RCE vulnerabilities: attackers can scan the entire Internet for vulnerable apps in a faster time than many sysadmins can get the upgrade deployed. Now, imagine this: a potential attacker, ahead of time, finds a way to reliably remotely fingerprint the version of Rails you've released as hyperledger. One scan later, they're sitting on a list of the IP addresses of some large proportion of hyperledger installs. All they now need to do is wait for the right vulnerability to be announced (or find it themselves), and then it's a race to gain control before a) the Rails team publishes a patch, b) you release a new version of hyperledger with the patch applied (or can announce that the patch doesn't break things via a gem upgrade), c) more than 66% of the sysadmins jump on the announcement. In the time for a), b) and c) to happen, they need to i) run a single exploit, and ii) simultaneously generate a bad transaction, across the servers they now control.
a), b), and c) are humans. i) and ii) are a for loop in a single bash script. That's not a race I'd want to be on the wrong side of.