summaryrefslogtreecommitdiff
path: root/4b/134431c9f0965a9ae75235797684c870b1b4be
blob: 2d12d75b2ae7fd7392005c4f3310d56f5f66a3ce (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
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pieter.wuille@gmail.com>) id 1Yy25O-0005Hm-BW
	for bitcoin-development@lists.sourceforge.net;
	Thu, 28 May 2015 17:59:18 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.180 as permitted sender)
	client-ip=209.85.214.180; envelope-from=pieter.wuille@gmail.com;
	helo=mail-ob0-f180.google.com; 
Received: from mail-ob0-f180.google.com ([209.85.214.180])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Yy25N-0002Kz-Is
	for bitcoin-development@lists.sourceforge.net;
	Thu, 28 May 2015 17:59:18 +0000
Received: by obbnx5 with SMTP id nx5so38921127obb.0
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 28 May 2015 10:59:12 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.82.97 with SMTP id h1mr3568789oey.71.1432835952154; Thu,
	28 May 2015 10:59:12 -0700 (PDT)
Received: by 10.60.94.36 with HTTP; Thu, 28 May 2015 10:59:11 -0700 (PDT)
Received: by 10.60.94.36 with HTTP; Thu, 28 May 2015 10:59:11 -0700 (PDT)
In-Reply-To: <COL131-DS24FC87C7C6622E23F5EF58CDCA0@phx.gbl>
References: <16096345.A1MpJQQkRW@crushinator>
	<CABsx9T3-zxCAagAS0megd06xvG5n-3tUL9NUK9TT3vt7XNL9Tg@mail.gmail.com>
	<CANEZrP3VCaFsW4+gPm2kCJ9z7oVUZYVaeNf=_cJWEWwh4ZxiPQ@mail.gmail.com>
	<CABsx9T21zjHyO-nh1aSBM3z4Bg015O0rOfYq7=Sy4mf=QxUVQA@mail.gmail.com>
	<COL131-DS24FC87C7C6622E23F5EF58CDCA0@phx.gbl>
Date: Thu, 28 May 2015 10:59:11 -0700
Message-ID: <CAPg+sBhuHrMHZym8xQ2-dMknR4zdM=ZULcnZ-fcGnKLserDd-A@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Raystonn <raystonn@hotmail.com>
Content-Type: multipart/alternative; boundary=047d7b6767c8f320ca0517281da7
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(pieter.wuille[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Yy25N-0002Kz-Is
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB
	stepfunction
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2015 17:59:18 -0000

--047d7b6767c8f320ca0517281da7
Content-Type: text/plain; charset=UTF-8

On May 28, 2015 10:42 AM, "Raystonn ." <raystonn@hotmail.com> wrote:
>
> I agree that developers should avoid imposing economic policy.  It is
dangerous for Bitcoin and the core developers themselves to become such a
central point of attack for those wishing to disrupt Bitcoin.

I could not agree more that developers should not be in charge of the
network rules.

Which is why - in my opinion - hard forks cannot be controversial things. A
controversial change to the software, forced to be adopted by the public
because the only alternative is a permanent chain fork, is a use of power
that developers (or anyone) should not have, and an incredibly dangerous
precedent for other changes that only a subset of participants would want.

The block size is also not just an economic policy. It is the compromise
the _network_ chooses to make between utility and various forms of
centralization pressure, and we should treat it as a compromise, and not as
some limit that is inferior to scaling demands.

I personally think the block size should increase, by the way, but only if
we can do it under a policy of doing it after technological growth has been
shown to be sufficient to support it without increased risk.

-- 
Pieter

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

<p dir=3D"ltr"><br>
On May 28, 2015 10:42 AM, &quot;Raystonn .&quot; &lt;<a href=3D"mailto:rays=
tonn@hotmail.com">raystonn@hotmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; I agree that developers should avoid imposing economic policy.=C2=A0 I=
t is dangerous for Bitcoin and the core developers themselves to become suc=
h a central point of attack for those wishing to disrupt Bitcoin.=C2=A0</p>
<p dir=3D"ltr">I could not agree more that developers should not be in char=
ge of the network rules.</p>
<p dir=3D"ltr">Which is why - in my opinion - hard forks cannot be controve=
rsial things. A controversial change to the software, forced to be adopted =
by the public because the only alternative is a permanent chain fork, is a =
use of power that developers (or anyone) should not have, and an incredibly=
 dangerous precedent for other changes that only a subset of participants w=
ould want.</p>
<p dir=3D"ltr">The block size is also not just an economic policy. It is th=
e compromise the _network_ chooses to make between utility and various form=
s of centralization pressure, and we should treat it as a compromise, and n=
ot as some limit that is inferior to scaling demands.</p>
<p dir=3D"ltr">I personally think the block size should increase, by the wa=
y, but only if we can do it under a policy of doing it after technological =
growth has been shown to be sufficient to support it without increased risk=
.</p>
<p dir=3D"ltr">-- <br>
Pieter<br>
</p>

--047d7b6767c8f320ca0517281da7--