I won't blame Greg for the
@Peter Tschipper 's recent bug as I think that would be unfair.
However there are things to consider when you look at this calmly:
- If the preliminary analysis from yesterday is correct, ptschip basically made the same mistake twice. He assumed a certain behavior of assert(..) (a well-known C/C++ function with a standard behavior) to not matter in RELEASE builds (when you make the software and release it to the whole world) but only to be active in DEBUG builds (when you are testing the code). This is the STANDARD behavior.
- Greg Maxwell in 2013 changed Bitcoin so that all asserts happen as if they would in DEBUG builds. There are (somewhat) valid reasons to do this, but it is more a 'hot fix' and if he would have done it the right way, he would have deprecated and removed assert(..) altogether from the code and replaced it with an explicit function, like "fail_if_not(..)". It is basically a psychological issue here, like so much is in programming: People blackbox certain behavior, assume standard behavior, and then it is super-easy to fall into the trap that non-standard behavior can cause.
This is also a fine example on the kind of 'special Bitcoin knowledge' and barrier to entry Core amasses by introducing non-standard quirks into the Bitcoin code or build process.
As it was done by Greg back in
2013, I do not want to assume malice here.
But again, I do think it is a fine example of the kind of uphill battle that results from these kinds of changes.
And I do want to state that, although BU owns the actual bug, Core owns the culture and the idiotic assert policy that made this bug possible in the first place.
- I said after the last bug to have a closer look at all assert()s, especially those in BU. I am sure others said and thought the same. I am also sure that our devs started to look into exactly that. However,
this takes time. Our enemy (and I think it is unfortunately 100% correct to call them that at this stage) likely prepared a whole string of exploits along the above assert(..) The only good thing is that they'll eventually run out of those. Bugs in stable code are a finite 'resource'.
Last but not least, I am thankful for our devs and I can see the immense pressure that they are under now.
I said that BU started with somewhat of a Cowboy mentality ('move fast') when it came into being - also somewhat out of necessity. From my casual glances at the current code, I have to say, however, that indeed quite a lot of work was done to clean up the code by our team (both on BU and Core parts) and I think everyone is taking the right approach now.
