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
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 36CBD86
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 16 Nov 2015 12:06:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yk0-f173.google.com (mail-yk0-f173.google.com
[209.85.160.173])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ED1C3148
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 16 Nov 2015 12:06:49 +0000 (UTC)
Received: by ykdr82 with SMTP id r82so233909433ykd.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 16 Nov 2015 04:06:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=jtimon_cc.20150623.gappssmtp.com; s=20150623;
h=mime-version:date:message-id:subject:from:to:cc:content-type
:content-transfer-encoding;
bh=+PbxUE/MggKIvU1gJvpD/aRkESV36kFMa8ypM9CRWRs=;
b=WnmQTDzJUx2E+5vOkbczHj1wWbLZ59li9JPbtJAxY6RZUwLdNDAQHQJG/DRf1y3JiD
Bku2XvrQvUFBK1CfDp2pjoQvKvgFgE1byVCuq0BlSx/XRbx1Ht0J2Pqft5H0sD84Uidz
9Ax3iQQ7ACERIm7zXwqSWS+1GB+Sn/Mq+1ShgrchrbE3o7qemuUoW9wpMO4MWfeDgJ2Z
V5pP9kgBkell/KCgA+JO9D9v3ZTdJM+CYGsXLfovldRENGxaIL/DwkEoq/WhmvS4QS89
I/bKrqfJM3ZSWujMsVJMC7byk3KI4T3OTbmpGDdRtOLAsIXYvIE8fqIEnMZKJ4Pwb6PW
l7AQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc
:content-type:content-transfer-encoding;
bh=+PbxUE/MggKIvU1gJvpD/aRkESV36kFMa8ypM9CRWRs=;
b=SFctzVaEtXU2aZbfwd9GHbs2StCb4nNGw0i3AH+BnYZcFarX4nWy6VqRL1+eYigFq2
bUfBfnEuDr7JcjU2NKXKFuxHzH/Io3mhYemsiNcqEViVC+BxTqZQ21YKELgoOJMKdEWw
X7zTy675ce2DfVcJlk9A7mUjKw3984OIS7ygiA+TdmA+rZxGP0URFfD/+vY1HnQi0lSH
plbjImIH7lksXqE2vPDYsDcce+iwGgVl0sKudm4WhNn9gVwMBQUWvO0cWTRTpDUgWsVb
C6lUia2hLqsutVqoSotJ2fJ4y0MwkVKxKmbetE2Vn5YN3ECdpJI1HafzEbfgxc8fQ8Ah
eIfg==
X-Gm-Message-State: ALoCoQk7GhyIASKz7lhUWZ8SU/gahOFTu47DQqcefDswJF7V6gX3IMEpSXKoqCPaqGI7BplsJ9sL
MIME-Version: 1.0
X-Received: by 10.129.115.68 with SMTP id o65mr6787489ywc.166.1447675609133;
Mon, 16 Nov 2015 04:06:49 -0800 (PST)
Received: by 10.31.132.147 with HTTP; Mon, 16 Nov 2015 04:06:49 -0800 (PST)
Date: Mon, 16 Nov 2015 13:06:49 +0100
Message-ID: <CABm2gDocOYndT7y44LwrN7PFXMcz4ABRLAEpdYPqqF_+1A368w@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Rusty Russell <rusty@rustcorp.com.au>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,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
X-Mailman-Approved-At: Mon, 16 Nov 2015 13:40:57 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] BIP99 and Schism hardforks lifecycle (was Switching
Bitcoin Core to sqlite db)
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: Mon, 16 Nov 2015 12:06:51 -0000
On Mon, Nov 16, 2015 at 2:52 AM, Rusty Russell <rusty@rustcorp.com.au> wrot=
e:
> We have strayed far from both the Subject line and from making progress
> on bitcoin development. Please redirect to bitcoin-discuss.
>
> I have set the moderation bits on the three contributors from here down
> (CC'd): your next post will go to moderation.
Sorry for going out of topic on that thread, I have just created
another thread to discuss this particular point (whether schism
hardforks can be universally predicted to collapse into a single chain
or not), which is a fundamental part of BIP99 discussion and I believe
technical enough for this list (assuming that we stay on topic). But
the moderation thinks it's not relevant enough for this list, we can
move it to the discussion mailing list or private emails.
On Sun, Nov 15, 2015 at 6:06 PM, Peter R <peter_r@gmx.com> wrote:
>> I am not convinced that Bitcoin even *has* a block size limit, let alone
>> that it can enforce one against the invisible hand of the market.
>
Jorge Tim=C3=B3n said:
> You keep insisting that some consensus rules are not consensus rules whil=
e
> others "are clearly a very different thing". What technical difference is
> there between the rule that impedes me from creating transactions bigger
> than X and the rules that prevent me frm creatin new coins (not as a mine=
r,
> as a regular user in a transaction with more coins in the outputs than in
> the inputs)?
>
On Sun, Nov 15, 2015 at 6:06 PM, Peter R <peter_r@gmx.com> wrote:
> I think you=E2=80=99re using the term =E2=80=9Ctechnical difference=E2=80=
=9D to mean something very
> specific. Perhaps you could clarify exactly how you are defining that te=
rm
> because to me it is crystal clear that creating coins out of thin air is
> very different than accepting a block 1.1 MB in size and full of valid TX=
s.
> There are many technical differences between the two. For example,
> technically the first allows coins to be created randomly while the secon=
d
> doesn=E2=80=99t.
Of course, their technical difference come from the fact they are
technically different. That's not what I meant.
There's no technical argument that lets you predict whether
eliminating one rule or the other will be more or less acceptable to
users.
There's no technical difference that I can see in that reward.
I think these two examples strike people as "obviously different" just
because they are morally different, but I want to avoid moral
judgments in BIP99.
> It is fact that two competing forks can persist for at least a short amou=
nt
> of time=E2=80=94we saw this a few years ago with the LevelDB bug and agai=
n this
> summer with the SPV mining incident. In both cases, there was tremendous
> pressure to converge back to a single chain.
Those were unintentional hardforks. There's an example of a failed
schism hardfork: when some people changed the subsidy/issuance rules
to maintain the 50 btc block subsidy constant.
It didn't failed because of "tremendous pressure": it failed because
the users and miners of the alternative ruleset abandoned it. If they
hadn't, the two incompatible chains would still grow in parallel.
> Could two chains persist indefinitely? I don=E2=80=99t know. No one kno=
ws. My gut
> feeling is that since users would have coins on both sides of the fork,
> there would be a fork arbitrage event (a =E2=80=9Cforkbitrage=E2=80=9D) w=
here speculators
> would sell the coins on the side they predict to lose in exchange for
> additional coins on the side they expect to win. This could actually be
> facilitated by exchanges once the fork event is credible and before the f=
ork
> actually occurs, or even in a futures market somehow. I suspect that the
> forkbitrage would create an unstable equilibrium where coins on one side
> quickly devalue. Miners would then abandon that side in favour of the
> other, killing the fork because difficulty would be too high to find new
> blocks. Anyways, I think even *this* would be highly unlikely. I suspec=
t
> nodes and miners would get inline with consensus as soon as the fork even=
t
> was credible.
Yes, there could be arbitrage and speculators selling "on both sides"
is also a possibility.
At some point we would arrive to some kind of price equilibrium,
different for each of the coins. BIP99 states that those prices are
unpredictable (or at least there's no general method to predict the
result without knowing the concrete case, the market, etc) and in fact
states that the resulting price for both sides could be going to close
to zero market capitalization.
That still doesn't say anything about one side having to "surrender".
The coin that ends up with the lowest price (and consequently, the
lowest block reward and hashrate) can still continue, maybe even for
longer than the side that appeared to be "victorious" after the
initial arbitrage.
I haven't heard any convincing arguments about schism hardforks having
to necessarily collapse into a single chain and until I do I'm not
going to adapt BIP99 to reflect that.
On Sun, Nov 15, 2015 at 11:22 PM, Corey Haddad <corey3@gmail.com> wrote:
> On Sun, Nov 15, 2015 at 2:12 AM, Jorge Tim=C3=B3n
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
>>If the invisible hand of the market is what decides consensus rules inste=
ad
>> of their (still incomple) specification (aka libconsensus), then the mar=
ket
>> could decide to stop enforcing ownership. Will you still think that Bitc=
oin
>> is a useful system when/if you empirically observe the invisible hand of=
the
>> market taking coins out of your pocket?
>
> The market, which in this instance I take to mean the economic majority,
> could absolutely decide to stop enforcing ownership of certain coins, eve=
n
> arbitrarily ascribing them to a different address. That's not something =
any
> of us have any control over, and that reality must be acknowledged.
> Bitcoins have value is due to collective behavior. We can provide tools =
to
> help people reach a common understanding, but the tools cannot force peop=
le
> to reach a certain conclusion.
Yes, I have control: all users (including miners) have direct control
over the rules that software they run validates.
You cannot ever have your coins stolen in the longest valid chain you
follow if the validity rules you use enforce property ownership.
No majority can force you to move to the new non-ownership rules, just
like no majority can force you to move to any different set of rules.
If we accept the notion that a groups of users could resist to
deploying this particular rule changes and keep operating under the
old rules, we have to accept that this can happen for any
controversial hardfork, and that we cannot predict a common lifecycle
for all schism hardforks.
|
