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
|
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 A9C33B4C
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Dec 2015 09:44:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com
[209.85.213.179])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 174CD89
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Dec 2015 09:44:37 +0000 (UTC)
Received: by mail-ig0-f179.google.com with SMTP id m11so30131177igk.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Dec 2015 01:44:37 -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=3twv9sCirXl+haRjBX9EmfxEqJN3IU88OvP90pQ+XPo=;
b=J03bBIsGltwCGDIEqPXVER92ArJgxtgnOK+1djTRSioqQ+pei00hJfEx8Cu3isz4f4
xGtZLBnSDAnhO0SAq5/++IPcbi/KYUdqvE26OtSXLHyxEN2L9hdBRN0cryEKPP1DpXXh
fJ8YOADwm1QVi649G5Qf7lT6NITN+vTH2RM4eZH7QNi9qudpd8BkI7xdvcKfurok7Qxv
nQw2BbN+X52rlB8/rOmIkSaYqG5WphN7cgCWyn6eTEn3hx43GFRoWNt54ZpnnBpR/xaa
2nSiM1WJDsZx87OYNrnFXQjRqY3s0hOcgmWR8S4gULiGt7+eQjTe4nJgiTG4v2QkTt6l
TyyA==
MIME-Version: 1.0
X-Received: by 10.50.73.198 with SMTP id n6mr1791883igv.95.1450431876470; Fri,
18 Dec 2015 01:44:36 -0800 (PST)
Received: by 10.79.77.75 with HTTP; Fri, 18 Dec 2015 01:44:36 -0800 (PST)
In-Reply-To: <20151217194407.GB1351@muck>
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>
<CAE-z3OVD67rDefFzbpuzTO0=54_hJzSfSPg735zk_vjsANmEhQ@mail.gmail.com>
<20151217194407.GB1351@muck>
Date: Fri, 18 Dec 2015 09:44:36 +0000
Message-ID: <CAE-z3OXQpHFXY_vbTRMMcFSfP4tiFAsmCxkkZ+=Bfkppg=ciMQ@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=089e011839a6c4c08c052728fcaf
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: Fri, 18 Dec 2015 09:44:37 -0000
--089e011839a6c4c08c052728fcaf
Content-Type: text/plain; charset=UTF-8
On Thu, Dec 17, 2015 at 7:44 PM, Peter Todd <pete@petertodd.org> wrote:
> If Bitcoin remains decentralized, miners have veto power over any
> blocksize increases. You can always soft-fork in a blocksize reduction
> in a decentralized blockchain that actually works.
>
The actual users of the system have significant power, if they (could)
choose to use it. There are "chicken" effects though. They can impose
costs on the other participants but using those options harms themselves.
If the cost of inaction is greater than the costs of action, then the
chicken effects go away.
In the extreme, they could move away from decentralisation and the concept
of miners and have a centralised checkpointing system. This would be a
bankrupting cost to miners but at the cost to the users of the
decentralised nature of the system.
At a lower extreme, they could change the mining hash function. This would
devalue all of the miner's investments. A whole new program of ASIC
investments would have to happen and the new miners would be significantly
different. It would also establish that merchants and users are not to be
ignored. On the other hand, bankrupting miners would make it harder to
convince new miners to make the actual investments in ASICs required to
establish security.
As a gesture, if merchants and exchanges wanted to get their "seat" at the
table, they could create a representative group that insists on a trivial
soft fork. For example, they could say that they will not accept any block
from block N to block N + 5000 that doesn't have a specific bit set in the
version.
Miners have an advantage where they can say that they have the majority of
the hashing power. As part of the public action problem that merchants
face, there is no equivalent metric.
--089e011839a6c4c08c052728fcaf
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 T=
hu, Dec 17, 2015 at 7:44 PM, Peter Todd <span dir=3D"ltr"><<a href=3D"ma=
ilto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>></span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If Bitcoin re=
mains decentralized, miners have veto power over any<br>
blocksize increases. You can always soft-fork in a blocksize reduction<br>
in a decentralized blockchain that actually works.<span class=3D""><font co=
lor=3D"#888888"><br>
</font></span></blockquote></div><br></div><div class=3D"gmail_extra">The a=
ctual users of the system have significant power, if they (could) choose to
use it.=C2=A0 There are "chicken" effects though.=C2=A0 They can=
impose costs on the other participants but using those options harms thems=
elves.=C2=A0 If the cost of inaction is greater than the costs of action, t=
hen the chicken effects go away.<br><br></div><div class=3D"gmail_extra">In=
the extreme, they could move away from decentralisation and the concept of=
miners and have a centralised checkpointing system.=C2=A0 This would be a =
bankrupting cost to miners but at the cost to the users of the decentralise=
d nature of the system.<br><br></div><div class=3D"gmail_extra">At a lower =
extreme, they could change the mining hash function.=C2=A0 This would deval=
ue all of the miner's investments.=C2=A0 A whole new program of ASIC in=
vestments would have to happen and the new miners would be significantly di=
fferent.=C2=A0 It would also establish that merchants and users are not to =
be ignored.=C2=A0 On the other hand, bankrupting miners would make it harde=
r to convince new miners to make the actual investments in ASICs required t=
o establish security.<br><br></div><div class=3D"gmail_extra">As a gesture,=
if merchants and exchanges wanted to get their "seat" at the tab=
le, they could create a representative group that insists on a trivial soft=
fork.=C2=A0 For example, they could say that they will not accept any bloc=
k from block N to block N + 5000 that doesn't have a specific bit set i=
n the version.<br><br></div><div class=3D"gmail_extra">Miners have an advan=
tage where they can say that they have the majority of the hashing power.=
=C2=A0 As part of the public action problem that merchants face, there is n=
o equivalent metric.<br></div></div>
--089e011839a6c4c08c052728fcaf--
|
