Dangerous precedents set on March 12 2013

[Blinken]

Seems like this was one of those "emperor has no clothes" moment, where you learn that the powers that be are making up the rules as they go along.

The US Govmint does this all the time. They just make stuff up that is totally unconstitutional because it is "convenient" and everybody goes along with it (or else gets arrested).

The lesson here is pretty clear: don't play by the official rules, do what the majority wants--those are the real rules and they change all the time.

Speaking of rules, is the new rule that the blocks will have a maximum size from now on so the 0.8 booboo doesn't happen again, or is there some plan to support big blocks in the future?

[johnyj]

This fork is not PLANNED, since devs did not have time to identify the cause when it happened, the only reasonable reaction at that time is a roll back, this is common sense in software upgrading procedure

The 0.8 version of the mining software adhered more closely to Satoshi's white paper than 0.7 did. They should have stuck with 0.8 for this reason alone.

I think the 0.3 version is more close to Satoshi's original design, since then lot's of improvements were made

[benjamindees]

It is understandable that they have been so far following relatively blindly the advice of the core development team, but I think it is time for this to stop, given the recent situation.

So, basically, you think that miners should stop blindly following the core developers, yet should upgrade the entire network on short notice, to an untested (and provably buggy) new version of the client released by them?

[markm]

I had not even noticed that my 0.8 client was no longer nagging me constantly about not using it for mining or commerce, I was running it hoping that by doing so I might help find any bugs before any attempt to start messing with block sizes happened.

In retrospect I discovered that at some pull or other git pull had no longer been pulling a pre-0.8 test that nagged not to use it for real mining or money.

When the fork hit I still had not seen any discussion of whether 0.8 or even pre-0.8 had been in the field without problems long enough that it might be time to risk a controlled test of creating some blocks larger than 0.7 had allowed.

So yeah, it certainly did not seem to be a planned test, all the stakeholders standing by counting down the hours or days to when some pool selected to run the test should try increasing the block size.

Maybe git pull should have some kind of nag thing it itself could do, like warning, warning, this is now a non-test / non-pre version of 0.8, thus pool XXX is expected to now be producing oversized blocks, if you encounter problems please take steps a b and c...

On the other hand maybe oversize blocks should have been tried longer with pre-0.8 versions? Or were they but no one was watching orphans to notice 0.7 was orphaning some of them due to a database problem?

-MarkM-

[jgarzik]

On the other hand maybe oversize blocks should have been tried longer with pre-0.8 versions? Or were they but no one was watching orphans to notice 0.7 was orphaning some of them due to a database problem?

1MB blocks were tested long, with 0.7 and before, on testnet.

The problem was not the size of the blocks.

[coinuser4000]

Sounds to me like you're suggesting we allow an elite class, with supposedly superior intellect and skills, to tell everyone else what to do because they know what's best for everyone.

They already have that in the US, it's called the Federal Bank. Anyone notice how that's been working out lately?

Bitcoin flies in the face of centralized controls. You will kill it if you centralize it.

?

[markm]

The problem was not the size of the blocks.

Not size per se, no. But something in the choices of which transactions to include, combined with a block size permitting inclusion of sets/combos of transactions that were capable of falling afoul of the BDB limitations, seems to have happened somewhere along the line.

Posts have recently been claiming that the default configuration of 0.8 is okay, yet supposedly 0.7 was able to produce these "ungood" blocks. How come 0.8 cannot, in its default configuration?

-MarkM-

[luv2drnkbr]

wtf of course the users have a vote.  they are integral to the system.  if no users will validate a miners block and pass it on, the miner doesn't end up getting credit for it and his block is orphaned.  why would have less people (i.e. just miners, not miners AND users) be a better thing?

[eleuthria]

We were faced with an easy decision:

1) Stay on the 0.8 chain and anybody that did not immediately upgrade would quickly be ripped off as awareness of the problem grew among the community.  0.7 would NEVER be able to rejoin that chain without upgrading/configuration changes.

2) Go back to the 0.7 chain, which all active nodes would revert to, heavily limiting the potential for any double spend attacks to be successful.


Yes, we would all like to kill off 0.7 and move to 0.8+.  0.8 sped up Bitcoin greatly, making it easier to start up and use.  It made pools faster and more efficient as well.  But the option was to force an unintended hard fork forward, or bring the network back together by downgrading until a patch can be deployed with a that works the constraints of the BerkeleyDB bug until a predetermined time, giving users a chance to upgrade.

In the end, it took under 7 hours for the blockchain to revert back to a universally compatible version (0.7).  It was possible for somebody to have slept through the entire event, it was resolved that quickly.  This could have been a disastrous situation if we tried to keep moving on a hard fork that nobody knew was coming.

In no way is it a "dangerous precedent" that the core developers and pool operators decided (in a crisis situation) to revert versions to keep the network whole.  A dangerous precedent would have been deciding "0.8 is so much better, they should have upgraded already even though they didn't know it was mandatory."

[Domrada]

The miners did vote. The pools switched and the miners didn't bail. I even pool hopped into BTCGuild the moment I read they finished their rollback to 0.7.

I also pool hopped into BTCGuild due to this event.

Eleuthria is a hero.

[Raoul Duke]

It was possible for somebody to have slept through the entire event, it was resolved that quickly.

I'm the living proof of someone sleeping through the entire event.

[aantonop]

Unfortunately, from my experience of the entire event in real time, the only fact you got right about the "bug" was the part where you admitted you didn't understand it.

The decision was 100% correct. The path back to 0.7 was predictable. The path forward on an unannounced hard-fork would have been a disaster and taken weeks to stabilize. This was not about purity of vision or block size, but about undiscovered bugs in BDB.

In the end, the combined efforts of the developers and miners got the problem resolved in a distributed, efficient and effective manner through consensus. That only served to prove that the operations and operators of the infrastructure have also achieved some maturity and are contributing to a resilient bitcoin.

As strong and resilient currency is math + infrastructure + operations, because you won't always catch all the bugs or prevent all the real world disasters. So you need operations and resilient infrastructure. Because in the end, shit will happen and what matters is how it is handled. Not everything can be predicted or prevented. The rest you catch in triage.

Last week was an example of great execution, fast thinking and almost painless results in an unexpected, hard, live network test.

I give them an A.

[jubalix]

I would like to think that the decisions will be based on what bitcoin was meant to be. This will often be subjective, but for me personally, the true bitcoin will always be the one mentioned in the Satoshi White Paper, and that paper defines the maximum block size as 1Mb.

One of the many amazing things about Bitcoin is watching a religion that would once have taken centuries to get established form itself in a couple of years.

First the adherents decide they want to abide by all the restrictions in their Holy Book, even when they're obviously no longer relevant, like applying dietary restrictions designed to deal with parasites in the absence of refrigeration technology.

Then as if that's not enough, they take little implementation quirks, traditions and short-term quick-fix bodges that build up over time and start imagining that they're in their Holy Book.

I don't suppose saying this will help as once a bit of dogma gets into a religious person's head it's a hell of a job getting it out, but there's nothing in the Holy Prophet's white paper about limiting block sizes. He specifically discussed the network scaling as big as Visa. (Letters to the Cryptographians, Chapter 2, Verse 2). Obviously nobody intended to grow a network just to the point where it was about to become really useful for actual, non-speculative commerce, then cripple it to stop it doing more than 10 transactions per second.

I know Satoishi has been deified, who gives a F*ck that satoshi said X....the idea must stand on its merits today....wow

[koin]

i'm more worried about dangerous presidents.

[eldentyrell]

I do not feel they should be voting at all. Bitcoin's integrity is the responsibility of the miners, not the users.

Er, not quite.  If it were entirely up to the miners we'd probably decide not to cut the block reward every four years and bitcoin would go from being a deflationary currency to a (mildly) inflationary currency.  People probably wouldn't want to hold BTC for the long term if changes like that could be imposed on them.

Secondly, the miners have a responsibility to maintain the integrity of bitcoin. This means doing whatever possible to ensure that transactions are not reversible. Their decision to revert to 0.7 broke this fundamental rule. They should never do this again if bitcoin is to retain any credibility.

That is very true.  As you mentioned, the Satoshi client already goes into safe mode when it notices a longer invalid chain; this protected the 0.7 clients from accepting transactions on their "short fork" while the 0.8 branch was longer -- they all shut down (ok, some crashed).

What has become clear is that there is a complementary check for long (but not longer) recent forks on the chain.  If the 0.8 clients had included this check the now-infamous OKPAY-BTCe double-spend could not have happened.  Hindsight is 20/20, I didn't forsee this and I don't blame anybody else for not forseeing it.  But failing to include this simple check in the next release of bitcoin-qt would be very reckless behavior, and if this situation happens again people will want to know why the client wasn't immunized against it while there was a chance to do so.

[eldentyrell]

Seems like this was one of those "emperor has no clothes" moment, where you learn that the powers that be are making up the rules as they go along.

No, it was just a (relatively) easy negotiation, and everybody involved had more to gain from a quick resolution than they had to lose from one choice or the other.  It's kind of like how most business contracts never wind up being disputed in court.  That doesn't mean the courts are powerless or irrelevant.

[iammagicmike]

I thought using 7 had less risk, not necessarily the better choice, but for the sake of nipping it in the bud it seemed like a reasonable decision.