This matter was apparently for the first time discussed here, which is in itself ridiculously late, but the recent events illustrate the need of having the various issues much more clearly delineated.

Recently Bitcoin came close to unmitigated disaster, in the following way: Gavin diplomatically suggested that miners increase their block size, from the previous magic number of "250k" to something they themselves pick. This approach is flawed: the solution to the problem of having a magic number in the code is not passing the responsibility of choosing it to a larger group. It may work politically, in the sense that where large, vague groups are responsible for a bad move nobody will ever be hung. It does not work practically.

This point does not begin to get sufficient emphasis: stop thinking politically, stick to thinking practically. The political importance, usefulness or competence of a dev is nil. This is not your job, and more importantly this is one of the things you suck at the most. A casual skim through the -dev sessions is ample proof for this, more ridiculous dickwad posturing and knowshitism has never before been seen (outside of the mailing lists of some meanwhile failed open source projects). Snap out of it. Stick to writing code.

But we digress: as a result of a number of miners implementing their own version of a magic miner, a number of large blocks were created and mined by them, as long as they ran 0.8. Miners running 0.7 failed to mine these same blocks, and a fork developed.

The reason is that Bitcoin code sucks. It's not that "the blocksize", it's not that "the database", it's not that "nobody could have foreseen their using a plane like a rocket". That shit does not belong in this discussion, passing the buck is not and cannot be accepted in Bitcoin. The reason is that Bitcoin code sucks, and Bitcoin code sucks because people want to be Bitcoin devs, people want to call each other Bitcoin devs, people want to participate in idle irc chatter as if they in fact were Bitcoin devs, but those same people do not have either the ability or intellectual resources to write dependable, usable, good, clean code.

This is a problem, and this problem needs to be resolved, preferably by the people who are causing it. You know yourselves, I won't name and shame. Fix your heads. You won't be getting much more warning.

Today will go down in history as the day when Bitcoin nearly died, and its fate depended on BTC-Guild staying online. Stop and think for a minute. What are you doing here? Why are you here, really?

Likewise, misterbigg.

What doesn't kill you makes you stronger.

Considered, yes. One problem is the centralization issue stemming from that approach. The one correct way to handle Bitcoin development is exactly as designed: independent devs doing it. The problem is that instead of doing it they spend their time opining on things that utterly ain't their business.

Devs handled this like fucking pros. Bullish for bitcoin.

Damn, you had to be the one to bring the bad news... 

Be back in a minute, have to patch some software.

Another way to state the real problem: There is no Bitcoin Protocol Spec, most semantics buried in the hairball of the C++ reference implementation

And?

If you say you know what the problem is, and have the ability to correct it, why complain about it unless you're going to do something?

Then you should develop your own cryptocoin with code that even a blind man could read. It sounds like you already have it figured out.

This is an experiment. Something like Bitcoin has never been done before. I don't recall getting any guarantee when I got my coins or sent transactions, do you?

On 2011 an external factor made Bitcoin nose dive...... Imagine what would happen this time.... Don't kid yourselves like some people in the IRC room. This is the biggest problem Bitcoin ever faced and it is waaaaay bigger than the MTGox. hack.

I am not pulling out I am just pissed off Bitcoin will suffer greatly because the DEVS MADE A MISTAKE! you dont freaking PUSH such things without proper testing. EVER HEARD OF TESTNET!!!!!!

The whole attitude of only having a single full implementation.  

No cause we're too cool for testnet and elbow grease, gotta spend 16 hours a day on -dev talking about what we think of Satoshi Dice and how many whales fatass Gmaxwell could swallow whole.

Yes.  This will be the death of Bitcoin.  When a fully specified crypto currency comes along, it will leave Bitcoin behind.  "The implementation is the protocol specification" is wrong, and at Internet scale it is very wrong.

That and the fact that we didnt even have an emergency plan for things like this, everyone just meeting in irc and it even took like 30mins for the first forum thread to show up. What a joke.

But then, i dont blame the devs, they are doing a great job, maybe we just need more people working on it?
I would have no problem paying like 1% of my Bitcoin earnings as donation to people working on Bitcoin.

Right now there's no question that they deserve to be called idiots. What's happening now was easily preventable and shouldn't have ever happened under any circumstances.

You're either a jackass braying by the side of the road or you're fixing the jackass's wagon. Which one are you?

Except for the integer overflow bug and all those CVEs, sure.  You can't even say "this is the first prolifically visible major bug in 4 years" as the integer overflow bug holds that title.

Actually, to be more precise: this is a major bug rather than yet another opportunity for the disgusting circlejerk of patting each other on the back precisely because I said something.

I don't care and I don't want to hear stupid stories and even more stupid justification. This sort of incompetence is not acceptable for a half billion dollar thing.

If you earnestly believe this is the best you can do, leave.

ladies and gentlemen:

this is why the "bankers" make a LOT of money. they are EXTREMELY good at what they do and WAY more money is on the line every hour vs what bitcoin deals with in a year.

Manipulate governments and markets, spread disinformation through the media and rig the currency to their benefit?

Ya, bankers are experts.

That's not how it works. If you don't think it's acceptable, you either help fix the problem (something tells me you're not up to that) or YOU leave. If you think the devs are idiots, then I guess the biggest idiot is you, for investing in their work. Toodles.

Won't work. All the 0.7 bitcoind node would have seen your previous transaction and would reject the new one. And some people here call the bitcoin devs idiots? They don't even know how the network works.

And true engineers in computer science know that no amount of inspection and testing is enough when you want something perfect. Lookup "formal verification" and see for yourself that nobody gives any guarantee in the software industry because it would be so damn costly.

And the REASON it was neither detected nor reported is that some idiots THOUGHT it was a good idea to come up with a magic number and limit everything to 250k.

Just as SOMEONE thought it was a good idea to run Bitcoin with a plaintext wallet for 2 years.

The difference between the former and the latter is that I didn't say anything then, because back then nobody of any consequence gave two shits about your little bullshit project here.

And in fact, you probably to this day think running the wallet plaintext was ok.

Reality check. Seriously.

You know what, talk is fucking cheap. You can bitch all day, or you can put some resources into pushing forward this little experiment of ours. You think the code sucks, or that there are painfully obvious flaws like unencrypted wallet files that go unaddressed for way too long? Fix it.

It's completely open.

Stop bitching, and fix it.

Yeah but apparently bitcoin millionaires cannot afford to get test suites made so it kind of sits there waiting for hard working coders and developers to find some spare time to work on such things.

-MarkM-

I was here and there on IRC and since the storm started to settle and I started to really look at things the way they are without the nervousness.

I would like to apologize to you all. Especially the devs, They did good and saved the day. thank you. And I am sorry for calling you idiots. You rock. Keep it up 

Yes, you can surmise exactly that. IT IS MY JOB. I AM DOING MY JOB.

Guess who isn't, and guess what that makes them.

Maybe you should just be quiet until the grownups fix your toy.

Yeah, I know what you mean... your website have been down for weeks now

I am not under any suck mistaken impression. Please read what's actually being said, it will help.

The presence of a 250k arbitrary block limit prevented the underlying problem of the db from being discovered until that moment when a perfect storm composed out of a db upgrade and the limit removal created two almost equal miner bases. This could have easily been avoided by simply not relying on magic numbers. It will ever be the case that whenever code contains arbitrary numbers based on arbitrary assumptions that code will break spectacularly.

Maybe it wasn't the size of the block that was the problem.

https://bitcointalk.org/index.php?topic=152131.msg1614374#msg1614374

That one requires more explanation for sure. What exactly?

That is not correct.  v0.7 nodes accepted a 1MB block on testnet.  The issue was more complex then just the size of the block.  By the protocol the block which was rejected by some nodes SHOULD have been accepted.  The 250kb soft limit was simply a default for block construction.  Even with it in place nodes should have accepted properly constructed blocks up to the 1MB limit.  It also appears not all v0.7 nodes were affected.  Some accepted the problem block and some didn't.  The defect/limit in BDB wasn't documented and didn't occur in all versions/platforms.   It appears the number of transactions being changed as a result of the block validation crossed some "magic code" not in the Bitcoin source code but undocumented in some implementations of BDB.

v0.7 reliance on BDB caused it to be fundamentally broken/flawed. Its actions weren't consistent with the documented protocol, the higher level source code, or anyone's understanding/expectation of what should have happened.   Nobody was saying/thinking oh yeah if you make a block with more than x transaction it will abort, cause a rollback, and result in a rejection.  It was a landmine.  

Does this not argue for a diversity of implementations with different underlying 3rd party libraries ? Clearly it does. But this cannot happen until and unless there is actually a formal-enough spec to enable those to be written w/o ever "groking" all that C++ folklore, which is a moving target anyways ...

I agree on that 100%.  It is inevitable that to survive Bitcoin will need to be move beyond a monoculture.  Right now all the clients share the same "DNA".  If there is a fatal genetic flaw in it then the network will not survive.   This time the "landmine" was accidental, next time it may be planted.

MPOE-PR, your attitude makes me sick.
You've been yelling and calling developers names without having even understood what the technical issue is.
You pretend you deserve a perfect codebase and do not even spend resources towards this goal.
My opinion it that your childish rants hurt good-willed and hard-working people.
If your job is politics, then my opinion is that you suck at that job, because bitcoin as a whole does not benefit from someone technically incompetent throwing random blame around.

I, for one, do want to give a bucket of congrats to the devs for all the work done so far and for the quick response to the current problem.

One thing is interesting in this thread, it's the need for a formal spec of the protocol. alexkravets nails it real good in his posts.

There is another 10+ hidden genetic flaws either in the C++ code itself or in one of the underlying libraries.

Imagine that next time instead of a fork split that can be healed, we end up leaking private key information through some side channel because of some bug in SSL libraries and the leakage gets embedded in the blockchain somehow ?

Such leakage cannot be repaired ... that will NOT be fixable and will simply lead to loss of confidence and extinction.

There's hundreds of deadly scenarios you can imagine here ...

Is anybody in the blessed circle of C++ magicians listening to this ?  

Bitcoin Foundation, is there any plan to extract the spec ?

Read up on http://en.wikipedia.org/wiki/Side_channel_attack ...

It is also a huge issue that those suggesting we need the protocol spec are brushed off with the "you don't get it" nonsense by elitist devs.
Bits and pieces, some expired, are scattered around Wiki. Is that the best we can do?
@MP: would you be willing to lead the effort of formulating the current protocol spec?

The spec should simply describe exact format and formal-enough semantics of all valid network messages.

That's it.  

Need examples of such specs ?

1. TCP/IP
2. HTTP/1.1 (with extensions)
3. TLS

etc.

This. So much this. Dublin Core and RDF/RDA container formats are excellent examples of standards that in all of their lenitive documentation provide an example of moving the database details out of the software implementation.

This idea is from an alternate world where you don't have to worry about breaking existing users' software and data to the point that they cannot spend their own money.

Bug-for-bug compatibility is not a choice made joyfully and willingly.

Engineers always prefer a clean slate, a clean interface.  That works here, only with a little help from science fiction's time machines.

jgarzik, i completely agree...i would be more inclined to take their criticisms seriously if they were actual contributors. but then again, i am not a contributor either (yet). Nevertheless, the core developers at least deserve the respect they've worked so hard to earn! None of this would even matter without them. i guess now is the time for the 'rats' to abandon ship, while the 'crew' works to right the ship and keep her afloat!

Thank you. I do not think I am actually far afield from Gavin, as I am pretty sure I have read him and/or other core devs discussing blockchain validator tools each of which would validate a certain range (by "height") of blocks.

In other words, no time machine going back and changing the historical past, just no repeating of the errors of the past in the future.

Basically the spec that tells us certain configurations, versions or implementations of BDB are not up to spec would be the spec for the new thing, the Real Bitcoin. The fact that the Satoshi node wasn't up to that spec gets enshrined not in the historically non-normative block-creation spec/code going forward but, rather, in the normative "validate a certain period of blockchain history's blocks" blockchain-checkers that I read some core devs discuss once upon a time.

An RFC could comment on details where certain builds of the Satoshi client on certain platforms failed to meet the new thing spec, and block heights could be targetted for the block height at which such builds will be orphaned, unsupported, deprecated, unable to function as part of "the Real Bitcoin" aka the new thing from that point on.

This is all old news / old ideas to Gavin et al I am pretty darn sure, which is why I am not in a panic over block sizes nor was in a panic yesterday evening over certain builds of Berkely DB on certain platforms in certain builds of the Satoshi node failing to perform to [ex]spec[tation].

So nyah nyah nyah circle jerk time group hugs for the geeks and techies, sorry if the PR folk aren't into that.

-MarkM-

You really, really don't get it. We can't have a protocol spec becasue the existing client has a whole bunch of unspecified and unintended behaviour that no-one knows about, and any divergence from that behaviour by any major implementation will result in fiascos like this one. This problem could just as easily have been caused by a independent third-party implementation of the client. The developers have been finding and documenting all the corner cases as thoroughly as possible, but some of them are - like this one - really subtle and hard to spot. I'm not sure anyone's managed to fully work out the circumstances under which 0.7 will fail to accept a block due to this bug.

MPOE-PR: Please do think from what I posted above that I defend the decision to forcibly accept the 0.7 fork and abandon the 0.8 fork, in violation of the bitcoin protocol's founding principle that greater hashing power always wins a dispute. Nobody asked me, of course, since I am neither developer nor mining pool manager. But as I see it, the final decision had two strong drawbacks and one weak upside.

The first strong drawback is that the decision forced a patch on clean efficient code (0.8 ) to conform to buggy slow code (0.7). In my experience this is never a good idea over the long pull.

Second, the decision burned up developers' political influence. A handful of developers used their deservedly high community respect to force a decision on the 0.8 miners. So be it. But the next emergency will see developer influence greatly reduced in consequence.

The weak upside? The decision prevented thousands of 0.7 users suffering crashes as their wallets choked on the offending block. This would have forced users around the world to stop dithering and upgrade to 0.8 immediately. So? What would have been wrong with that?

Read the chat logs before speaking about topics of which you know little.

The miners were not "forced" to do anything.  They could have chosen to stay on the 0.8 side of the fork.

Each miner (really, pool operator) votes with their collective hash power, deciding whether or not to support a mining-related decision like this.

A agree with you, but based on statements by Jeff, Gavin, and Mike, this will not happen.  If we want a well specified crypto currency with a wealth of implementations, we are going to have to create it.  Bitcoin is not that, and it is not going to become that.