Are we prepared for an emergency blockchain fork?

[grux]

Is there anything in place for a situation that requires a blockchain fork? I can imagine a scenario where all Bitcoin developers are scrambling to get the fix out that forks the blockchain and due to time constraints none of these fixes/additions from the wishlist are implemented. Shouldn't there be a ready-to-go and maintained fork of changes that can be rolled in along with an emergency fork? We wouldn't want to waste a fork...

[byt411]

Is there anything in place for a situation that requires a blockchain fork? I can imagine a scenario where all Bitcoin developers are scrambling to get the fix out that forks the blockchain and due to time constraints none of these fixes/additions from the wishlist are implemented. Shouldn't there be a ready-to-go and maintained fork of changes that can be rolled in along with an emergency fork? We wouldn't want to waste a fork...

Why would we even suddenly need an emergency fork?

[teukon]

Why would we even suddenly need an emergency fork?

The discovery of a critical bug in the protocol.

[alp]

Why would we even suddenly need an emergency fork?

The discovery of a critical bug in the protocol.

Also an attack that has no way to overcome it other than a hard fork.

[MysteryMiner]

Why would we even suddenly need an emergency fork?

The discovery of a critical bug in the protocol.

Also an attack that has no way to overcome it other than a hard fork.

I think the basic protocol and blockchain are robust enough to have no forking capable attacks. The last fork was caused by incorrect function of database engine and was resolved on the fly as I was sitting and drinking beer while watching events unfold.

[grux]

I think the basic protocol and blockchain are robust enough to have no forking capable attacks. The last fork was caused by incorrect function of database engine and was resolved on the fly as I was sitting and drinking beer while watching events unfold.

It's not a question of how stable and bug-free the current code is, the opportunity of a hard fork means we can roll in bug fixes/improvements that are potentially disruptive otherwise. Not to mention having an "emergency" branch will allow users and services to plan ahead as well. We need any discrepancy to go as smoothly as possible.

[ThirdRenaissance]

I think the basic protocol and blockchain are robust enough to have no forking capable attacks. The last fork was caused by incorrect function of database engine and was resolved on the fly as I was sitting and drinking beer while watching events unfold.

You think there can't be any forking attacks yet admit that a simple and until then undetected implementation error caused a fork. Doesn't add up. There is actually little reason to believe that the network is safe from malicious or accidental forking incidents, it's rather a matter of how well the network as a whole will deal with it when the time comes.

[alp]

Why would we even suddenly need an emergency fork?

The discovery of a critical bug in the protocol.

Also an attack that has no way to overcome it other than a hard fork.

I think the basic protocol and blockchain are robust enough to have no forking capable attacks. The last fork was caused by incorrect function of database engine and was resolved on the fly as I was sitting and drinking beer while watching events unfold.

I'm talking about an attack where the fix to it is a hard fork.  For example, if rogue miners started double spending in mass, rolling back the chain, holding the block chain hostage for huge tx fees, etc...

[grux]

I don't think anyone in the community and/or the foundation are really prepared for anything like this as well as could be. Anything that happens we will currently be disorganized and scrambling to get consensus, maybe even making rash decisions.

[wumpus]

An emergency isn't a time to introduce other features. That complicates things and may make people more hesitative to upgrade as it may introduce new bugs in addition to solve the old one.

You're welcome to implement points from the hardfork wishlist (for example on an alternative chain) but they will need to be tested thoroughly then introduced carefully. "Emergencies" provide no shortcut (unless it happens that your fork fixes the critical problem).

[jl2012]

I think the basic protocol and blockchain are robust enough to have no forking capable attacks. The last fork was caused by incorrect function of database engine and was resolved on the fly as I was sitting and drinking beer while watching events unfold.

It's not a question of how stable and bug-free the current code is, the opportunity of a hard fork means we can roll in bug fixes/improvements that are potentially disruptive otherwise. Not to mention having an "emergency" branch will allow users and services to plan ahead as well. We need any discrepancy to go as smoothly as possible.

Most bugs could be fixed by a soft-fork, because in terms of consensus we usually prefer restrictive than liberal. For example, the OP_RETURN bug and negative output value bug, the worst in the bitcoin history, have been fixed with a soft forks. Even the BIP50 incident could not be considered as a real hard-fork as the bug is non-deterministic and it is mainly the problem of a third-party package instead of the core bitcoin protocol

[ZephramC]

Why would we even suddenly need an emergency fork?

The discovery of a critical bug in the protocol.

Mere possibility of fast and enforceable emergency fork would be critical bug in the protocol, would it not?

[amspir]

Why would we even suddenly need an emergency fork?

The discovery of a critical bug in the protocol.

Mere possibility of fast and enforceable emergency fork would be critical bug in the protocol, would it not?

It should be called an "emergency 51% attack."   Bitcoin will be safer once miners don't use the current reference implementation as a majority.

[teukon]

Mere possibility of fast and enforceable emergency fork would be critical bug in the protocol, would it not?

Agreed.  I was thinking something akin to last-year's hard-fork.  No enforcement took place; everything was quickly settled through debate and voluntary action.

[Cryddit]

In theory, you could do something like insert a transaction in the blockchain with a 0.005 BTC txout spendable only by a certain secret key, and then modify the next version of the client to reject as invalid any chain containing a spend of that txout.

And then whomever holds that secret key could attempt to "kill" an alternate blockchain by spending that txout on that fork of the blockchain.

The problem with an idea like this is that if the fork is deliberate and malicious, then the malicious miners on that fork will be aware of the poison pill (because they have the sources) and will flatly refuse to mine that transaction.

[ZephramC]

In theory, you could do something like insert a transaction in the blockchain with a 0.005 BTC txout spendable only by a certain secret key, and then modify the next version of the client to reject as invalid any chain containing a spend of that txout.

And then whomever holds that secret key could attempt to "kill" an alternate blockchain by spending that txout on that fork of the blockchain.

The problem with an idea like this is that if the fork is deliberate and malicious, then the malicious miners on that fork will be aware of the poison pill (because they have the sources) and will flatly refuse to mine that transaction.

Why would anyone prefer such modified client with "poison pill receptor"?

[justbtcme]

All the btc community would have to agree to go over the new fork and abandon (not necessarily) the old one.

[Cryddit]

Why would anyone prefer such modified client with "poison pill receptor"?

I could sort of see it as everybody wants to quickly reject any chain that everybody else is also rejecting, and having your software taking the same poison pill that's there for everybody will drop that chain like a hot rock.  You get onto the "right" chain faster that way, and if you're a miner you waste less mining effort. 

But as I said, it doesn't matter.  That output could never be "spent," not really.  Every time such a tx were broadcast, it would guarantee that the chain would continue from the next mined block that *failed* to include it.  Miners aware of this simply would never include it in a block.  Miners who weren't aware of it would issue an orphan block, figure out what went wrong, and then adjust their software to never include it again. 

And the further problem is that we need to absolutely trust the guy with the key to that txout. 

[teukon]

And the further problem is that we need to absolutely trust the guy with the key to that txout. 

Yep.  In fact, for me, this is the first problem.  An effective poison pill would be an effective element of centralisation.  I could be convinced to entertain the notion but the term "guy" suggesting a human (laughably corruptible creatures) makes this easy to dismiss out of hand.

The fact that this scheme would be wholly ineffective, as you've described, is its saving grace.