Topic: Dangerous precedents set on March 12 2013 (Read 3884 times)
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.
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.
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.
i'm more worried about dangerous presidents.
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
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.
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.
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.
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.
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."
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."
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?
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-
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.
?
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.
?
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.
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-
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-
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?
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
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
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?
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?
I think the alert system should be moved into a plugin so people can subscribe to the Bitcoin Foundation alerts if they want. That way if some other entity wanted to send alerts they could develop their own plugin and users can decide which plugins to download.
That's a pretty decent suggestion.
[Edit: Not that alerts from mutliple parties are sent out necessarily but that the client can subscribe to alerts from outside sources and that it would have the ability to go into safe mode or require manual approval for payments as a reaction to certain alerts.]
People running the software had to make a choice, which transactions to revert. It was going to be 0.7 or 0.8.
When a staged rollout goes pear-shaped, you roll back. This should have been the plan from the beginning.
Jump to: