From: Gavin Andresen <gavinandresen@gmail•com>
To: "Jonathan Toomim (Toomim Bros)" <j@toom•im>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Is it possible for there to be two chains after a hard fork?
Date: Tue, 29 Sep 2015 10:04:39 -0400 [thread overview]
Message-ID: <CABsx9T2pDwNBrC-3w8vHeaLYZ6eoNTNU0gW741Y51YL9hU-kiA@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2289 bytes --]
I keep seeing statements like this:
On Tue, Sep 29, 2015 at 9:30 AM, Jonathan Toomim (Toomim Bros) via
bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> As a further benefit to hard forks, anybody who is ideologically opposed
> to the change can continue to use the old version successfully, as long as
> there are enough miners to keep the fork alive.
... but I can't see how that would work.
Lets say there is a hard fork, and 5% of miners stubbornly refuse to go
along with the 95% majority (for this thought experiment, it doesn't matter
if the old rules or new rules 'win').
Lets further imagine that some exchange decides to support that 5% and lets
people trade coins from that fork (one of the small altcoin exchanges would
definitely do this if they think they can make a profit).
Now, lets say I've got a lot of pre-fork bitcoin; they're valid on both
sides of the fork. I support the 95% chain (because I'm not insane), but
I'm happy to take people's money if they're stupid enough to give it to me.
So, I do the following:
1) Create a send-to-self transaction on the 95% fork that is ONLY valid on
the 95% fork (maybe I CoinJoin with a post-fork coinbase transaction, or
just move my coins into then out of an exchange's very active hot wallet so
I get coins with a long transaction history on the 95% side of the fork).
2) Transfer those same coins to the 5% exchange and sell them for whatever
price I can get (I don't care how low, it is free money to me-- I will
still own the coins on the 95% fork).
I have to do step (1) to prevent the exchange from taking the
transfer-to-exchange transaction and replaying it on the 95% chain.
I don't see any way of preventing EVERYBODY who has coins on the 95% side
of the fork from doing that. The result would be a huge free-fall in price
as I, and everybody else, rushes to get some free money from anybody
willing to pay us to remain idealogically pure.
Does anybody think something else would happen, and do you think that
ANYBODY would stick to the 5% fork in the face of enormously long
transaction confirmation times (~3 hours), a huge transaction backlog as
lots of the 95%'ers try to sell their coins before the price drops, and a
massive price drop for coins on the 5% fork.
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 3343 bytes --]
next reply other threads:[~2015-09-29 14:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-29 14:04 Gavin Andresen [this message]
2015-09-29 14:17 ` Jonathan Toomim (Toomim Bros)
2015-09-29 14:59 ` Mark Friedenbach
2015-09-29 17:24 ` Allen Piscitello
2015-09-29 17:35 ` Gavin Andresen
2015-09-29 17:43 ` Allen Piscitello
2015-09-29 17:51 ` Mike Hearn
2015-09-29 17:55 ` Allen Piscitello
2015-09-29 18:01 ` Gavin Andresen
2015-09-29 18:23 ` Allen Piscitello
2015-09-30 16:14 ` Jorge Timón
2015-09-29 18:02 ` Mike Hearn
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=CABsx9T2pDwNBrC-3w8vHeaLYZ6eoNTNU0gW741Y51YL9hU-kiA@mail.gmail.com \
--to=gavinandresen@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=j@toom$(echo .)im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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