public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: jl2012@xbt.hk
To: odinn <odinn.cyberguerrilla@riseup.net>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?
Date: Wed, 19 Aug 2015 11:22:43 -0400	[thread overview]
Message-ID: <46e6bf2dbd8e08745f1c0dbd9f62bc7d@xbt.hk> (raw)
In-Reply-To: <55D467AF.5030203@riseup.net>

odinn via bitcoin-dev 於 2015-08-19 07:25 寫到:

>  The big problem is
>> BIP101 being deployed as a Schism hardfork.
> 
> This is certainly a problem.
> 


No, BitcoinXT won't become a Schism hardfork, or may be just for a few 
days, at most.

There is one, and only one scenario that BitcoinXT will win: it is 
supported by major exchanges, merchants, and investors, and they request 
miners to support it. When BIP101 is activated, these exchanges will 
refuse to accept or exchange tokens from the old chain. Miners in the 
old chain can't sell their newly generated coins and can't pay the 
electricity bill. They will soon realize that they are mining fool's 
gold and will be forced to switch to the new chain or sell their ASIC. 
The old chain will be abandoned and has no hope to revive without a 
hardfork to decrease the difficulty. The dust will settle in days if not 
hours.

Will the adoption of BitcoinXT lead by miners? No, it won't. Actually, 
Chinese miners who control 60% of the network has already said that they 
would not adopt XT. So they must not be the leader in this revolution. 
Again, miners need to make sure they could sell their bitcoin in a good 
price, and that's not possible without support of exchanges and 
investors.

What about that Not-Bitcoin-XT? The creator of the spoof client may stay 
anonymous, but the miners cannot. 95% of the blocks come from known 
entities and they have to be responsible to their actions. And again, 
they have real money in stake. If bitcoin is destroyed, their ASIC 
serves at best as very inefficient heaters.

So Bitcoin-XT is basically in a win-all-or-lose-all position. It all 
relies on one condition: the support of major exchanges, merchants, and 
investors. Their consensus is what really matters. With their consensus, 
that could not be a Schism hardfork. Without their consensus, nothing 
will happen.

-------

Or let me analyse in a different angle. BitcoinXT is in no way similar 
to your examples of Schism hardforks. All of your examples, "ASIC-reset 
hardfork", "Anti-Block-creator hardfork", and "Anti-cabal hardfork", are 
hostile to the current biggest miners and will destroy their investment. 
These miners have no choice but stick to the original protocol so 2 
chains MUST coexist. However, BIP101 has no such effect at all and 
miners may freely switch between the forks. They will always choose the 
most valuable fork, so only one fork will survive.


  reply	other threads:[~2015-08-19 15:22 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-18  9:54 [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork? jl2012
2015-08-18 11:57 ` Micha Bailey
2015-08-18 18:52 ` Eric Lombrozo
2015-08-18 20:48 ` Danny Thorpe
2015-08-18 20:51   ` Eric Lombrozo
2015-08-18 21:06     ` Danny Thorpe
2015-08-18 21:17       ` Eric Lombrozo
2015-08-18 21:39         ` Danny Thorpe
2015-08-19  9:29       ` Jorge Timón
2015-08-19 10:14         ` odinn
2015-08-19 11:06           ` Jorge Timón
2015-08-19 11:25             ` odinn
2015-08-19 15:22               ` jl2012 [this message]
2015-08-19 15:48                 ` Tier Nolan
2015-08-19 15:25               ` Jorge Timón
2015-08-19 17:30         ` Danny Thorpe
2015-08-19 18:33           ` Jorge Timón
2015-08-18 22:51 ` Ahmed Zsales
2015-08-19  2:53   ` Eric Lombrozo
2015-08-19  9:24 ` Jorge Timón
2015-08-19 10:34   ` jl2012
2015-08-19 10:53     ` Jorge Timón

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46e6bf2dbd8e08745f1c0dbd9f62bc7d@xbt.hk \
    --to=jl2012@xbt.hk \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=odinn.cyberguerrilla@riseup.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox