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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <john.dillon892@googlemail.com>) id 1UsVs0-0002nw-Bw
for bitcoin-development@lists.sourceforge.net;
Fri, 28 Jun 2013 10:25:36 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of googlemail.com
designates 74.125.83.48 as permitted sender)
client-ip=74.125.83.48;
envelope-from=john.dillon892@googlemail.com;
helo=mail-ee0-f48.google.com;
Received: from mail-ee0-f48.google.com ([74.125.83.48])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UsVry-0006K1-Jz
for bitcoin-development@lists.sourceforge.net;
Fri, 28 Jun 2013 10:25:36 +0000
Received: by mail-ee0-f48.google.com with SMTP id b47so937896eek.35
for <bitcoin-development@lists.sourceforge.net>;
Fri, 28 Jun 2013 03:25:28 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.14.38.14 with SMTP id z14mr13239577eea.49.1372415128282;
Fri, 28 Jun 2013 03:25:28 -0700 (PDT)
Received: by 10.223.12.131 with HTTP; Fri, 28 Jun 2013 03:25:28 -0700 (PDT)
In-Reply-To: <CAKaEYhL2YY6wWnUYJuwWo2czHq7hRiYsQouR1B64oE31ZEochg@mail.gmail.com>
References: <CAPaL=UWcKmnChw0zYGVduzHHdQ-AgG7uqbCLvjjuW6Q67zmS0g@mail.gmail.com>
<CAKaEYhL2YY6wWnUYJuwWo2czHq7hRiYsQouR1B64oE31ZEochg@mail.gmail.com>
Date: Fri, 28 Jun 2013 10:25:28 +0000
Message-ID: <CAPaL=UUYOQQiLO4pn_83_VRihebq-n3892pxpar2mH_9fXYh0w@mail.gmail.com>
From: John Dillon <john.dillon892@googlemail.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.4 (-)
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
(john.dillon892[at]googlemail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (john.dillon892[at]googlemail.com)
-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: 1UsVry-0006K1-Jz
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal: Vote on the blocksize limit
with proof-of-stake voting
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: Fri, 28 Jun 2013 10:25:36 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
> Thinking about this a little more, I guess it does not hurt to build some
> kind of voting system into the clients. But I think it's more useful for
> straw polls. For example a bug fix 100% of people should agree on. A
> protocol optimization perhaps 80% would agree on. A protocol change that
> redistributes wealth or incentives perhaps only 60% will agree on.
>
> At this point in time it's far too easy to deliver contentious changes into
> the hands of the general population. I think that fortunately we're blessed
> with a very strong dev team, but the fundamental philosophy of bitcoin is to
> not put too much trust in single point, but rather, to distribute and
> diversify trust to the edges.
I disagree entirely. Your example of "straw polls" for bug fixes and
features is precisely what the current method of rough consensus and
running code, an IETF expression, handles just fine.
What the method does not handle effectively are issues that are
fundementally political rather than technical in nature. Blocksize is
precisely the latter because while the tradeoffs are technical in
nature the fundemental issue at hand is what do we want Bitcoin to be?
Who are we going to allow to participate?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJRzWR7AAoJEEWCsU4mNhiPEYsIAME+VvS4vfE0PdOMv3vHWGSH
HwUJdtKPold4+p0jhPBKSMbgnpMvXsZezMIIxj8xehnblnVuUdyakibXAdgVNLvp
a6SCw+W/VnopYCw151zZ4FQS92KQuSbX+XmYTQy32oqZIXtBmTE1fydw5q6YhoXb
gCCygPRyLTIQxLZAxqqRrQ0nsSE5ID5kDcr+xRsmCvfIKrzoOCbYL+nXPCB4Zzgu
Gs7Lfa0yfTrUlQmoDseyoWrVuhfYuFNesTAs3z6imMTdHqZh8Z+a+gmC+G9qFO1h
y7hOmzW4oz7hH4R2F6M+UpV6rKdwMaNYwrDw5eHClDgGYNfjjVduQ/YMQnbjyAc=
=5mhd
-----END PGP SIGNATURE-----
|
