grux (OP)
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 67
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 09, 2014, 10: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...
|
|
|
|
byt411
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 09, 2014, 10:22:27 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?
|
|
|
|
teukon
Legendary
Offline
Activity: 1246
Merit: 1011
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 09, 2014, 11:07:25 PM |
|
Why would we even suddenly need an emergency fork?
The discovery of a critical bug in the protocol.
|
|
|
|
alp
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 09, 2014, 11:20:47 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 am looking for a good signature. Here could be your advertisement
|
|
|
MysteryMiner
Legendary
Offline
Activity: 1512
Merit: 1049
Death to enemies!
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 09, 2014, 11:39:05 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.
|
bc1q59y5jp2rrwgxuekc8kjk6s8k2es73uawprre4j
|
|
|
grux (OP)
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 67
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 09, 2014, 11:55:53 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.
|
|
|
|
ThirdRenaissance
Newbie
Offline
Activity: 30
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 10, 2014, 12:31:27 AM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 10, 2014, 01:26:07 AM |
|
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...
|
I am looking for a good signature. Here could be your advertisement
|
|
|
grux (OP)
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 67
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 10, 2014, 01:47:59 AM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 10, 2014, 07:08:02 AM Last edit: March 10, 2014, 08:53:49 AM by 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).
|
Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through File → Backup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
|
|
|
jl2012
Legendary
Offline
Activity: 1792
Merit: 1111
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 10, 2014, 07:32:09 AM |
|
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
|
Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY) LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC) PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
|
|
|
ZephramC
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 10, 2014, 06:05:52 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?
|
|
|
|
amspir
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 112
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 11, 2014, 01:02:15 AM |
|
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
Legendary
Offline
Activity: 1246
Merit: 1011
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 11, 2014, 09:57:59 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.
|
|
|
|
Cryddit
Legendary
Offline
Activity: 924
Merit: 1132
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 19, 2014, 03:31:07 AM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 20, 2014, 01:08:39 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"?
|
|
|
|
justbtcme
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 20, 2014, 03:54:15 PM |
|
All the btc community would have to agree to go over the new fork and abandon (not necessarily) the old one.
|
|
|
|
Cryddit
Legendary
Offline
Activity: 924
Merit: 1132
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 20, 2014, 07:41:40 PM |
|
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
Legendary
Offline
Activity: 1246
Merit: 1011
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 20, 2014, 09:30:45 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.
|
|
|
|
|