<p>A contentious hardfork (where some portion of the network doesn't agree to modify their consensus rules) is effectively a doomsday scenario, there's no making this safe or making tools which allow you to transact on two chains simultaneously with no ill effect. </p>

<blockquote>
  <p>This almost happened once before, and the miners picked the fork that solved the problem (a fork that would otherwise have lost, mind you).</p>
</blockquote>

<p>That does not reflect current understanding of how <a href="https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki" rel="nofollow">BIP50</a> operated. </p>

<p>The chain abandoned by human intervention was actually the correct one, the decision was made just because a majority of the networks nodes were using buggy software that would have had to have been updated very quickly. Nodes running 0.7 or earlier software could randomly fail out of consensus (with 0.8, or even just with other nodes running the same version) depending on their own environmental influences. </p>

<p>It's a little out to argument if fixing the implementation was a hard fork or not, but BIP50 is not an applicable example for gaining knowledge about how the network might operate under intentionally changed operating conditions.  </p>

<blockquote>
  <p>How long do you think it would take for bitcoin clients to appear that would ensure that your transaction is broadcast to both forks so that anyone seeing only one chain would see your transaction?</p>
</blockquote>

<p>There is no scenario in which two networks can continue to happily operate in unison. </p>

<ul>
<li><p>The two chains of differing consensus rules will fall out of synchronization. Inevitably due to a single transaction not confirming, being mutated between the chains changing the TXID, or someone spending a coinbase output, transactions on one side will become invalid where they would otherwise be valid on the other. </p>

<p>Rebroadcasting your transaction doesn't mean anything if it literally cant't exist in both chains, no wallet vendor will bother doing this for the extreme amount of development time required to make it work functionally, and the high amount of user confusion it would cause. </p></li>
<li><p>Clients on one side (or both) will ban their peers for not following consensus rules. This is part of a long list of denial of service attack prevention measures which include sending invalid blocks and wasting validation time on something that can never be accepted. Nodes that disable this rule may find that they reorganize onto different chains and flip flop between them</p></li>
<li><p>If two fictional companies Coinbarse and Bitflinux decide they will follow alternate chains, then there is an opportunity for every Bitcoin owner with an account on each to double their money. Simply sell your BTC twice for USD on each chain and you've got double the USD you would otherwise, the markets clearly couldn't survive this sort of behavior one way or the other. </p></li>
</ul>

<blockquote>
  <p>The worst people using bitcoin generally rely heavily on irreversibility, and the best people nearly always have some way to re-do any reversed transaction (rebroadcast is built into the standard client)</p>
</blockquote>

<p>That does not accurately portray the behavior of the system, and I'm not sure how that couples with "worse" people. If somebody pays you with a mature coinbase output which is reorganized out of the chain, then you are stuck without your money no recourse.  If someone pays you and an alternate payment included in a different block, then you are stuck without your money no recourse. The vast majority of users do not use wallets which rebroadcast transactions, and in almost all scenarios where payments could be reversed there is a high probability that they could also become invalidated as well. </p>

<hr>

<p>The simple answer is just that if you don't want dangerous and undefined things like this happening, don't go along with the belief that 75% of the mining hashrate is "consensus". Work towards solutions which don't actively destroy the ecosystem, and have complete agreement on their implementation and execution. </p>

CC BY-SA 3.0
2015-07-31T23:15:52.260Z
Bitcoin 0.7 and before were out of consensus with itself. Bitcoin 0.8 (as far as we know) was not.
Pieter Wuille
CC BY-SA 3.0
2015-08-01T01:20:15.200Z
@Bitcoin, thanks for the points you made.  It sounds like you'd just give up once you decided that the fork is contentious.  That is a valid answer and helpful, but it begs for verification and invites the followup: How big would each side have to be for you to give up?
Dave Scotese
CC BY-SA 3.0
2015-08-01T01:39:05.353Z
@DaveScotese That's not really an easy concept to quantify. Mining hashrate certainly does not represent the interests or costs of Bitcoins end users any more than it represents the [number of mountain railways in Switzerland](https://en.wikipedia.org/wiki/List_of_mountain_railways_in_Switzerland). Even if mining hashpower did represent consensus then leaving 25% of people behind is obviously unacceptable. Giving up isn't the right term I don't think, it's just realizing that Bitcoin as a distributed consensus system has failed and moving on.
Claris
CC BY-SA 3.0
2015-08-02T17:31:15.323Z
Somewhere between 1 and a billion, a number of grains of sand becomes a pile.  Selecting the number isn't really sensible but there are things we can do with piles of sand that we won't do with a few grains.   For me, bitcoin isn't dead just because there's a fork.  Both forks survive only because there are enough people continuing to solve blocks on them.  It seems wise to salvage what value we can when one fails.  I seek strategies for such preparation.
Dave Scotese
CC BY-SA 3.0
2015-08-03T11:05:28.567Z
@DaveScotese The system is not compatible with simultaneous operation of an incompatible fork. It does not make sense to accommodate something which is effectively a signal of the end of the network. On both a technical and a manpower level, nobody is interested or able to make allowances for it.
Claris
CC BY-SA 4.0
2022-09-22T22:32:40.100Z
@Claris: There's exactly one scenario where you'd have to care. Active 51% attack.
Joshua
CC BY-SA 3.0
2015-07-31T21:43:01.723Z
2015-07-31T23:22:16.890Z
2015-07-31T23:22:16.890Z
Claris
<p>It is conceivable (though generally buried with cognitive dissonance, I imagine) that a hard fork might not get resolved.  This almost happened once before, and the miners picked the fork that solved the problem (a fork that would otherwise have lost, mind you).  This was human intervention at its finest.</p>

<p>But what if it wasn't fixed?  How long do you think it would take for bitcoin clients to appear that would ensure that your transaction is broadcast to both forks so that anyone seeing only one chain would see your transaction?  Who would run into a lot of trouble in this scenario?  I think people relying on transaction irreversibility might get antsy, and that bothers me a little, but only a little.  The worst people using bitcoin generally rely heavily on irreversibility, and the best people nearly always have some way to re-do any reversed transaction (rebroadcast is built into the standard client).</p>

<p>I don't want to encourage hard forks.  I just want to frustrate the people who secretly yearn for one in order to destroy cryptos.</p>

<p>I view a valid transaction as good, but susceptible to being hidden.  It is the blockchain that currently prevents it from being hidden, but that is not the only way to make sure everyone on the planet can know that the owner of a private key has reassigned the bitcoins it controls to a private key that I own.</p>

CC BY-SA 3.0
2015-07-31T20:57:25.853Z
I suspect that this is a very contentious question with a lot of points of view. Keep it civil, folks. @Dave Mind editing the title? At present, it sounds like a poll about what each contributor would do.
Nick ODell
CC BY-SA 3.0
2015-08-01T01:11:00.633Z
I'm not sure I understand the concern, but would this work better? "Do you have a strategy for dealing with a hard fork of the blockchain?"
Dave Scotese
<doublespend><blockchain-fork><chain-reorganization>
What would you do while a hard fork lasts?
Dave Scotese
# What would you do while a hard fork lasts?

(Asked by: username_0 on 2015-07-31)

It is conceivable (though generally buried with cognitive dissonance, I imagine) that a hard fork might not get resolved. This almost happened once before, and the miners picked the fork that solved the problem (a fork that would otherwise have lost, mind you). This was human intervention at its finest.

But what if it wasn't fixed? How long do you think it would take for bitcoin clients to appear that would ensure that your transaction is broadcast to both forks so that anyone seeing only one chain would see your transaction? Who would run into a lot of trouble in this scenario? I think people relying on transaction irreversibility might get antsy, and that bothers me a little, but only a little. The worst people using bitcoin generally rely heavily on irreversibility, and the best people nearly always have some way to re-do any reversed transaction (rebroadcast is built into the standard client).

I don't want to encourage hard forks. I just want to frustrate the people who secretly yearn for one in order to destroy cryptos.

I view a valid transaction as good, but susceptible to being hidden. It is the blockchain that currently prevents it from being hidden, but that is not the only way to make sure everyone on the planet can know that the owner of a private key has reassigned the bitcoins it controls to a private key that I own.

**Tags:** doublespend, blockchain-fork, chain-reorganization

> **Comments:**
> **username_1**: I suspect that this is a very contentious question with a lot of points of view. Keep it civil, folks. @username_0 Mind editing the title? At present, it sounds like a poll about what each contributor would do.  
> **username_0**: I'm not sure I understand the concern, but would this work better? "Do you have a strategy for dealing with a hard fork of the blockchain?"  

---

## 1 answers

### Answer by username_2 on 2015-07-31. Score: 2

A contentious hardfork (where some portion of the network doesn't agree to modify their consensus rules) is effectively a doomsday scenario, there's no making this safe or making tools which allow you to transact on two chains simultaneously with no ill effect.

> This almost happened once before, and the miners picked the fork that solved the problem (a fork that would otherwise have lost, mind you).

That does not reflect current understanding of how [BIP50](https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki) operated.

The chain abandoned by human intervention was actually the correct one, the decision was made just because a majority of the networks nodes were using buggy software that would have had to have been updated very quickly. Nodes running 0.7 or earlier software could randomly fail out of consensus (with 0.8, or even just with other nodes running the same version) depending on their own environmental influences.

It's a little out to argument if fixing the implementation was a hard fork or not, but BIP50 is not an applicable example for gaining knowledge about how the network might operate under intentionally changed operating conditions.

> How long do you think it would take for bitcoin clients to appear that would ensure that your transaction is broadcast to both forks so that anyone seeing only one chain would see your transaction?

There is no scenario in which two networks can continue to happily operate in unison.

* The two chains of differing consensus rules will fall out of synchronization. Inevitably due to a single transaction not confirming, being mutated between the chains changing the TXID, or someone spending a coinbase output, transactions on one side will become invalid where they would otherwise be valid on the other.

  Rebroadcasting your transaction doesn't mean anything if it literally cant't exist in both chains, no wallet vendor will bother doing this for the extreme amount of development time required to make it work functionally, and the high amount of user confusion it would cause.
* Clients on one side (or both) will ban their peers for not following consensus rules. This is part of a long list of denial of service attack prevention measures which include sending invalid blocks and wasting validation time on something that can never be accepted. Nodes that disable this rule may find that they reorganize onto different chains and flip flop between them
* If two fictional companies Coinbarse and Bitflinux decide they will follow alternate chains, then there is an opportunity for every Bitcoin owner with an account on each to double their money. Simply sell your BTC twice for USD on each chain and you've got double the USD you would otherwise, the markets clearly couldn't survive this sort of behavior one way or the other.

> The worst people using bitcoin generally rely heavily on irreversibility, and the best people nearly always have some way to re-do any reversed transaction (rebroadcast is built into the standard client)

That does not accurately portray the behavior of the system, and I'm not sure how that couples with "worse" people. If somebody pays you with a mature coinbase output which is reorganized out of the chain, then you are stuck without your money no recourse. If someone pays you and an alternate payment included in a different block, then you are stuck without your money no recourse. The vast majority of users do not use wallets which rebroadcast transactions, and in almost all scenarios where payments could be reversed there is a high probability that they could also become invalidated as well.

---

The simple answer is just that if you don't want dangerous and undefined things like this happening, don't go along with the belief that 75% of the mining hashrate is "consensus". Work towards solutions which don't actively destroy the ecosystem, and have complete agreement on their implementation and execution.

> **Comments:**
> **username_3**: Bitcoin 0.7 and before were out of consensus with itself. Bitcoin 0.8 (as far as we know) was not.  
> **username_0**: @Bitcoin, thanks for the points you made.  It sounds like you'd just give up once you decided that the fork is contentious.  That is a valid answer and helpful, but it begs for verification and invites the followup: How big would each side have to be for you to give up?  
> **username_2**: @username_0 That's not really an easy concept to quantify. Mining hashrate certainly does not represent the interests or costs of Bitcoins end users any more than it represents the [number of mountain railways in Switzerland](https://en.wikipedia.org/wiki/List_of_mountain_railways_in_Switzerland). Even if mining hashpower did represent consensus then leaving 25% of people behind is obviously unacceptable. Giving up isn't the right term I don't think, it's just realizing that Bitcoin as a distributed consensus system has failed and moving on.  
> **username_0**: Somewhere between 1 and a billion, a number of grains of sand becomes a pile.  Selecting the number isn't really sensible but there are things we can do with piles of sand that we won't do with a few grains.   For me, bitcoin isn't dead just because there's a fork.  Both forks survive only because there are enough people continuing to solve blocks on them.  It seems wise to salvage what value we can when one fails.  I seek strategies for such preparation.  
> **username_2**: @username_0 The system is not compatible with simultaneous operation of an incompatible fork. It does not make sense to accommodate something which is effectively a signal of the end of the network. On both a technical and a manpower level, nobody is interested or able to make allowances for it.  
> **username_4**: @username_2: There's exactly one scenario where you'd have to care. Active 51% attack.  

---

