Hacker News Reader

Comment by rorrr | Hacker News Reader

I don't understand why 0.7 gets the preference though, considering that it's the version with the DB bug in it.

Because it won't generate blocks that 0.8 won't accept, and 0.8 does generate blocks that 0.7 won't accept.

This is a quick fix to get the system back on its feet while they figure out the longer term strategic answer.

Who is "they"? Is there a central authority in charge of BTC? I thought part of the advantage of it was that there wasn't.

Exactly, no-one is forcing the miners to do this. The 0.8 miners could decide to keep that branch alive, and if it stays longest, then the "central committee" would be SOL and just have to accept it.

"They" is the dev team for the main client.

They don't (can't) rule with an iron fist, but they have a lot of good will with the community, so most will listen to them.

EDIT- The good/bad news is that since most mining (and thus transaction verification) has consolidated into large pools of machines, only a few people have to agree with "them". So in a sense, there is a central committee of people who run the large mining pools that does have a fair amount of power.

Yes, you could say that ultimately the miners rule which blockchain grows, but have strong reasons to defer to the judgement core developers.

Even though the pool operators have large discretion, the computational power that makes up their pools can be moved elsewhere... a little like a transferable proxy. Most smaller miners probably trust the pools who they've grown confident in... but a large enough controversy or campaign could conceivably shift the mining-power away from pool operators who make unpopular decisions.

Yes. A large enough controversy could also threaten to devalue Bitcoin drastically. No one wants to store assets in a currency which could potentially lose the faith of all of its merchants, vendors when it forks and no one can agree on which fork is the 'correct' one. It's in everyone's best interest to do whatever it takes to get back to a single long blockchain.

So what you're saying is that there isn't a central authority like the Bank of England but there is a cartel like OPEC?

Yeah, cause access to compilers really is a scarce resource.

Trust is the limiting factor.

More like customers of amazon, Google and apple. If suddenly what they were offering sucked, the 'little guys' would put their resources elsewhere.

It's easy to fall prey to the idea that the ideal is that there is no authorities anywhere, but that's not the goal. The point is that you can choose your authority freely, and if enough people decide a given authority is no longer worthwhile, they can choose a new one freely.

Open source works the same way. Of course there are authorities for a given project who can choose what the final release is, but if they get too full of themselves or something it's easy enough to bypass them. It's happened quite frequently, so it's not an idle threat, either. You can't prevent authority from developing, that's wouldn't even be a good thing, but you can prevent it from abusing its current position of authority to lock in future authority.

I don't understand this. If 0.8 fixed the bug that 0.7 contains, shouldn't encourage everyone to upgrade instead of downgrade? And it's fine that the longest blockchain is on 0.8; that is the latest version. If you're not patching your software, I am not so surprised that you're vulnerable (in this case to double-spending attacks).

A second thing that I don't understand is why 0.8 people are vulnerable to double-spending attacks. It wasn't said that 0.7 was safe, but it was said that 0.8 was vulnerable. But with two separate blockchains, wouldn't both be vulnerable? Or at least 0.7 because they don't accept 0.8's blockchain?

If they pushed for people upgrading to 0.8 then everyone not upgrading would have their own blockchain. By getting more than 50% of the users to use 0.7, the rest of the 0.8 clients will discover that everyone else uses the 0.7 chain and thus replay all of the transactions on that chain.

Upgrading: Those who doesn't upgrade end up with their own chain.

Downgrading: Those who doesn't downgrade will automatically use the other chain when it becomes dominant.

> But with two separate blockchains, wouldn't both be vulnerable?

It's only the chain that doesn't become the main chain that is vulnerable. Because they're pushing for 0.7 to be the main chain you don't have to worry about double spending there.

The choice was made for backwards compatibility. People are still running version 0.3-0.7 of bitcoind and up to this point that was not a problem. If we decided the 0.8 fork was canonical we'd lose a big chunk of the userbase.

Reply on news.ycombinator.com