3 ms·

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 secur

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.

w-ll 14y ago
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.
platypii 14y ago
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...
michaelt 14y ago
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?
- johnsoft 14y ago
  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.
rmc 14y ago
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?
- johnsoft 14y ago
  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.

w-ll 14y ago

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.

platypii 14y ago

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...

michaelt 14y ago

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?

johnsoft 14y ago
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.

rmc 14y ago

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?

johnsoft 14y ago
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.