summaryrefslogtreecommitdiff
path: root/0d/800205bbce6bc9abd31aaa332ad48eb58de648
blob: 1d81833e8c8f4688b4e1255d7579b2a8b4a1c0d7 (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
165
166
167
168
169
170
171
172
173
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 1393A74
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 15 Nov 2015 10:12:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f43.google.com (mail-vk0-f43.google.com
	[209.85.213.43])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 75C3A13F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 15 Nov 2015 10:12:23 +0000 (UTC)
Received: by vkgy188 with SMTP id y188so13942364vkg.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 15 Nov 2015 02:12:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=jtimon_cc.20150623.gappssmtp.com; s=20150623;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=DaTiBls9IRs2mxkJsDQzAykiZ79IU5C5G9xK8KwEmas=;
	b=CA4A8ppiUY2IKSKGsqyHL7biI1ulngxHY6TBDBTdAnzwF9IxWXucCMLmmHO7gtkvr6
	+v1BESl8HtJ6Mq+hOI5ZoIlawMphEvd2jWQlTYMe2m3ecApyziHBhPr3mgk+GArVDzFK
	8fEPuQVVBLh2OxqqvG3Gx3HQY20GQDlFlbxc8269YEFkeWccd5PF6MjCyzq+5kvUC6Af
	p5yy1z/P8sIPm+NfRmSbdLWRwcFL6KE96l+h9ae3Tn/daBkhnHWMZdYnOtFSoRsEN0cJ
	yK2EnOvd7nI9/wx7ArowRYL52VwbMfudnGWdsv7VD1WQyy2KMh2FMudXMTtq8h5k+cH4
	qdQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=DaTiBls9IRs2mxkJsDQzAykiZ79IU5C5G9xK8KwEmas=;
	b=A+oRuL2VdLWrswM25c6KLEFDmvoQfenUE3hwwKuk64wSVm6gU/ZrFHx82ac/FeE/9x
	aUEnTnq/zRXkIwN5vuR+f/vlkYs3kOVLt+X6jXNsV+b2ohQQcAWlf8mtrAq2YC6+BPTB
	of4l6iNgBOXQRWQ+XGiXD3N6LMj3ngvgFIYbp6HCUHJ6pk3cJF1jTwsOVqVpi2DNKae9
	MIcBq1HJjXiQ2opSEu7oOOa1qrMHf0CCuhALG51Rd2z2ayKbQ70dmPuvhKq+b0zjpPin
	2LLZrz2VtI9klzEfNp8HaUhAYjUVQ+v0OsmcC2/9ArtTRAxgGBqZ+2iH1t+fCiLUJ+zw
	IG3w==
X-Gm-Message-State: ALoCoQmnRKZUxvUt9XhB6DAC1K5kX+q84E9QGfLtLkUrJfgtGlflNV7YO+LvWaT583P0FW1wX88C
MIME-Version: 1.0
X-Received: by 10.31.11.197 with SMTP id 188mr6997603vkl.2.1447582342693; Sun,
	15 Nov 2015 02:12:22 -0800 (PST)
Received: by 10.31.132.147 with HTTP; Sun, 15 Nov 2015 02:12:22 -0800 (PST)
Received: by 10.31.132.147 with HTTP; Sun, 15 Nov 2015 02:12:22 -0800 (PST)
In-Reply-To: <2C8EBBD8-51B7-4F47-AFFA-3870DBD6C4EA@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>
Date: Sun, 15 Nov 2015 11:12:22 +0100
Message-ID: <CABm2gDrEymffZXRqkYij0eCR3Rg6x1w_=AUJpb3NxHwQ-q48aQ@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Peter R <peter_r@gmx.com>
Content-Type: multipart/alternative; boundary=001a1144211a51db640524918796
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,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>,
	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 10:12:24 -0000

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

On Nov 15, 2015 5:10 AM, "Peter R via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> What rules does Bitcoin obey?

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.

> 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.

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)? 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.
Will you still think that Bitcoin is a useful system when/if you
empirically observe the invisible hand of the market taking coins out of
your pocket?

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), just like when the
implementation of the rules diverge in a unintentional consensus fork. But
in this case they could decide to never implement the same rules.
See bip99 and specially the "schism hardforks" section for more details.

> You were the one who just brought up politics, Greg.  Not I.

Please, read the thread again. I think it is pretty clear that you did.
Nothing wrong with that, just move it to the discussion ml.

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

<p dir=3D"ltr"><br>
On Nov 15, 2015 5:10 AM, &quot;Peter R via bitcoin-dev&quot; &lt;<a href=3D=
"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfound=
ation.org</a>&gt; wrote:<br>
&gt;<br>
&gt; What rules does Bitcoin obey?=C2=A0</p>
<p dir=3D"ltr">Thanks to the worl of many people, part of the consensus rul=
es are finally encapsulated in the libbitcoinconsensus library. I&#39;m cur=
rently writing a document to complete the encapsulation of the specificatio=
n of the consensus rules.</p>
<p dir=3D"ltr">&gt; 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">You keep insisting that some consensus rules are not consens=
us rules while others &quot;are clearly a very different thing&quot;. What =
technical difference is there between the rule that impedes me from creatin=
g 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 i=
n the outputs than in the inputs)? What about property enforcement? If the =
invisible hand of the market is what decides consensus rules instead of the=
ir (still incomple) specification (aka libconsensus), then the market could=
 decide to stop enforcing ownership.<br>
Will you still think that Bitcoin is a useful system when/if you empiricall=
y observe the invisible hand of the market taking coins out of your pocket?=
</p>
<p dir=3D"ltr">You also keep assuming that somehow it is a universal law th=
at users must eventually converge under the most-work chain. People follow =
the most-work VALID chain, but if they consciously decide to implement diff=
erent rules (different definitions of &quot;valid block&quot;) then their c=
hains can diverge, and once they do they won&#39;t converge again (unless/u=
ntil one group decides to implement the rules of the other exactly again), =
just like when the implementation of the rules diverge in a unintentional c=
onsensus fork. But in this case they could decide to never implement the sa=
me rules.<br>
See bip99 and specially the &quot;schism hardforks&quot; section for more d=
etails.</p>
<p dir=3D"ltr">&gt; You were the one who just brought up politics, Greg.=C2=
=A0 Not I.</p>
<p dir=3D"ltr">Please, read the thread again. I think it is pretty clear th=
at you did. Nothing wrong with that, just move it to the discussion ml.</p>

--001a1144211a51db640524918796--