Bitcoin Forum
October 20, 2017, 12:02:39 AM *
News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Is provoking a fork on purpose a good thing ?  (Read 921 times)
Nicolas Dorier
Hero Member
*****
Offline Offline

Activity: 686


View Profile
January 16, 2015, 08:37:05 PM
 #1

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 ?

Bitcoin address 15sYbVpRh6dyWycZMwPdxJWD4xbfxReeHe
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1508457759
Hero Member
*
Offline Offline

Posts: 1508457759

View Profile Personal Message (Offline)

Ignore
1508457759
Reply with quote  #2

1508457759
Report to moderator
1508457759
Hero Member
*
Offline Offline

Posts: 1508457759

View Profile Personal Message (Offline)

Ignore
1508457759
Reply with quote  #2

1508457759
Report to moderator
1508457759
Hero Member
*
Offline Offline

Posts: 1508457759

View Profile Personal Message (Offline)

Ignore
1508457759
Reply with quote  #2

1508457759
Report to moderator
hhanh00
Sr. Member
****
Offline Offline

Activity: 464


View Profile
January 17, 2015, 07:09:51 AM
 #2

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
Jr. Member
*
Offline Offline

Activity: 39


View Profile
January 17, 2015, 08:17:57 AM
 #3

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
Hero Member
*****
Offline Offline

Activity: 686


View Profile
January 17, 2015, 04:10:57 PM
 #4

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

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

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

Bitcoin address 15sYbVpRh6dyWycZMwPdxJWD4xbfxReeHe
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
January 17, 2015, 10:04:02 PM
 #5

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

How often do you get the chance to work on a potentially world-changing project?
Nicolas Dorier
Hero Member
*****
Offline Offline

Activity: 686


View Profile
January 17, 2015, 10:28:49 PM
 #6

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.

Bitcoin address 15sYbVpRh6dyWycZMwPdxJWD4xbfxReeHe
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2324



View Profile
January 17, 2015, 11:07:45 PM
 #7

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.

Bitcoin will not be compromised
Nicolas Dorier
Hero Member
*****
Offline Offline

Activity: 686


View Profile
January 18, 2015, 12:07:36 AM
 #8

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

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


Bitcoin address 15sYbVpRh6dyWycZMwPdxJWD4xbfxReeHe
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!