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: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1713B49F
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jul 2015 16:52:22 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com
[209.85.213.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 89ED9115
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jul 2015 16:52:21 +0000 (UTC)
Received: by igvi1 with SMTP id i1so134015703igv.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jul 2015 09:52:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type; bh=Fd+pepMNH+E33L2f3MG16Fe7DBKFa2GJUOeHTDpXJMg=;
b=z9WEBOXQZtmgxCXjOnLcGU72VsYMF6jm0Th5WuF/mbUdWr2f+NDWIxyCs60MmcryO/
f18RSCugsHSg5dQmhhTWaQteTHF4j2WpV+Qjks/7UYvD7Vj15d/hQ6hjLysJfao7H9tA
oIb8TvMSZStYwoZcTCsArn1Xc3it+aH8Lp4KZsU5DOiSAVX3Eg/E21bOrazsDmiYL3ei
18FkaIhVN9sLO5Podb8utYz5whlA4nT7SNhGu0EEgXWLDW9vYQkrgZy77FUqhh2VCxRn
jVGDelkSNaC7/NYA+oYjEaeAFrxLGmse7DiXK5NMS/NvJTTJK3FQhm/z8vaRzXTGgeT3
k2Ig==
MIME-Version: 1.0
X-Received: by 10.107.169.138 with SMTP id f10mr6870497ioj.75.1437583941015;
Wed, 22 Jul 2015 09:52:21 -0700 (PDT)
Received: by 10.36.77.201 with HTTP; Wed, 22 Jul 2015 09:52:20 -0700 (PDT)
Received: by 10.36.77.201 with HTTP; Wed, 22 Jul 2015 09:52:20 -0700 (PDT)
In-Reply-To: <CAPg+sBgs-ouEMu=LOVCmOyCGwfM1Ygxooz0shyvAuHDGGZYfJw@mail.gmail.com>
References: <CAPg+sBgs-ouEMu=LOVCmOyCGwfM1Ygxooz0shyvAuHDGGZYfJw@mail.gmail.com>
Date: Wed, 22 Jul 2015 12:52:20 -0400
Message-ID: <CAPg+sBgugLSVEwDLXhgey86_rM2fTjGWXFuXsiZioJKCZiHiNg@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a11425d0623a208051b799817
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_40,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
Subject: [bitcoin-dev] Bitcoin Core and hard forks
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: Wed, 22 Jul 2015 16:52:22 -0000
--001a11425d0623a208051b799817
Content-Type: text/plain; charset=UTF-8
Hello all,
I'd like to talk a bit about my view on the relation between the Bitcoin
Core project, and the consensus rules of Bitcoin.
I believe it is the responsibility of the maintainers/developers of Bitcoin
Core to create software which helps guarantee the security and operation of
the Bitcoin network.
In addition to normal software maintenance, bug fixes and performance
improvements, this includes DoS protection mechanism deemed necessary to
keep the network operational. Sometimes, such (per-node configurable)
policies have had economic impact, for example the dust rule.
This also includes participating in discussions about consensus changes,
but not the responsibility to decide on them - only to implement them when
agreed upon. It would be irresponsible and dangerous to the network and
thus the users of the software to risk forks, or to take a leading role in
pushing dramatic changes. Bitcoin Core developers obviously have the
ability to make any changes to the codebase or its releases, but it is
still up to the community to choose to run that code.
Some people have called the prospect of limited block space and the
development of a fee market a change in policy compared to the past. I
respectfully disagree with that. Bitcoin Core is not running the Bitcoin
economy, and its developers have no authority to set its rules. Change in
economics is always happening, and should be expected. Worse, intervening
in consensus changes would make the ecosystem more dependent on the group
taking that decision, not less.
So to point out what I consider obvious: if Bitcoin requires central
control over its rules by a group of developers, it is completely
uninteresting to me. Consensus changes should be done using consensus, and
the default in case of controversy is no change.
===
My personal opinion is that we - as a community - should indeed let a fee
market develop, and rather sooner than later, and that "kicking the can
down the road" is an incredibly dangerous precedent: if we are willing to
go through the risk of a hard fork because of a fear of change of
economics, then I believe that community is not ready to deal with change
at all. And some change is inevitable, at any block size. Again, this does
not mean the block size needs to be fixed forever, but its intent should be
growing with the evolution of technology, not a panic reaction because a
fear of change.
But I am not in any position to force this view. I only hope that people
don't think a fear of economic change is reason to give up consensus.
--
Pieter
--001a11425d0623a208051b799817
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Hello all,</p>
<p dir=3D"ltr">I'd like to talk a bit about my view on the relation bet=
ween the Bitcoin Core project, and the consensus rules of Bitcoin.</p>
<p dir=3D"ltr">I believe it is the responsibility of the maintainers/develo=
pers of Bitcoin Core to create software which helps guarantee the security =
and operation of the Bitcoin network.</p>
<p dir=3D"ltr">In addition to normal software maintenance, bug fixes and pe=
rformance improvements, this includes DoS protection mechanism deemed neces=
sary to keep the network operational. Sometimes, such (per-node configurabl=
e) policies have had economic impact, for example the dust rule.</p>
<p dir=3D"ltr">This also includes participating in discussions about consen=
sus changes, but not the responsibility to decide on them - only to impleme=
nt them when agreed upon. It would be irresponsible and dangerous to the ne=
twork and thus the users of the software to risk forks, or to take a leadin=
g role in pushing dramatic changes. Bitcoin Core developers obviously have =
the ability to make any changes to the codebase or its releases, but it is =
still up to the community to choose to run that code.</p>
<p dir=3D"ltr">Some people have called the prospect of limited block space =
and the development of a fee market a change in policy compared to the past=
. I respectfully disagree with that. Bitcoin Core is not running the Bitcoi=
n economy, and its developers have no authority to set its rules. Change in=
economics is always happening, and should be expected. Worse, intervening =
in consensus changes would make the ecosystem more dependent on the group t=
aking that decision, not less.</p>
<p dir=3D"ltr">So to point out what I consider obvious: if Bitcoin requires=
central control over its rules by a group of developers, it is completely =
uninteresting to me. Consensus changes should be done using consensus, and =
the default in case of controversy is no change.</p>
<p dir=3D"ltr">=3D=3D=3D</p>
<p dir=3D"ltr">My personal opinion is that we - as a community - should ind=
eed let a fee market develop, and rather sooner than later, and that "=
kicking the can down the road" is an incredibly dangerous precedent: i=
f we are willing to go through the risk of a hard fork because of a fear of=
change of economics, then I believe that community is not ready to deal wi=
th change at all. And some change is inevitable, at any block size. Again, =
this does not mean the block size needs to be fixed forever, but its intent=
should be growing with the evolution of technology, not a panic reaction b=
ecause a fear of change.</p>
<p dir=3D"ltr">But I am not in any position to force this view. I only hope=
that people don't think a fear of economic change is reason to give up=
consensus.</p>
<p dir=3D"ltr">-- <br>
Pieter</p>
--001a11425d0623a208051b799817--
|
