By full-disclosure standards this is actually old news; I disclosed itsemi-publicly to the Bitcoin developers about a month ago and theycommitted a fix back then, and there's even been a Bitcoin release0.5.2 since then which includes the fix (though only because one ofthe other developers stubbornly insisted on creating a bugfix releasefor other reasons - the head developer was strongly against it). Allprevious 0.5.x releases were vulnerable and 0.6 hasn't been releasedyet. I only just got around to looking into how the vulnerability gotin originally though and it doesn't appear anyone's really talkedabout it.

This isn't a formal advisory either, more an example of how avulnerability can easily be introduced by a seemingly innocuous commitand why the Bitcoin code needs more scrutiny.

More important than the flaw itself, is that it perhaps suggests that code changes are being made without proper review. I'd prefer to see a more conservative approach even if it meant a much slower development cycle.

More important than the flaw itself, is that it perhaps suggests that code changes are being made without proper review. I'd prefer to see a more conservative approach even if it meant a much slower development cycle.

Actually there is. I pointed this out to Gavin months ago in private chat but he disagreed with me. I still don't think the change was a good one. You don't comment out 2 lines of code because it produces a 6 hour speedup. The proper way is to restructure the code nicely but that takes more effort.

More important than the flaw itself, is that it perhaps suggests that code changes are being made without proper review. I'd prefer to see a more conservative approach even if it meant a much slower development cycle.

Actually there is. I pointed this out to Gavin months ago in private chat but he disagreed with me. I still don't think the change was a good one. You don't comment out 2 lines of code because it produces a 6 hour speedup. The proper way is to restructure the code nicely but that takes more effort.

yet the vulnerability still slipped in and had to be fixed later - if there were any question marks over any changes should there not be a much more thorough review before accepting the change?

By full-disclosure standards this is actually old news; I disclosed itsemi-publicly to the Bitcoin developers about a month ago and theycommitted a fix back then, and there's even been a Bitcoin release0.5.2 since then which includes the fix (though only because one ofthe other developers stubbornly insisted on creating a bugfix releasefor other reasons - the head developer was strongly against it). Allprevious 0.5.x releases were vulnerable and 0.6 hasn't been releasedyet. I only just got around to looking into how the vulnerability gotin originally though and it doesn't appear anyone's really talkedabout it.

This isn't a formal advisory either, more an example of how avulnerability can easily be introduced by a seemingly innocuous commitand why the Bitcoin code needs more scrutiny.

More important than the flaw itself, is that it perhaps suggests that code changes are being made without proper review. I'd prefer to see a more conservative approach even if it meant a much slower development cycle.

just do like me and wait some time b4 upgrading to the latest versions

A powerful attacker could definitely exploit this; timestamps in thefuture are rejected and Bitcoin won't generally accept a version ofhistory in which time goes backwards, but otherwise a 51% attacker canchoose whatever timestamps they like and can delay releasing theirversion of the chain to meet the "less than 10 seconds" requirement.It's a very expensive attack but far from impossible.

Yeah. Like this wouldn't be a huge arrow pointing directly at the attacker. No one is going to notice a 144+ block reversion of the chain. Right.

Still, looks like another case where my exponential difficulty requirement for blockchain reorganization idea would come in handy. It would kill any and all offline mining attacks.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8 I routinely ignore posters with paid advertising in their sigs. You should too.

Still, looks like another case where my exponential difficulty requirement for blockchain reorganization idea would come in handy. It would kill any and all offline mining attacks.

is there any reason why this wouldn't be implemented?

Ahh. The fine print...

Turns out that no one is exactly sure what would happen in a few cases. I have a rough understanding of what would happen most of the time, but nothing formal. It is possible for sections of the network to become permanently diverged from the rest of the world, but the amount of time needed for that to happen depends very much on the size of the section that gets disconnected. For example, if the network was split into two halves (by mining power) they could become irreconcilable in a relatively short time, like a few hours. But who wouldn't notice the hashing power dropping by 50%? A smaller split is less likely to be noticed, but will take longer to get screwed. A solo miner that finds a block every month would need a year or more to get hopelessly wedged, and if he doesn't notice that he is really solo for that long, it is his problem. (The exact times depend on the parameters of the exponential system.)

And it would complicate things if we ever needed to fix a bug like the signed/unsigned thing from a while back. Right now, if a major bug is found, and it takes a day or two to get a fix made, as long as most of the mining pools get together, they can overtake the buggy chain and restore order to the entire network. Under the exponential plan, each node would require human intervention unless the fix was found rather quickly. I think that this will gradually become less of an argument as alternate clients gain popularity. Once the monoculture gives way to the ecosystem, it simply won't be possible to do fixes in that way anyway.

Oh, and then there is the issue of starting up. An attacker that can control which blocks a new node gets during the download can prevent it from ever meeting up with the rest of the network. But there is no reason for a new node to be using the exponential system during the initial download anyway, so that isn't much of an issue in reality.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8 I routinely ignore posters with paid advertising in their sigs. You should too.