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
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
|
Return-Path: <peter_r@gmx.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D6A2D7A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 15 Nov 2015 17:19:50 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6222B13D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 15 Nov 2015 17:19:49 +0000 (UTC)
Received: from [192.168.50.29] ([69.50.179.106]) by mail.gmx.com (mrgmx003)
with ESMTPSA (Nemesis) id 0LgZRV-1alb3D3dLR-00nxfG;
Sun, 15 Nov 2015 18:07:03 +0100
Content-Type: multipart/alternative;
boundary="Apple-Mail=_9E440E5C-41D1-4F34-8EBA-776F0B3F18AA"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Peter R <peter_r@gmx.com>
In-Reply-To: <CABm2gDrEymffZXRqkYij0eCR3Rg6x1w_=AUJpb3NxHwQ-q48aQ@mail.gmail.com>
Date: Sun, 15 Nov 2015 09:06:58 -0800
Message-Id: <D64AA4C7-BB66-41B2-A001-107985071DA1@gmx.com>
References: <5631C363.5060705@neomailbox.net>
<201510290803.52734.luke@dashjr.org>
<5632DE33.7030600@bitcartel.com>
<CAAS2fgTga_vTfOKrFu_hEzXSfTfg9FRfJ6aL6ginuGFqnbm7=w@mail.gmail.com>
<3CB90C47-293E-4C18-A381-E5203483D68F@gmx.com>
<CAAS2fgRdK4bDr3x_y9UpdH234PQSfD7U539HBLA==+hLQJ_7Fw@mail.gmail.com>
<571D9B7F-077D-4B80-B577-1C18FF2ECF31@gmx.com>
<CAAS2fgTLE1cpDqKTiy0r1VMex7zTAB8tgUC=Y0WXmbNBJL42xQ@mail.gmail.com>
<6DAD1D38-A156-4507-B506-BF66F26E6594@gmx.com>
<CAAS2fgT+r4aRPe7Qjww6wgbAzkwafN+340pUaVO9F7MZEVY-zA@mail.gmail.com>
<13D7C936-4D2E-4BAC-AC61-3DA80581C946@gmx.com>
<CAAS2fgTuty0OCxJvZwU+BCPXG-VuJxtwCPVMvL7Xbze=OjSSdA@mail.gmail.com>
<2C8EBBD8-51B7-4F47-AFFA-3870DBD6C4EA@gmx.com>
<CABm2gDrEymffZXRqkYij0eCR3Rg6x1w_=AUJpb3NxHwQ-q48aQ@mail.gmail.com>
To: =?utf-8?Q?Jorge_Tim=C3=B3n?= <jtimon@jtimon.cc>
X-Mailer: Apple Mail (2.2104)
X-Provags-ID: V03:K0:gJPyxGyuBAoEAKuw8DJy/EXzk1p6ApAHcJ8fI4VocKkTAPhA3gv
VYO6ugplwhGNuBphAGCFeKYPWoliEZoMexqsgkvCFkUyloaj1zpd3r3yEEnH7Y3HRg4oxzi
x61eZGrNCcmLI/mYqHeLTgwygH+n/G5Je5ko2Lx35mLyAqreRbHkRkYA/sS0uP9/E0LxW1O
rUvSGVTw/xO6o5s4ORS5Q==
X-UI-Out-Filterresults: notjunk:1;V01:K0:KEOX/5GF+VY=:nePGWGYDQ3B3HkZDnidBDI
zVco6e/FjvDtDHp7Vj/GMSHtHrIswSil4HfXp3lzP98Axn2YTMFIn/XW+FIdStgYOKMfc+Jpt
Ii6H/nFC1tRbFB1PmcAwnTxbyroWeKK9zK+vcEIzSLFV/jEfG57BeetL5GyQzcVNaR6MFLZKq
CXVpuPUpnOBrlseY5n34eDXB7dJpIKSw7tiMR9ekcG9J5vimvKPDW1bH3OMWCi+XBNZfVaBu7
oE0zQn38RKqQTs+hJ0gHpZp56ic+xYv2CAtudE6gPdHFamHZcBJbA91Y0UdIx6jTtQNxRdeYV
/q4Yymy5iTncbnXFXmtIJo7s9pKHDxUJZ4BgSIbB8HMSuBs1CCuWNMes5r0ddQFXz1uqcA9uE
meICcpoAibHFjXBNDbFX6vH8nlfa/45lAPoEF25kZ75ByTdR9Y/uFTWLxnqDS1VdK01EmTKdL
jZUPZvGYSO0qxRSQxvHA0HbsrGBmR63QpTqnVxh/7vOlqMYFE+WerlqWRgYULnHsY/Ag51g5s
OWF+Je/v9N8J27gDGUhNIvMKwryen8mVKZD0NfJw2FeHJpYNfbu8GejK0HdJ1208RFB1XpCO8
I4Lr6P1ftLCKB5WK1ex/jUyJwibjQHMvpOy0w106wtKyfm7uQogVocoadQsgHZarvZZ1yFWQj
A7VW+wQiwGVxV0VOxQky8SYOt+07m/ztCKDe6dcWwhU+aoOWpKPBXwUeBYwU2DLdbKW1dFUZL
1PaVRCCgWE8ofcl2T8bTqCl433HG7pZI0DyuJZ7DzX3oPsFpE7f9cV1sFkXZgEwJPIzS15Ebv
QZSyd8q
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
HTML_MESSAGE, MIME_QP_LONG_LINE,
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>,
Gregory Maxwell <gmaxwell@gmail.com>, telemaco <telemaco@neomailbox.net>
Subject: Re: [bitcoin-dev] [patch] 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: Sun, 15 Nov 2015 17:19:51 -0000
--Apple-Mail=_9E440E5C-41D1-4F34-8EBA-776F0B3F18AA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
Hello Jorge:
> > What rules does Bitcoin obey?=20
>=20
> Thanks to the worl of many people, part of the consensus rules are =
finally encapsulated in the libbitcoinconsensus library. I'm currently =
writing a document to complete the encapsulation of the specification of =
the consensus rules.
>=20
I applaud your work on the consensus library. I think it an important =
step to encouraging multiple competing implementations of the protocol.
> > 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.
>=20
> You keep insisting that some consensus rules are not consensus rules =
while 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 miner, as a regular user in a transaction with more =
coins in the outputs than in the inputs)?
>=20
What technical difference is there between a cat and a dog? They both =
have four legs and a furry coat.=20
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 term 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 TXs. There are many technical =
differences between the two. For example, technically the first allows =
coins to be created randomly while the second doesn=E2=80=99t. =20
> What about property enforcement? If the invisible hand of the market =
is what decides consensus rules instead of their (still incomple) =
specification (aka libconsensus), then the market could decide to stop =
enforcing ownership.
>=20
Correct. Bitcoin is an experiment and could still fail (e.g., the =
network could allow people to move coins without valid signatures). For =
Bitcoin to be viable, the network of miners and node operators being =
net-econo-rational actually is probably a core axiom that must be =
accepted. =20
> You also keep assuming that somehow it is a universal law that users =
must eventually converge under the most-work chain. People follow the =
most-work VALID chain, but if they consciously decide to implement =
different rules (different definitions of "valid block") then their =
chains can diverge, and once they do they won't converge again =
(unless/until one group decides to implement the rules of the other =
exactly again)
>=20
It is fact that two competing forks can persist for at least a short =
amount of time=E2=80=94we saw this a few years ago with the LevelDB bug =
and again this summer with the SPV mining incident. In both cases, =
there was tremendous pressure to converge back to a single chain.
Could two chains persist indefinitely? I don=E2=80=99t know. No one =
knows. 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) where 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 fork 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 =
suspect nodes and miners would get inline with consensus as soon as the =
fork event was credible. =20
Cryptocurrency is a new area of interdisciplinary research. We are all =
learning together and no one knows how things will unfold. =20
Best regards,
Peter
--Apple-Mail=_9E440E5C-41D1-4F34-8EBA-776F0B3F18AA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D"">Hello Jorge:<br class=3D""><div><blockquote type=3D"cite" =
class=3D""><div class=3D""><p dir=3D"ltr" class=3D"">
> What rules does Bitcoin obey? </p><p dir=3D"ltr" =
class=3D"">Thanks to the worl of many people, part of the consensus =
rules are finally encapsulated in the libbitcoinconsensus library. I'm =
currently writing a document to complete the encapsulation of the =
specification of the consensus rules.</p></div></blockquote><div>I =
applaud your work on the consensus library. I think it an =
important step to encouraging multiple competing implementations of the =
protocol.</div><blockquote type=3D"cite" class=3D""><div class=3D""><p =
dir=3D"ltr" class=3D"">> 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.</p><p dir=3D"ltr" class=3D"">You keep =
insisting that some consensus rules are not consensus rules while 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 miner, =
as a regular user in a transaction with more coins in the outputs than =
in the inputs)? </p></div></blockquote><div>What technical difference is =
there between a cat and a dog? They both have four legs and a furry =
coat. </div><div><br class=3D""></div><div>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 term 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 TXs. There are many technical differences =
between the two. For example, technically the first allows coins to be =
created randomly while the second doesn=E2=80=99t. =
</div><blockquote type=3D"cite" class=3D""><p dir=3D"ltr" =
class=3D"">What about property enforcement? If the invisible hand of the =
market is what decides consensus rules instead of their (still incomple) =
specification (aka libconsensus), then the market could decide to stop =
enforcing ownership.<br class=3D""></p></blockquote><div>Correct. =
Bitcoin is an experiment and could still fail (e.g., the network =
could allow people to move coins without valid signatures). For =
Bitcoin to be viable, the network of miners and node operators being =
net-econo-rational actually is probably a core axiom that must be =
accepted. </div><blockquote type=3D"cite" class=3D""><p dir=3D"ltr" =
class=3D"">You also keep assuming that somehow it is a universal law =
that users must eventually converge under the most-work chain. People =
follow the most-work VALID chain, but if they consciously decide to =
implement different rules (different definitions of "valid block") then =
their chains can diverge, and once they do they won't converge again =
(unless/until one group decides to implement the rules of the other =
exactly again)</p></blockquote>It is fact that two competing forks can =
persist for at least a short amount of time=E2=80=94we saw this a few =
years ago with the LevelDB bug and again this summer with the SPV mining =
incident. In both cases, there was tremendous pressure to converge =
back to a single chain.</div><div><br class=3D""></div><div>Could two =
chains persist indefinitely? I don=E2=80=99t know. No one =
knows. 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) where 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 fork 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 suspect nodes and miners would get inline with consensus as soon =
as the fork event was credible. </div><div><br =
class=3D""></div><div>Cryptocurrency is a new area of interdisciplinary =
research. We are all learning together and no one knows how things =
will unfold. </div><div><br class=3D""></div><div>Best =
regards,</div><div>Peter</div><br class=3D""></body></html>=
--Apple-Mail=_9E440E5C-41D1-4F34-8EBA-776F0B3F18AA--
|
