Bitcoin Forum

I think BTCGuild's decision to revert to 0.7 for mining was the wrong decision. Let's explore why I've come to this conclusion.

Firstly, let's ask - who do we want to be in control of bitcoin? By in control I mean, to define and maintain the integrity of bitcoin.

I personally feel that bitcoin should be defined as closely as possible to the white paper that Satoshi wrote.

I also feel that the people better skilled to make these decisions are the miners and mining pools rather than the average user of bitcoin (who probably just downloaded the first bitcoin client they found after a Google search).

The decision (to switch mining back to 0.7 version) was heavily influenced by the userbase. Most of the userbase are probably unaware currently that they are effectively voting on the definition by their choice of bitcoin client.

I do not feel they should be voting at all. Bitcoin's integrity is the responsibility of the miners, not the users. The miners should not be influenced to the extent they were by the users nor the developers of any client, in my opinion. Granted the miners depend heavily on the skill (and they are skilled) of the developers and need to work in close co-operation, and to ensure that the the mining is done using as similar code as they can manage and that it performs as closely to the white paper. The miner's have a responsibility to check that the code they are using keeps to the integrity of the white paper also.

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.

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.

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. They need to think far more critically and recognize their responsibilities. There are going to be politics involved in the evolution of bitcoin. There is going to be influence and pressure from governments on all parties involved - the developers and the miners in particular. Anyone developing or mining bitcoin who is not anonymous is touchable.  (Read http://www.dgcmagazine.com/the-old-radical-how-bitcoin-is-being-destroyed/ to better understand why I mention this).

Staying mining on 0.8 would have been the safer option because 0.7 clients already were alerting the users to their being a longer chain. Users of 0,8 weren't being alerted until at least 11 (21 by some reports) confirmations had passed on their fork so during those confirmations all transactions were not trustworthy. Trust in transactions is the primary importance in bitcoin. Although some failure for alerting the users to this is the fact that most client don't alert the user to the event that another chain is catching up - they only alert when another chain is longer, and even then, only when by at least 6 blocks.

There will probably be events in the future where the miners and the developers disagree, and the miners disagree with other miners about the future of bitcoin, but 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. The currently running bitcoin is therefore not really bitcoin, and won't be until a hardfork is done to set this to the correct number. 0.8 did that - the miners were running with it and had a majority, until March 12.

I'll admit I don't know all the details behind the decision to switch back to 0.7 and to something less-bitcoin like. I'm aware that mtgox and blockchain.info were still on the 0.7 fork but they could have fixed this and arguably this was their fault for not keeping up to date. Although on the other hand, the miners may have switched to 0.8 without sufficient testing and notice. Mtgox's software would surely have noticed the longer chain and automatically switched to a safe mode where no transactions were accepted until resolved, so they'd not have lost any money, but it would have been a headache for the site maintainer to install the patch needed to switch to the 0.8 fork, admittedly. Still, I think this is what should have been done instead.

So, I've yet to hear a strong argument still for the decision. I'll keep looking though, and thanks in advance to anyone who can enlighten me.

If the users are not voting (validating), then it is trivial for miners to rewrite the rules.

If the users are fully validating, then a miner decision to have each block produce 50 BTC again would be instantly rejected.

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.

Either way it's a decision: 0.7 or 0.8.  And a decision made by the same people.

As it worked out it was tolerably graceful.

I've got no problems at all with how it went.

go found yourself a religion. "true bitcoin".....what the fuck?!

There is a market for securing transactions.  Markets consist of both consumers (bitcoin users) and suppliers (miners).  Miners could have decided to go to 0.8, but it's not clear to me that 0.7 still wouldn't have won out in the long run.  The consumers could have decided to stay on 0.7 and any miners still mining on 0.7 would have still been providing a transaction security service to those users.  If that service was adequate (blocks continued to be found at a reasonable pace), it's quite easy to imagine that as the 0.7 chain continued on, miners that had previously switched to 0.8 would realize that they weren't servicing a large population of users...they could have then made the rational decision to switch back to 0.7.  The 0.7 chain would slowly regain momentum, overtaking 0.8 and ultimately providing transaction security to the entire community of 0.7 and 0.8 users.  Those miners that had continued on the 0.8 fork would lose all their mining revenues.

Conversely, consumers, seeking the most secure service and seeing the mining community transitioning to 0.8 might have made the rational decision to incur the work of upgrading to 0.8.

The decision that miners made was to serve the largest pool of consumers of their services.  Targeting the largest market of users with your mining capacity is probably the best policy (and would likely ensure that you, as a miner, are on the block chain most likely to survive).

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.

As with any religion, believers will believe what they're gonna believe no matter what their leader said:

TLDR;
As the price goes up, there is a concentrated vested interest in the Bitcoin community to do the best for what they have their money invested in.  As I read in another thread about somebody offering $500 to attack the LTC network, someone else pointed out that all that hardware would make them thousands per day vs. the $500.  Long story short, these "coins" are just simply worth way too much money, and unless there are enough people out there that do not like money, it will survive.  Sure we will have a few speed bumps along the way, but you have to remember when this "currency" or whatever you want to call it was created.  It has done amazingly great for the length of time we are talking about and will only get better.

I think the right decision was made... wouldn't the alternate mean the majority having to update to the 0.8 client before being able to use Bitcoin again? I think this would have caused even more panic. I live in the UK, I woke up and the situation had been resolved. It would have looked much more serious if 50% (or whatever) of users couldn't use Bitcoin. For many upgrading is simple... but for my Linux install, the repository wasn't even ready for a at least a week after 0.8 was released!
The devs need to sort out a 0.81 release and test it hard, then test it again. When the concerns about transaction limits are removed confidence in the protocol will be solid.
OP referring to the white paper does sound a bit religious! 

Satoshis paper makes no mention of a one megabyte block size limit.

Idealistic thinking meets practicality...I think an unintended network split would have been foolish to just let happen...making two weaker Bitcoin networks is in no ones best interest. This wasn't a fork per se, all transactions were broadcast to both halves of the split network. Not many transactions would've been "reversed". Most transactions were on both chains anyway. As I understand it, the balance of hash rate on each network was about equal...thus the split network could have persisted for a very long time....increasing the possibility of more transactions becoming reversible. It's probably a still possible attack method on the network.

I don't understand why this is so controversial. There was a major issue with compatibility and it would have been a permanent fork if the 0.8 chain survived. I don't think it would have anyway, because it was in nobody's best interest to have a permanent fork.

The developers quickly identified the problem and announced the solution. No one was forced. No one was told to do something against that was against their best interest. I think a wonderful precedent was set on March 12, 2013. That was one of transparency and voluntary co-operation. The devs could have done nothing and the same result would have probably happened eventually (much later), but there would have been more panic.

What you speak of is not the Bitcoin I consented to use. K THX BYE

Or a non-inflationary money supply.

It still seems odd to me why satoshi wouldn't still have a hand in steering Bitcoin through these issues.

The Pope has to rule on whether each incident in which he seemingly did actually counts before we can Canonise the guy, so in the meantime its a bit hush hush.

-MarkM-

When a staged rollout goes pear-shaped, you roll back. This should have been the plan from the beginning.

People running the software had to make a choice, which transactions to revert.  It was going to be 0.7 or 0.8.

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.]

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?

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


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

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?

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-

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

The problem was not the size of the blocks.

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.

?

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-

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?

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."

I also pool hopped into BTCGuild due to this event.

Eleuthria is a hero.

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

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.

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

i'm more worried about dangerous presidents.

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.



That is very true.  As you mentioned, the Satoshi client already goes into safe mode when it notices a longer invalid chain (https://bitcointalk.org/index.php?topic=152282.msg1619090#msg1619090); 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 (https://bitcointalk.org/index.php?topic=152348.msg1619035#msg1619035).  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.

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 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.