Is provoking a fork on purpose a good thing ?

[Nicolas Dorier]

Imagine that you discover a fork condition between V1 and V2 of bitcoin core.
Surely enough, this should be reported to github, and test data must be updated.

However, I think an even better action is to deliberately provoke the fork.
Since the damage a fork would provoke depends on the number of people being on the wrong side of the fork, I think it is better to provoke the fork sooner than later on buggy implementations.

Another reason to deliberately provoke it, is that would-be full node implementers (people that would not want to depends on bitcoin core) would be notified immediately about their bad implementation, and will not leave it unaddressed.

What do you think ?

[hhanh00]

First of all, I don't think they are many people who do not rely on bitcoin core professionally. Some run a different implementation for personal use but when money is at stake the risk of loss is too high. Even if it is a small bug that makes you miss a transaction, it could be a very large transaction that ends up costing you your business.
So alternate implementations are mostly for side projects, and even if they fork, their impact on the consensus is too small to provoke a split. In fact, the current opinion is that none of the alternate implementations are fully compliant with bitcoin core (https://bitcointalk.org/index.php?topic=923409.0). In deciding what to do regarding a potential fork, I think we should ignore the impact on alternate implementations.

Since you talk about a bug in bitcoin core, it is a different story altogether. Let's say someone found a major difference which would split the chain. If only client nodes are affected, it would mess up network propagation. If miners are affected, it may split the blockchain. Most likely, people will lose money and they don't care whether it helps fixing bugs or not. I wouldn't care either.

I don't think the damage on the credibility of bitcoin is worth the extra kick in the anthill though I have the opposite opinion if we were talking about an altcoin.

[davec]

In my opinion, the responsible thing to do would be to do it on testnet.  Intentionally forking the mainnet block chain knowing it will likely cost some people money is a pretty crappy thing to do.

First of all, I don't think they are many people who do not rely on bitcoin core professionally. Some run a different implementation for personal use but when money is at stake the risk of loss is too high.

There are several large companies, such as Coinbase, that don't run on Bitcoin Core.

Even if it is a small bug that makes you miss a transaction, it could be a very large transaction that ends up costing you your business.

The transaction will end up in the block chain anyways (short of a massive network-wide chain fork that reorgs your transaction out and it got double-spent, but that is an issue that applies across the board regardless of any bugs), so even if your implementation didn't see it for some reason, the transaction, and hence your money, isn't lost.  The only time I can think of where this wouldn't be the case is if the bug involved sending the transaction to the wrong address.

[Nicolas Dorier]

Most likely, people will lose money and they don't care whether it helps fixing bugs or not. I wouldn't care either.

The problem is that if you publish the bug without provoking it, someone might deliberately provoke it later.
Also, as davec point out, if you do it on purpose, most transaction will return on the mempool once the fork is fixed.
However, if you do not provoke it on purpose:

1. More people will be impacted, (because more people will go to the bogus fork with time)
2. The attacker can make a double spend against an exchange, (this time, creating big loss, assuming a fork of more than 6 conf)

Provoking it early and purposely would not necessarily make people loosing money, on the contrary if you rely on "the good faith of the community to not provoke the fork" people will loose money by giving time to an attacker to prepare a double spend attack.

In my opinion, the responsible thing to do would be to do it on testnet.  Intentionally forking the mainnet block chain knowing it will likely cost some people money is a pretty crappy thing to do.

My point is the same as with hhanh. If people see that on TestNet, someone will exploit it on MainNet anyway, making more people impacted, and maybe coupled with a double spend attack.

The transaction will end up in the block chain anyways

Not necessarily if an attacker knows how a fork can happen, and planify a double spend against an exchange. (The fork could be more than 6 conf, if it is a bug between 2 versions of bitcoin core widely used)
Provoking it on purpose prevent someone from exploiting it.

[Gavin Andresen]

Imagine that you discover a fork condition between V1 and V2 of bitcoin core.
Surely enough, this should be reported to github, and test data must be updated.

No, please report security-critical issues (including consensus bugs) to the bitcoin-security mailing list: bitcoin-security@lists.sourceforge.net

[Nicolas Dorier]

Imagine that you discover a fork condition between V1 and V2 of bitcoin core.
Surely enough, this should be reported to github, and test data must be updated.

No, please report security-critical issues (including consensus bugs) to the bitcoin-security mailing list: bitcoin-security@lists.sourceforge.net

I'd just like to know why you would consider it better than provoking the fork on purpose.
As I said, if published before being exploited, then it can potentially be used maliciously by someone in bitcoin-security mailing list, making more damage that if the discoverer just provoke it, then publish it after.

[gmaxwell]

Potential forking conditions need to be handled in a coordinated manner in order to avoid opening people to loss.  In the past we've found forking conditions and managed them in a coordinated manner through e.g. fixes that prevent the discrepancy from ever showing up in the blockchain.  Any trigger of a fork _immediately_ allows it to be opportunistically used by thieves, who don't need to understand why the network has forked in order to find parties on other sides of it and rob them; and don't need to have done anything special before the fork showed up. Doing so is exactly the opposite of protective. Not specific to now, but as a general bit of advice, it may well be that anything you think you've found is not actually a real issue or is already known and already in the process of a coordinated resolution which such an attack would disrupt.

By intentionally triggering an inconsistency in network state you would be exposing yourself to civil litigation by any party harmed by the foreseeable outcomes of your attack the network/it's participating systems.  I would strongly recommend against it.

Instead I would recommend that you responsibly report any discoveries to the security contact on Bitcoin.org or the specific authors/maintainers of the Bitcoin application you believe to be most proximately at fault.

[Nicolas Dorier]

In the past we've found forking conditions and managed them in a coordinated manner through e.g. fixes that prevent the discrepancy from ever showing up in the blockchain.

I understand your point that a thief can exploit the fork even without knowing the cause, so it responds to my question.

However, how can you "immediately fix it" ? let's say the fork is between client V1 and V2 with 51%/49% of share.
Your fix will be coded in V3, and until V2 clients migrate to it, the blockchain is exposed to the fork condition. (which can take long)
I understand that firing the fork on purpose now does not prevent the thieves though, so what is your solution ?

By intentionally triggering an inconsistency in network state you would be exposing yourself to civil litigation by any party harmed by the foreseeable outcomes of your attack the network/it's participating systems.  I would strongly recommend against it.

Such person would stay anonymous so would not consider it an issue.
It is more a thought experiment about how to limit the impact of a forking condition.