Are we prepared for an emergency blockchain fork?

teukon

legendary

Activity: 1246

Merit: 1011

Quote from: Cryddit on March 20, 2014, 02:41:40 PM

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.

Cryddit

legendary

Activity: 924

Merit: 1132

Quote from: ZephramC on March 20, 2014, 08:08:39 AM

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.

justbtcme

sr. member

Activity: 420

Merit: 250

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

ZephramC

sr. member

Activity: 475

Merit: 255

Quote from: Cryddit on March 18, 2014, 10:31:07 PM

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

Cryddit

legendary

Activity: 924

Merit: 1132

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.

teukon

legendary

Activity: 1246

Merit: 1011

Quote from: ZephramC on March 10, 2014, 01:05:52 PM

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.

amspir

member

Activity: 112

Merit: 10

Quote from: ZephramC on March 10, 2014, 01:05:52 PM

Quote from: teukon on March 09, 2014, 06:07:25 PM

Quote from: byt411 on March 09, 2014, 05:22:27 PM

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.

ZephramC

sr. member

Activity: 475

Merit: 255

Quote from: teukon on March 09, 2014, 06:07:25 PM

Quote from: byt411 on March 09, 2014, 05:22:27 PM

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?

jl2012

legendary

Activity: 1792

Merit: 1111

Quote from: grux on March 09, 2014, 06:55:53 PM

Quote from: MysteryMiner on March 09, 2014, 06:39:05 PM

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

wumpus

hero member

Activity: 812

Merit: 1022

No Maps for These Territories

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

grux

member

Activity: 67

Merit: 10

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.

alp

full member

Activity: 284

Merit: 101

Quote from: MysteryMiner on March 09, 2014, 06:39:05 PM

Quote from: alp on March 09, 2014, 06:20:47 PM

Quote from: teukon on March 09, 2014, 06:07:25 PM

Quote from: byt411 on March 09, 2014, 05:22:27 PM

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

ThirdRenaissance

newbie

Activity: 30

Merit: 0

Quote from: MysteryMiner on March 09, 2014, 06:39:05 PM

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.

grux

member

Activity: 67

Merit: 10

Quote from: MysteryMiner on March 09, 2014, 06:39:05 PM

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.

MysteryMiner

legendary

Activity: 1512

Merit: 1049

Death to enemies!

Quote from: alp on March 09, 2014, 06:20:47 PM

Quote from: teukon on March 09, 2014, 06:07:25 PM

Quote from: byt411 on March 09, 2014, 05:22:27 PM

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.

alp

full member

Activity: 284

Merit: 101

Quote from: teukon on March 09, 2014, 06:07:25 PM

Quote from: byt411 on March 09, 2014, 05:22:27 PM

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.

teukon

legendary

Activity: 1246

Merit: 1011

Quote from: byt411 on March 09, 2014, 05:22:27 PM

Why would we even suddenly need an emergency fork?

The discovery of a critical bug in the protocol.

byt411

hero member

Activity: 798

Merit: 1000

Quote from: grux on March 09, 2014, 05:10:52 PM

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?

grux

member

Activity: 67

Merit: 10

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

Topic: Are we prepared for an emergency blockchain fork? (Read 1552 times)