Hacker News Reader

Comment by johnsoft | Hacker News Reader

You would need to find a very localized, specific class of bug in a piece of software that has been highly scrutinized over many years by cryptography and security experts who know there are millions of dollars at stake, and this bug would need to affect parts of the P2P network but not others, keeping in mind everyone voluntarily chooses which software to run. I think calling it "relatively easy" is a bit of a stretch.

View on HN

  You would need to find a very localized, specific 
  class of bug in a piece of software that has been 
  highly scrutinized over many years by cryptography 
  and security experts

Couldn't you monitor the version control system trunk for patches fixing bugs in the critical section of the code, work out the bug based on the fix, and exploit it before everyone had their systems patched?

  everyone voluntarily chooses which software to run.

In things like operating systems heterogeneous software is often seen as a defence against bugs - but in this instance, wasn't it the differences between the 0.7 and 0.8 clients that triggered the split in the blockchain?

Surely the most secure thing is to be on the most widely used client?

Clients emit a warning in the GUI (and IIRC disable the RPC interface, which would be the fail-safe for merchants) when this kind of issue is detected (namely, conflicting blockchains of significant length received from different peers). So the most secure thing would be to be connected to a high diversity of peer nodes, and to pause transaction processing and check the news when you get a warning.

When I say relatively easy, I mean compared to the prevailing wisdom that causing a fork requires controlling 51% of the total bitcoin mining capacity.

Also, it doesn't need to be a crypto failure. Just a divergence of the clients on how they handle the protocol. Possibly a discrepancy that would be very unlikely to occur by chance or in testing, and only manifests itself when a malicious user triggers it. This is the threat model bitcoin has to worry about now...

You claim it is hard to do. However it accidentally happened recently. So it can't be that hard.

After all, if all "security experts" are so good, why didn't they catch the recent fork?

They didn't catch this because it wasn't a bug in the client code itself, rather it was a bug in a third-party library, which is currently being migrated away from. Further (as far as I'm aware) it's only happened by chance, never deliberately by a malicious entity.

Well it happened, with a simple decision to switch from BerkeleyDB to LevelDB. Luckily no-one malicious discovered it first, and it got fuzz'ed out.

Reply on news.ycombinator.com