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
|
Return-Path: <hectorchu@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 18C419C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 1 Aug 2015 08:44:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com
[209.85.217.171])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 020608F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 1 Aug 2015 08:44:17 +0000 (UTC)
Received: by lbqc9 with SMTP id c9so32406277lbq.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 01 Aug 2015 01:44:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-type;
bh=r2CgLAN0lkJ/BJSrEyk8R/MvTt/Ta/clOvdaU34EjL0=;
b=v2FI4BndjvJDJ6nnZ8+U0uVyXOWZBzUFP6k0IcgHN3lAfO4t5GfTkbly0A8MfHTN6z
gkHEd7kjeM8Q3TuBtx7bTUXDgOkdSihUqOKTbCdsHr7k5kz0EQgtk4R19mJJmfd9kOew
qUy+2uuk3Q0BEBEE8KNzw2ypAdB1bPo9x3wrXkIRzTBW8x/pgLoQHvpAQYzXGtvQr+0g
TbE7Xlb8ZHeGb7jyzbnS9OsvQ5k5n154yOAp/9S7khO92koG7Rwj9rInBApi5aR8ghSX
QgZ0rDYc+XBd+ImUeYjjd0gUoE5+o10nbhWXc3dZhfrvJZHVheEcOCQW5v7F4cB+cOMX
T/3A==
X-Received: by 10.152.182.194 with SMTP id eg2mr7465337lac.71.1438418656260;
Sat, 01 Aug 2015 01:44:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.21.94 with HTTP; Sat, 1 Aug 2015 01:43:56 -0700 (PDT)
In-Reply-To: <CAAS2fgQL_0W0i5j0DVBY2dVtZzBj6sryycMG3Q-5KrTd1tpWaw@mail.gmail.com>
References: <CAAO2FKFQjjftgEgZoDAUrMxa86KTbNzAqg+xgExTRPpGxedwRw@mail.gmail.com>
<CAAS2fgQL_0W0i5j0DVBY2dVtZzBj6sryycMG3Q-5KrTd1tpWaw@mail.gmail.com>
From: Hector Chu <hectorchu@gmail.com>
Date: Sat, 1 Aug 2015 09:43:56 +0100
Message-ID: <CAAO2FKH4txfNxz9H51YPm+5hMaZ+w16gBhpF5ztvbef4ar3K8w@mail.gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=001a113491f20b79f5051c3bf1ae
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,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: Re: [bitcoin-dev] Block size 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: Sat, 01 Aug 2015 08:44:19 -0000
--001a113491f20b79f5051c3bf1ae
Content-Type: text/plain; charset=UTF-8
On 1 August 2015 at 01:17, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> One can quite easily transact in a way to intentionally produce such a
> split to seperate the existance of your coins onto the seperate forks;
> just as anyone would need to do to perform a reorg-and-respend attack
> on a single blockchain.
>
Right. Why anyone would want to do this intentionally, however, is not
clear. The coins would be worth less as they wouldn't be fungible across
the chains anymore.
Additionally, new coins will be issued, along with fees, on both
> chains. These new outputs become spendable after 100 blocks, and any
> transaction spending them can exist exclusively on one chain.
>
This is something that hadn't entered my mind when I made my assertions. At
the moment I can't see any way to avoid this fact.
Also any transaction whos casual history extends from one of the above
> cases can exist only on one chain. This also means that someone who
> has single-chain coins (via a conflict or from coinbase outputs) can
> pay small amount to many users to get their wallets to consume them
> and make more of the transactions single chain only-- if they wanted
> the process to happen faster.
>
Wallets could detect this and notify the user. Due to Gresham's Law, I'll
admit the observation that these outputs would likely get spent in
preference (as they are less fungible), but whether the payee would be
happy to accept them is a different matter.
> Miners will migrate to the bigger chain in search of higher profits due
> to higher volume of fees
>
> The migration remark is a considerable oversimplification. Imagine if
> I released a version of the software programmed to reassign ownership
> of a million of the earliest created unmoved coins to me at block
> 400k, and then after that I made transaction to pay 5 coin/block in
> fees. Would miners move to this chain? It pays more in fees!
>
Well in your example they wouldn't, because they know that your version
wouldn't be accepted by the economic majority. But it's not as clear cut
for the larger blocks case. They may move over gradually as they see the
new chain gain acceptance, demonstrated by the higher trading volume on it.
--001a113491f20b79f5051c3bf1ae
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">On 1=
August 2015 at 01:17, Gregory Maxwell <span dir=3D"ltr"><<a href=3D"mai=
lto:gmaxwell@gmail.com" target=3D"_blank">gmaxwell@gmail.com</a>></span>=
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">One can quite easily transact in =
a way to intentionally produce such a<br>
split to seperate the existance of your coins onto the seperate forks;<br>
just as anyone would need to do to perform a reorg-and-respend attack<br>
on a single blockchain.<br></blockquote><div><br></div><div>Right. Why anyo=
ne would want to do this intentionally, however, is not clear. The coins wo=
uld be worth less as they wouldn't be fungible across the chains anymor=
e.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Additionally, new coins will be issued, along with fees, on both<br>
chains. These new outputs become spendable after 100 blocks, and any<br>
transaction spending them can exist exclusively on one chain.<br></blockquo=
te><div><br></div><div>This is something that hadn't entered my mind wh=
en I made my assertions. At the moment I can't see any way to avoid thi=
s fact.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also any transaction whos casual history extends from one of the above<br>
cases can exist only on one chain. This also means that someone who<br>
has single-chain coins (via a conflict or from coinbase outputs) can<br>
pay small amount to many users to get their wallets to consume them<br>
and make more of the transactions single chain only-- if they wanted<br>
the process to happen faster.<br></blockquote><div><br></div><div>Wallets c=
ould detect this and notify the user. Due to Gresham's Law, I'll ad=
mit the observation that these outputs would likely get spent in preference=
(as they are less fungible), but whether the payee would be happy to accep=
t them is a different matter.</div><div><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><span class=3D"">
> Miners will migrate to the bigger chain in search of higher profits du=
e to higher volume of fees<br>
<br>
</span>The migration remark is a considerable oversimplification. Imagine i=
f<br>
I released a version of the software programmed to reassign ownership<br>
of a million of the earliest created unmoved coins to me at block<br>
400k, and then after that I made transaction to pay 5 coin/block in<br>
fees. Would miners move to this chain?=C2=A0 It pays more in fees!<br></blo=
ckquote><div><br></div><div>Well in your example they wouldn't, because=
they know that your version wouldn't be accepted by the economic major=
ity. But it's not as clear cut for the larger blocks case. They may mov=
e over gradually as they see the new chain gain acceptance, demonstrated by=
the higher trading volume on it.=C2=A0</div></div><br></div></div>
--001a113491f20b79f5051c3bf1ae--
|
