summaryrefslogtreecommitdiff
path: root/3c/d1daa92f97bacc70c1b88a51eb03b32df615b4
blob: 2603a697a07b72b66c0a26ba40986bb4426bf807 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
Return-Path: <gavinandresen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 40BE51DDA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 29 Sep 2015 14:04:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com
	[209.85.214.177])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E64FC220
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 29 Sep 2015 14:04:39 +0000 (UTC)
Received: by obbda8 with SMTP id da8so6094827obb.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 29 Sep 2015 07:04:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:cc:content-type;
	bh=AtTeoB8SVg04XvipogU8B0WS8xcYYV0GBjhaLPmMwh8=;
	b=ze42yGEdhSF+KuyZptG+a+eAZJBlPiex8OMEK6l1OjGB1jjAUQIEoZK0sLFCdCZG5q
	xqHjfzr77vIa4s5YfT0lPuc7sY+HhWr8Z00krstQgueqSX4nxC5qDXQiZcQmfGcKn/fA
	KZmd9u07j3xzpsb3+34eHIuVDk/8dyyJb81XK9j+uVT1euB4e3/X5+Q/7mrXS31Biud5
	q0DQ5ChxNqEHZYpiPbLs0fIBfza54Kq5BqHfTMub8U0kO826psyyJAkCX7J0Z0iVa+E3
	lKoO0waY5W1I1KX9PtahycNhGE/71T0z/Mj6rMbNiPJVcJxG5AXwC86dfovZ6U8Oa+A5
	f96A==
MIME-Version: 1.0
X-Received: by 10.182.142.129 with SMTP id rw1mr14377228obb.28.1443535479158; 
	Tue, 29 Sep 2015 07:04:39 -0700 (PDT)
Received: by 10.60.58.134 with HTTP; Tue, 29 Sep 2015 07:04:39 -0700 (PDT)
Date: Tue, 29 Sep 2015 10:04:39 -0400
Message-ID: <CABsx9T2pDwNBrC-3w8vHeaLYZ6eoNTNU0gW741Y51YL9hU-kiA@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: "Jonathan Toomim (Toomim Bros)" <j@toom.im>
Content-Type: multipart/alternative; boundary=001a11c1ccfa74bff90520e34b81
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_05,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] Is it possible for there to be two chains after a
	hard fork?
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Sep 2015 14:04:46 -0000

--001a11c1ccfa74bff90520e34b81
Content-Type: text/plain; charset=UTF-8

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

--001a11c1ccfa74bff90520e34b81
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">I ke=
ep seeing statements like this:</div><div class=3D"gmail_quote"><br></div><=
div class=3D"gmail_quote">On Tue, Sep 29, 2015 at 9:30 AM, Jonathan Toomim =
(Toomim Bros) via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitco=
in-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linux=
foundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.</blockquote></div><br>... but I c=
an&#39;t see how that would work.</div><div class=3D"gmail_extra"><br></div=
><div class=3D"gmail_extra">Lets say there is a hard fork, and 5% of miners=
 stubbornly refuse to go along with the 95% majority (for this thought expe=
riment, it doesn&#39;t matter if the old rules or new rules &#39;win&#39;).=
</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Lets =
further imagine that some exchange decides to support that 5% and lets peop=
le trade coins from that fork (one of the small altcoin exchanges would def=
initely do this if they think they can make a profit).</div><div class=3D"g=
mail_extra"><br></div><div class=3D"gmail_extra">Now, lets say I&#39;ve got=
 a lot of pre-fork bitcoin; they&#39;re valid on both sides of the fork. I =
support the 95% chain (because I&#39;m not insane), but I&#39;m happy to ta=
ke people&#39;s money if they&#39;re stupid enough to give it to me.</div><=
div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">So, I do the=
 following:</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_e=
xtra">1) Create a send-to-self transaction on the 95% fork that is ONLY val=
id on the 95% fork (maybe I CoinJoin with a post-fork coinbase transaction,=
 or just move my coins into then out of an exchange&#39;s very active hot w=
allet so I get coins with a long transaction history on the 95% side of the=
 fork).</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra=
">2) Transfer =C2=A0those same coins to the 5% exchange and sell them for w=
hatever price I can get (I don&#39;t care how low, it is free money to me--=
 I will still own the coins on the 95% fork).</div><div class=3D"gmail_extr=
a"><br></div><div class=3D"gmail_extra">I have to do step (1) to prevent th=
e exchange from taking the transfer-to-exchange transaction and replaying i=
t on the 95% chain.<br><br>I don&#39;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.</di=
v><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Does anyb=
ody think something else would happen, and do you think that ANYBODY would =
stick to the 5% fork in the face of enormously long transaction confirmatio=
n times (~3 hours), a huge transaction backlog as lots of the 95%&#39;ers t=
ry to sell their coins before the price drops, and a massive price drop for=
 coins on the 5% fork.<br clear=3D"all"><div><br></div>-- <br><div class=3D=
"gmail_signature">--<br>Gavin Andresen<br></div><div class=3D"gmail_signatu=
re"><br></div>
</div></div>

--001a11c1ccfa74bff90520e34b81--