summaryrefslogtreecommitdiff
path: root/8c/9580307af7710fda31526e9345344e4ea84f73
blob: 998b0536fcb36e8817df9584c90bce97351f7687 (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
Return-Path: <johnathan@corganlabs.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 5A1D086
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 15 Nov 2015 06:04:33 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com
	[209.85.217.172])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5794F87
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 15 Nov 2015 06:04:32 +0000 (UTC)
Received: by lbblt2 with SMTP id lt2so73283016lbb.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 14 Nov 2015 22:04:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=corganlabs_com.20150623.gappssmtp.com; s=20150623;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=b1bnoduUANhwhDNrgGxPtGsKF3N3kdsSLGGLYcWrJ4o=;
	b=QU+RjJMSvWLUPyOyHBQvyGEmVclf5oEfPwXiqX6rtkXtCutkT/WusKcDz11qtxdQJq
	q2F4HsYvhXlYSmiXZjJhLj8F4yrR6sNeU4MpGtaYJU/AMzSggku42KvNYe+imtFP8MuT
	jUCls47vOBhl6cvza718qNF9qWQU8DEUqjFm+u+vjoGiK99KwEKAxcuWvtN9YKbzlKDc
	S7femcCpIRDc6TXs16T3T3fHHXGEZDLfiDVi1DrUg9RihN3vSTeRQ/SlWV/wPic9ZZ3l
	vZsmQiyc8J/9LXbgLBII6xdACVcCg9G0ef0vaagQOx7DraVaNnp7Bl03EG1KTZ8R0MM3
	DnUA==
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:from:date
	:message-id:subject:to:cc:content-type;
	bh=b1bnoduUANhwhDNrgGxPtGsKF3N3kdsSLGGLYcWrJ4o=;
	b=aGioW4Q5xHiYsIv7ECApj3pRD8HK1ED+g7Y7xgIGPQ4jUkqdPatorqwi8J42Um1b4a
	VkxdJ+Zt73WMO2NWWYplHh3mxcL1gQOEDZpHm+ZYFn3lFnaP8saBrZMvv7E+VImcqdve
	uY3pZW52dJVODdK/ub2azYAO2KF1ogTIeh/bTPMyjzS5+WFdl+3JwU4tP7CTWbXY/wGP
	gNUGma3deNdJX1zXhJCYZ9NAm5uJ65lu0Rh8GoegMpgbeDf30wDvzZFjvlQwtCCkJoJX
	yLk23l812KZWpOIyVv1oGWTU1fYvq94ugBWBvU8DHRIcKSWL7S0auNBc8cAIkIzJv0pv
	uGyA==
X-Gm-Message-State: ALoCoQnELIF9zhFtQYXyERw4aFI4/UG0XZjU4QHwbTlkxGKv5EnYZ/hoBzTdIffIbkFeyJF2tQHf
X-Received: by 10.112.135.233 with SMTP id pv9mr14517983lbb.42.1447567470516; 
	Sat, 14 Nov 2015 22:04:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.114.186.194 with HTTP; Sat, 14 Nov 2015 22:04:10 -0800 (PST)
In-Reply-To: <B2C858C1-B15F-49F1-BF7E-02EA7C3FE474@gmx.com>
References: <CAPkFh0s-o6BXAEC-s9s1UmFwVfMFQKStoJaM0u2Lct9yiP5QBQ@mail.gmail.com>
	<B2C858C1-B15F-49F1-BF7E-02EA7C3FE474@gmx.com>
From: Johnathan Corgan <johnathan@corganlabs.com>
Date: Sat, 14 Nov 2015 22:04:10 -0800
Message-ID: <CALOxbZtt8k4Q+h0ZwKDQS7-UUpYKoM0dNd8vXUg5Z9i1MCf_iw@mail.gmail.com>
To: Peter R <peter_r@gmx.com>
Content-Type: multipart/alternative; boundary=089e01228934de707705248e108b
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>
Subject: Re: [bitcoin-dev] How to evaluate block size increase suggestions.
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 06:04:33 -0000

--089e01228934de707705248e108b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

This topic is straying from Bitcoin development into general Bitcoin
governance, policy, or other meta-issues.

We have now the new bitcoin-discuss mailing list now, specifically for
these more free-flowing topics:

https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-discuss

Please take further discussion of this thread to that forum.

Thank you,

The bitcoin-dev moderation team


On Sat, Nov 14, 2015 at 1:45 PM, Peter R via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > It looks like some specific meta-level criteria would help more at this
> point than new proposals all exploring a different variants of block size
> increase schedules.
>
> I agree.  In fact, I=E2=80=99ll go meta on your meta and suggest that we =
should
> first discuss how Bitcoin should be governed in the first place.  Should
> Bitcoin evolve from the =E2=80=9Cbottom up,=E2=80=9D or from the =E2=80=
=9Ctop down=E2=80=9D?
>
> If one=E2=80=99s answer is from the =E2=80=9Ctop-down,=E2=80=9D then the =
meta-level criteria can
> be endlessly debated, for they all involve some sort of tradeoff, they al=
l
> require some sort of compromise.  The =E2=80=9Ctop down=E2=80=9D perspect=
ive holds that
> people might make poor choices if given the freedom to easily do so--it
> holds that the trade-offs must be balanced instead by experts.
>
> However, if one's answer is from the =E2=80=9Cbottom up,=E2=80=9D then th=
e meta-level
> criteria is very easy: we do what the people wants. We allow the people t=
o
> weigh the tradeoffs and then we watch as consensus emerges through a
> decentralized process, objectively represented by the longest proof-of-wo=
rk
> chain.
>
> Regarding the block size limit debate, at the end of the day it comes dow=
n
> to two things:
>
> 1.  How big of a block will my node accept today?
>
> 2.  What do I want my node to do if the longest chain includes a block
> larger than the limit I set?
>
> If one concedes that Bitcoin should be governed from the =E2=80=9Cbottom =
up,=E2=80=9D then
> it is already possible to empower each node operator to more easily expre=
ss
> his free choice regarding the size of blocks he is willing to accept, whi=
le
> simultaneously ensuring that his node tracks consensus.
>
> Best regards,
> Peter
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-size:small">Thi=
s topic is straying from Bitcoin development into general Bitcoin governanc=
e, policy, or other meta-issues.</div><div class=3D"gmail_default" style=3D=
"font-size:small"><br></div><div class=3D"gmail_default" style=3D"font-size=
:small">We have now the new bitcoin-discuss mailing list now, specifically =
for these more free-flowing topics:</div><div class=3D"gmail_default" style=
=3D"font-size:small"><br></div><div class=3D"gmail_default" style=3D""><a h=
ref=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-discuss">=
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-discuss</a><br><=
/div><div class=3D"gmail_default" style=3D""><br></div><div class=3D"gmail_=
default" style=3D"">Please take further discussion of this thread to that f=
orum.</div><div class=3D"gmail_default" style=3D""><br></div><div class=3D"=
gmail_default" style=3D"">Thank you,</div><div class=3D"gmail_default" styl=
e=3D""><br></div><div class=3D"gmail_default" style=3D"">The bitcoin-dev mo=
deration team</div><div class=3D"gmail_default" style=3D""><br></div><div c=
lass=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, Nov 14, 2015 at=
 1:45 PM, Peter R via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:b=
itcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.l=
inuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<span class=3D"">&gt; It looks like some specific meta-level criteria would=
 help more at this point than new proposals all exploring a different varia=
nts of block size increase schedules.<br>
<br>
</span>I agree.=C2=A0 In fact, I=E2=80=99ll go meta on your meta and sugges=
t that we should first discuss how Bitcoin should be governed in the first =
place.=C2=A0 Should Bitcoin evolve from the =E2=80=9Cbottom up,=E2=80=9D or=
 from the =E2=80=9Ctop down=E2=80=9D?<br>
<br>
If one=E2=80=99s answer is from the =E2=80=9Ctop-down,=E2=80=9D then the me=
ta-level criteria can be endlessly debated, for they all involve some sort =
of tradeoff, they all require some sort of compromise.=C2=A0 The =E2=80=9Ct=
op down=E2=80=9D perspective holds that people might make poor choices if g=
iven the freedom to easily do so--it holds that the trade-offs must be bala=
nced instead by experts.<br>
<br>
However, if one&#39;s answer is from the =E2=80=9Cbottom up,=E2=80=9D then =
the meta-level criteria is very easy: we do what the people wants. We allow=
 the people to weigh the tradeoffs and then we watch as consensus emerges t=
hrough a decentralized process, objectively represented by the longest proo=
f-of-work chain.<br>
<br>
Regarding the block size limit debate, at the end of the day it comes down =
to two things:<br>
<br>
1.=C2=A0 How big of a block will my node accept today?<br>
<br>
2.=C2=A0 What do I want my node to do if the longest chain includes a block=
 larger than the limit I set?<br>
<br>
If one concedes that Bitcoin should be governed from the =E2=80=9Cbottom up=
,=E2=80=9D then it is already possible to empower each node operator to mor=
e easily express his free choice regarding the size of blocks he is willing=
 to accept, while simultaneously ensuring that his node tracks consensus.<b=
r>
<br>
Best regards,<br>
Peter<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a></div></div></blockquote></div>
</div></div>

--089e01228934de707705248e108b--