6 ms·

In this kind of blockchain network, the longest chain of blocks is considered to be the valid one. However, someone that has 51% of the hashing power (i.e. mor

by bonyt 8y ago

In this kind of blockchain network, the longest chain of blocks is considered to be the valid one. However, someone that has 51% of the hashing power (i.e. more hashing power than everyone else combined) can create a chain that grows faster than the chain used by everyone else. This means that they could tamper with their chain, potentially rewriting history on it, and because it is the longest chain, it will be accepted as the valid chain, and their version of events looks like it has been accepted.

orblivion 8y ago
Being only somewhat familiar, I wonder this: Why don't clients have a simple rule against accepting changes to history that are more than one or two blocks old?
- wmf 8y ago
  Those rules can cause breakage under normal usage because the probability of an N-deep reorganization is low but nonzero. They also don't help nodes that are syncing the chain from scratch.
- leevlad 8y ago
  Because it's an eventually consistent system. If what you proposed was implemented, you could end up with a fork that would never get reconciled.
- makomk 8y ago
  In short, because they don't know that the chain they saw first is the chain that other nodes saw first (especially if they weren't online at the time). At least in theory, an attacker can exploit this to permanently fork the chain.
  - orblivion 8y ago
    Hmm. The humans at the exchanges seem to be able to tell the difference. I wonder if it could be encoded.
    - AgentME 8y ago
      The "legitimate" fork can only be identified if you were online when the 51% attack started. Users who have started up their ETC client after the attack started will just see two forks and will pick the one with more blocks (which will be the 51% attacker's fork). No one wants a permanent fork, so the clients that were online the whole time disregard their knowledge of the previous "legitimate" fork and adopt the attacker's fork because it has more work and because that's the one everyone else is using. Also, if you have clients follow the rule "never switch forks" to protect against 51% attacks, then any network partitions will cause a permanent fork.
    - leevlad 8y ago
      I don't think that's feasible, to be honest. I'd imagine that you would want to look for evidence of a double spend as that's the most likely goal of a 51% attack. But then the blockchain must have up-to-date knowledge of likely double spend targets (such as exchanges, OTC desks, etc), and be able to algorithmically and deterministically prove malicious intent with high certainty. Only then will you be able to maintain consensus and prevent unnecessary or accidental forks. But since this is all open-source anyway, it would only be a matter of time before a slightly more sophisticated attacker read through the updated consensus algorithm and figured out how to game it. And so the cycle continues. In truth, the only real strategy for mitigating attacks in PoW blockchains is hash power. It has proven to be very effective if you have enough of it (see BTC), and looking for other 51% resistance measures isn't really that productive unless you start from the ground up and rebuild the consensus mechanism on a different paradigm (e.g. PoS, which is still unproven afaik).
- CydeWeys 8y ago
  Because then a simple accidental network partition could cause a permanent fork in the cryptocurrency.
- pryce 8y ago
  Other people have answered this from a more technical perspective. Philosophically, what the distributed blockchain is, is an agreement for adjudicating whose record (eg list of transactions) should be agreed on as "the valid one". If you already have a different, reliable external way of deciding this question, that is (arguably) conceding that you didn't need a distributed blockchain in the first place. EDIT: I've realised my comment could be misinterpreted as endorsing the blockchain 'movement'. I am among those who are quite skeptical of these many blockchain projects.
  - orblivion 8y ago
    What I described would be part of the rules of system (or at least certain players). It just says "no changing history after X point". If anything, relying on an outside source is what we're doing now. Coinbase and others are telling us that they detected something and I haven't heard anybody question them. (And I'm assuming they're not lying). Though that's not to say the blockchain will be changed by this information.
    - pryce 8y ago
      > If anything, relying on an outside source is what we're doing now. You are correct of course. To me, problems like this recent attack highlight an inherent contradiction in the blockchain idea - that the "51%+ of hashing power determines the truth" rule is really either lip-service; techno-marketing vanity that doesn't actually translate to practice (if corrective action ensues), and in which case the adjudicator is clearly not the blockchain tech we were told, but instead a nebulous collection of companies and stakeholders OR - that "51% determines the truth" is indeed a strictly-held principle even though we have already demonstrated that there exist actors with enough resources and motivation to make attacks of this nature on some of the most prominent blockchain projects already - and we haven't even yet witnessed what a 51% attempt by an actor with the resources of a state would look like. This is one of the reasons I have become skeptical of blockchain projects.
  - hinkley 8y ago
    > I am among those who are quite skeptical of these many blockchain projects. There's always dilution when an idea has been around long enough and I'm concerned about the copycats trying to use blockchain for other things. If Raft is democracy, then blockchain is Might Makes Right. The guy with the biggest stick always wins. There is no actual vote. Everybody is an accomplice. That doesn't sound like progress, that sounds like regression. A really big one.
- stale2002 8y ago
  Some clients do have this rule, actually! It is a pretty interesting solution, that seems to work out OK. For example, most Bitcoin cash clients don't accept reorgs longer than 10 blocks, as such a reorg is 100% an attack. This protects the network against large reorgs.

by bonyt 8y ago

orblivion 8y ago

Being only somewhat familiar, I wonder this: Why don't clients have a simple rule against accepting changes to history that are more than one or two blocks old?

wmf 8y ago
Those rules can cause breakage under normal usage because the probability of an N-deep reorganization is low but nonzero. They also don't help nodes that are syncing the chain from scratch.
leevlad 8y ago
Because it's an eventually consistent system. If what you proposed was implemented, you could end up with a fork that would never get reconciled.
makomk 8y ago
In short, because they don't know that the chain they saw first is the chain that other nodes saw first (especially if they weren't online at the time). At least in theory, an attacker can exploit this to permanently fork the chain.
- orblivion 8y ago
  Hmm. The humans at the exchanges seem to be able to tell the difference. I wonder if it could be encoded.
  - AgentME 8y ago
    The "legitimate" fork can only be identified if you were online when the 51% attack started. Users who have started up their ETC client after the attack started will just see two forks and will pick the one with more blocks (which will be the 51% attacker's fork). No one wants a permanent fork, so the clients that were online the whole time disregard their knowledge of the previous "legitimate" fork and adopt the attacker's fork because it has more work and because that's the one everyone else is using. Also, if you have clients follow the rule "never switch forks" to protect against 51% attacks, then any network partitions will cause a permanent fork.
  - leevlad 8y ago
    I don't think that's feasible, to be honest. I'd imagine that you would want to look for evidence of a double spend as that's the most likely goal of a 51% attack. But then the blockchain must have up-to-date knowledge of likely double spend targets (such as exchanges, OTC desks, etc), and be able to algorithmically and deterministically prove malicious intent with high certainty. Only then will you be able to maintain consensus and prevent unnecessary or accidental forks. But since this is all open-source anyway, it would only be a matter of time before a slightly more sophisticated attacker read through the updated consensus algorithm and figured out how to game it. And so the cycle continues. In truth, the only real strategy for mitigating attacks in PoW blockchains is hash power. It has proven to be very effective if you have enough of it (see BTC), and looking for other 51% resistance measures isn't really that productive unless you start from the ground up and rebuild the consensus mechanism on a different paradigm (e.g. PoS, which is still unproven afaik).
CydeWeys 8y ago
Because then a simple accidental network partition could cause a permanent fork in the cryptocurrency.
pryce 8y ago
Other people have answered this from a more technical perspective. Philosophically, what the distributed blockchain is, is an agreement for adjudicating whose record (eg list of transactions) should be agreed on as "the valid one". If you already have a different, reliable external way of deciding this question, that is (arguably) conceding that you didn't need a distributed blockchain in the first place. EDIT: I've realised my comment could be misinterpreted as endorsing the blockchain 'movement'. I am among those who are quite skeptical of these many blockchain projects.
- orblivion 8y ago
  What I described would be part of the rules of system (or at least certain players). It just says "no changing history after X point". If anything, relying on an outside source is what we're doing now. Coinbase and others are telling us that they detected something and I haven't heard anybody question them. (And I'm assuming they're not lying). Though that's not to say the blockchain will be changed by this information.
  - pryce 8y ago
    > If anything, relying on an outside source is what we're doing now. You are correct of course. To me, problems like this recent attack highlight an inherent contradiction in the blockchain idea - that the "51%+ of hashing power determines the truth" rule is really either lip-service; techno-marketing vanity that doesn't actually translate to practice (if corrective action ensues), and in which case the adjudicator is clearly not the blockchain tech we were told, but instead a nebulous collection of companies and stakeholders OR - that "51% determines the truth" is indeed a strictly-held principle even though we have already demonstrated that there exist actors with enough resources and motivation to make attacks of this nature on some of the most prominent blockchain projects already - and we haven't even yet witnessed what a 51% attempt by an actor with the resources of a state would look like. This is one of the reasons I have become skeptical of blockchain projects.
- hinkley 8y ago
  > I am among those who are quite skeptical of these many blockchain projects. There's always dilution when an idea has been around long enough and I'm concerned about the copycats trying to use blockchain for other things. If Raft is democracy, then blockchain is Might Makes Right. The guy with the biggest stick always wins. There is no actual vote. Everybody is an accomplice. That doesn't sound like progress, that sounds like regression. A really big one.
stale2002 8y ago
Some clients do have this rule, actually! It is a pretty interesting solution, that seems to work out OK. For example, most Bitcoin cash clients don't accept reorgs longer than 10 blocks, as such a reorg is 100% an attack. This protects the network against large reorgs.