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
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id EFC17E90
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Dec 2015 16:58:03 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f173.google.com (mail-io0-f173.google.com
[209.85.223.173])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 792BC107
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Dec 2015 16:58:03 +0000 (UTC)
Received: by mail-io0-f173.google.com with SMTP id 186so62503478iow.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Dec 2015 08:58:03 -0800 (PST)
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:cc
:content-type; bh=Q5P8q91WwUtlJ+tOQcWqsCQmaPEsS16onX2gzGc2IDE=;
b=Dz/aXGBkJi3u2hLQ3XIhxWeYd6+/1gmDRN3MqeKOnjc2vTaoHv3XUZAe4jRD/4m97s
3Fb5rovJLP/xJ1wUIVcxDMKjpY6IbcwF6N1vtsozJm1pC3iFdxJ5sb0F/WOR82UNCOd+
5njRweiFtUBzRovAOG+X01LB9kVII3peyQQqLPQfahWqqliH2IQSt7A0PmUxXMP/10Xn
E9ndvgEc8V5xlafR8vLAr1YMjEzrPRXFCcITIhjISRVuFyaBlctGBRk/skNGnyhOiYZL
H5QLvZjW+Aim8tHbJRALHoOaeU8oX0lpx4CZLrhZCED6IoJtcfs4wD+wOL6s++L5NXTi
OMgw==
MIME-Version: 1.0
X-Received: by 10.107.153.79 with SMTP id b76mr30081314ioe.71.1450371482846;
Thu, 17 Dec 2015 08:58:02 -0800 (PST)
Received: by 10.79.77.75 with HTTP; Thu, 17 Dec 2015 08:58:02 -0800 (PST)
In-Reply-To: <CAPg+sBimfFVea4Sorgx=DaMPVs1k1DrmTA2ZFdLFtxrqKm23-w@mail.gmail.com>
References: <CADm_WcasDuBsop55ZWcTb2FvccaoREg8K032rUjgQUQhQ3g=XA@mail.gmail.com>
<CAPg+sBi=Mw7UnxG1-0-0ZTRqxrS5+28VmowyYrGP2MAvYiu_pA@mail.gmail.com>
<CADm_Wcae7OK7kyXkfh+7XFrc2WYsv7T1Va3_E=5om+XYrL9pOw@mail.gmail.com>
<CAPg+sBimfFVea4Sorgx=DaMPVs1k1DrmTA2ZFdLFtxrqKm23-w@mail.gmail.com>
Date: Thu, 17 Dec 2015 16:58:02 +0000
Message-ID: <CAE-z3OVD67rDefFzbpuzTO0=54_hJzSfSPg735zk_vjsANmEhQ@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a1140f7e0070b2805271aedb5
X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
MALFORMED_FREEMAIL,
MISSING_HEADERS,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Block size: It's economics & user preparation &
moral hazard
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: Thu, 17 Dec 2015 16:58:04 -0000
--001a1140f7e0070b2805271aedb5
Content-Type: text/plain; charset=UTF-8
On Wed, Dec 16, 2015 at 9:11 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> We are not avoiding a choice. We don't have the authority to make a choice.
>
This is really the most important question.
Bitcoin is kind of like a republic where there is separation of powers
between various groups.
The power blocs in the process include
- Core Devs
- Miners
- Exchanges
- Merchants
- Customers
Complete agreement is not required for a change. If merchants and their
customers were to switch to different software, then there is little any of
the other groups could do.
Consensus is nice, certainly, and it is a good social norm to seek
widespread agreement before committing to a decision above objection.
Committing to no block increase is also committing to a decision against
objections.
Having said that, each of the groups are not equal in power and
organisation.
Merchants and their customers have potentially a large amount of power, but
they are disorganised. There is little way for them to formally express a
view, much less put their power behind making a change. Their potential
power is crippled by public action problems.
On the other extreme is the core devs. Their power is based on legitimacy
due to having a line of succession starting with Satoshi and respect gained
due to technical and political competence. Being a small group, they are
organised and they are also more directly involved.
The miners are less centralised, but statements supported by the majority
of the hashing power are regularly made. The miners' position is that they
want dev consensus. This means that they have delegated their decision
making to the core devs.
The means that the two most powerful groups in Bitcoin have given the core
devs the authority to make the decision. They don't have carte blanche
from the miners.
If the core devs made the 2MB hard-fork with a 75% miner threshold, it is
highly likely that the other groups would accept it.
That is the only authority that exists in Bitcoin. The check is that if
the authority is abused, the other groups can simply leave (or use
checkpointing)
--001a1140f7e0070b2805271aedb5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Dec 16, 2015 at 9:11 PM, Pieter Wuille via bitcoin-dev <span dir=3D"ltr=
"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_b=
lank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><span class=3D"">
</span>We are not avoiding a choice. We don't have the authority to mak=
e a choice.<br></blockquote><div><br></div><div>This is really the most imp=
ortant question.<br><br></div>Bitcoin is kind of like a republic where ther=
e is separation of powers between various groups.<br><br></div><div class=
=3D"gmail_quote">The power blocs in the process include<br><br></div><div c=
lass=3D"gmail_quote">- Core Devs<br></div><div class=3D"gmail_quote">- Mine=
rs<br></div><div class=3D"gmail_quote">- Exchanges<br></div><div class=3D"g=
mail_quote">- Merchants<br></div><div class=3D"gmail_quote">- Customers<br>=
<br></div><div class=3D"gmail_quote">Complete agreement is not required for=
a change.=C2=A0 If merchants and their customers were to switch to differe=
nt software, then there is little any of the other groups could do.<br></di=
v><div class=3D"gmail_quote"><br>Consensus is nice, certainly, and it is a =
good social norm to seek widespread agreement before committing to a decisi=
on above objection.=C2=A0 Committing to no block increase is also committin=
g to a decision against objections.<br><br></div><div class=3D"gmail_quote"=
>Having said that, each of the groups are not equal in power and organisati=
on.<br><br></div><div class=3D"gmail_quote">Merchants and their customers h=
ave potentially a large amount of power, but they are disorganised.=C2=A0 T=
here is little way for them to formally express a view, much less put their=
power behind making a change.=C2=A0 Their potential power is crippled by p=
ublic action problems.<br><br></div><div class=3D"gmail_quote">On the other=
extreme is the core devs. Their power is based on legitimacy due to having=
a line of succession starting with Satoshi and respect gained due to techn=
ical and political competence.=C2=A0 Being a small group, they are organis=
ed and they are also more directly involved. <br><br>The miners are less ce=
ntralised, but statements supported by the majority of the hashing power ar=
e regularly made.=C2=A0 The miners' position is that they want dev cons=
ensus.=C2=A0 This means that they have delegated their decision making to t=
he core devs.=C2=A0 <br><br></div><div class=3D"gmail_quote">The means that=
the two most powerful groups in Bitcoin have given the core devs the autho=
rity to make the decision.=C2=A0 They don't have carte blanche from the=
miners.<br><br></div><div class=3D"gmail_quote">If the core devs made the =
2MB hard-fork with a 75% miner threshold, it is highly likely that the othe=
r groups would accept it.<br><br>That is the only authority that exists in =
Bitcoin.=C2=A0 The check is that if the authority is abused, the other grou=
ps can simply leave (or use checkpointing)<br></div></div></div>
--001a1140f7e0070b2805271aedb5--
|
