summaryrefslogtreecommitdiff
path: root/67/3ba4d7c594ffea82b62ee418fad761ec589b60
blob: 99539f49c6f212fb887388def6800a609f1fca84 (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
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
235
236
237
238
Return-Path: <jrn@jrn.me.uk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id C36A4504
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jul 2015 17:18:47 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from homiemail-a9.g.dreamhost.com (homie.mail.dreamhost.com
	[208.97.132.208])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id AAC2015A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jul 2015 17:18:46 +0000 (UTC)
Received: from homiemail-a9.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a9.g.dreamhost.com (Postfix) with ESMTP id 3C75D62606E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jul 2015 10:18:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=jrn.me.uk; h=subject:to
	:references:from:message-id:date:mime-version:in-reply-to:
	content-type; s=jrn.me.uk; bh=CTN0xNU5fvcOe3Q1xN21bKwngg8=; b=Ae
	mQp8bxpUxkUJDa3sp2y41quEo/Xn+N7WkAGwXBxI4yUG9KJXkFmTeOwa9I2/gMdO
	rCi6Y2gF5ql6qHGxwPHTvsDZUZYYFvgT0sftWlaQrQxg7rvW51Q7ERD/zg8jsSMW
	RcB5AulT2VYplK5uKQv6xVXHnxjv8Li63pQWeu3e0=
Received: from [10.9.1.133] (unknown [89.238.129.18])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: jrn@jrn.me.uk)
	by homiemail-a9.g.dreamhost.com (Postfix) with ESMTPSA id 8E96062606A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jul 2015 10:18:45 -0700 (PDT)
To: bitcoin-dev@lists.linuxfoundation.org
References: <CAPg+sBgs-ouEMu=LOVCmOyCGwfM1Ygxooz0shyvAuHDGGZYfJw@mail.gmail.com>
	<CAPg+sBgugLSVEwDLXhgey86_rM2fTjGWXFuXsiZioJKCZiHiNg@mail.gmail.com>
From: Ross Nicoll <jrn@jrn.me.uk>
Message-ID: <55AFD075.1000806@jrn.me.uk>
Date: Wed, 22 Jul 2015 18:18:45 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
	Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <CAPg+sBgugLSVEwDLXhgey86_rM2fTjGWXFuXsiZioJKCZiHiNg@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------070905090506060105050601"
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,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: Re: [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 17:18:47 -0000

This is a multi-part message in MIME format.
--------------070905090506060105050601
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

So, if consensus shouldn't really be between the developers (which is 
fine), should we empower users to control consensus? I've been working 
on a fork framework anyway, which can support reasonably arbitrary 
consensus changes (currently against block height, but moving towards 
block time). Theoretically it could be modified to load consensus 
parameters (which block size would have to be added to) from disk at 
startup, rather than having them hard-coded.

Is that considered desirable? Will raise as a PR if so. If not, where do 
we draw a line between developer and user consensus?

Ross

On 22/07/2015 17:52, Pieter Wuille via bitcoin-dev wrote:
>
> 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
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--------------070905090506060105050601
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    So, if consensus shouldn't really be between the developers (which
    is fine), should we empower users to control consensus? I've been
    working on a fork framework anyway, which can support reasonably
    arbitrary consensus changes (currently against block height, but
    moving towards block time). Theoretically it could be modified to
    load consensus parameters (which block size would have to be added
    to) from disk at startup, rather than having them hard-coded.<br>
    <br>
    Is that considered desirable? Will raise as a PR if so. If not,
    where do we draw a line between developer and user consensus?<br>
    <br>
    Ross<br>
    <br>
    <div class="moz-cite-prefix">On 22/07/2015 17:52, Pieter Wuille via
      bitcoin-dev wrote:<br>
    </div>
    <blockquote
cite="mid:CAPg+sBgugLSVEwDLXhgey86_rM2fTjGWXFuXsiZioJKCZiHiNg@mail.gmail.com"
      type="cite">
      <p dir="ltr">Hello all,</p>
      <p dir="ltr">I'd like to talk a bit about my view on the relation
        between the Bitcoin Core project, and the consensus rules of
        Bitcoin.</p>
      <p dir="ltr">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.</p>
      <p dir="ltr">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.</p>
      <p dir="ltr">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.</p>
      <p dir="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 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.</p>
      <p dir="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="ltr">===</p>
      <p dir="ltr">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.</p>
      <p dir="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="ltr">-- <br>
        Pieter</p>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------070905090506060105050601--