summaryrefslogtreecommitdiff
path: root/33/d83af5ab854fb58ffb65ccf32b5cb5f09de138
blob: a7bfd4839abbd63c8903c58fc398e38a7ccdbf93 (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
Return-Path: <hearn@vinumeris.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 60DB7847
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 15 Aug 2015 19:21:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com
	[209.85.213.177])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B472C13B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 15 Aug 2015 19:21:52 +0000 (UTC)
Received: by igbjg10 with SMTP id jg10so31811340igb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 15 Aug 2015 12:21:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=vinumeris.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=dLjluG8+BrXS0byV1aUgwa9cWUPGaiLctIRh22hbnI0=;
	b=BUkbyUSw2pAH0Aoz+lPCZT1uAGc9H3xU1OsCmDaWIlyeDRIIdPj1dcXZgiV1jLHMJD
	2gjav2u53iBt9q0onp+lmU9+jShFOFJzQhtymBniV9pp8XMmeDkGuLfjtPeIP+V4UTL/
	WHBqsjYwyPn3YCmdzicSDMohcA+niYFmdZU3s=
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:date
	:message-id:subject:from:to:cc:content-type;
	bh=dLjluG8+BrXS0byV1aUgwa9cWUPGaiLctIRh22hbnI0=;
	b=a9R2dxA8Gd1Wfu/FbxfYp/BUQDwLvQl5E3dt0SHL/LvBYyZuZvd2IJ4yJJ7w0jKMZ2
	Op9zL+hEyM6mtGAjG20zmYg3KgpMPKfM+Lxd+tWbg++q4FLUY6wUAYk63Zobz649ZM+e
	9xOWKo+sdU9fJviftNa80ShPCaUKb51x29sNAVkPqB0+hJ0ku5UHg2ywoHsPzgKObTwK
	hun3X/cNF8uvb2eFntzx+ayuhXKuhNy303kM5hRRJX7+YVn5kJHa8yXzlX3wCA4JQw2d
	Y8bsKPB8SaQ7w6koU8OHqT3KaeF+GzWR2nftT9e5PYO9OLCL5LiPlJYUMLZEr7LTphsa
	gZWw==
X-Gm-Message-State: ALoCoQn0egjMI8U3UWKuZ1fEXy2oVvASIDB0ACiG7niP34K0Edwpl3ciH/EJeKP/rrgvWTP66ADU
MIME-Version: 1.0
X-Received: by 10.50.66.232 with SMTP id i8mr9397035igt.34.1439666512137; Sat,
	15 Aug 2015 12:21:52 -0700 (PDT)
Received: by 10.50.208.7 with HTTP; Sat, 15 Aug 2015 12:21:52 -0700 (PDT)
In-Reply-To: <55CF871E.9050500@sky-ip.org>
References: <CA+w+GKT7t5OahS-+P=QAmOyFzPnOs4J6KSo+mhSrC0YggmMupg@mail.gmail.com>
	<55CF871E.9050500@sky-ip.org>
Date: Sat, 15 Aug 2015 21:21:52 +0200
Message-ID: <CA+w+GKTG6a_v4Jop3FZ2O2WG9Fi=o0Lnh58OH4Y4sM-vPjFHSQ@mail.gmail.com>
From: Mike Hearn <hearn@vinumeris.com>
To: s7r@sky-ip.org
Content-Type: multipart/alternative; boundary=047d7bdc9e4e0d2ebc051d5e7b0a
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,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] Bitcoin XT 0.11A
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: Sat, 15 Aug 2015 19:21:53 -0000

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

>
> I use bitcoin heavily (not from time to time) but I don't mine - can I
> vote? The way I see it I cannot, and I am not saying it is a bad thing,
> but I missed the argument explaining why users don't matter and only
> miners do.
>

It is a reasonable question. Let me try and explain why it's done this way.

*In theory*, you do have a vote. If a majority of miners were to club
together and decide to change the protocol against the wishes of the wider
user base, then we'd get a fight between the hashpower majority and the
so-called economic majority. And because bitcoins only have value because
you can buy things with them, in theory, the wishes of the economic
majority should always win.

*In practice*, the code we have today doesn't let us measure what the
economic majority wants. It's not even really clear how that term is
defined. Intuitively we can understand that people who are trading real
goods and services for bitcoin have the final say, because they can always
just refuse to accept BTC. But defining it precisely enough to put in an
algorithm is tricky.

Then you have the question of how to express the vote? For miners, it's
easy: they express their vote by switching to a different full node
implementation that gives them different blocks.

For users, it'd mean switching to a different wallet. If their wallet is
fully validating and the decision is implemented via hard fork, this is
sufficient. If the wallet is *not* fully validating and cannot detect the
fork point by itself, then it'd need help in the form of checkpointing.
Some months ago I pointed out this possibility and a whole bunch of people
freaked out - then bitcoin.org decided to start censoring any wallet that
said it'd ignore what miners wanted.

So if you want a user vote, that's an issue that'd have to be tackled: the
people who admin the main communication channels Bitcoin users have vowed
to censor any program that doesn't slavishly follow 51%+ hash power. That
attempt to control the conversation is certainly not libertarian or
democratic in nature, but there you go.

We can also imagine voting via proof-of-stake. This might be useful as a
form of opinion poll, but wallet developers would have to actually add
support for such a protocol to their apps, and then we're back to the same
issue as with mining pools. Plus, of course, static wealth does not equal
economic importance.

Luckily the wallet market is a decentralisation success story. There are
wallets everywhere these days. Man+dog make their own wallet, it seems. So
it's not silly to think a coin voting protocol could one day happen.

--047d7bdc9e4e0d2ebc051d5e7b0a
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"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">I use bitcoin heavily (not from time to time) bu=
t I don&#39;t mine - can I<br>
vote? The way I see it I cannot, and I am not saying it is a bad thing,<br>
but I missed the argument explaining why users don&#39;t matter and only<br=
>
miners do.<br></blockquote><div><br></div><div>It is a reasonable question.=
 Let me try and explain why it&#39;s done this way.</div><div><br></div><di=
v><i>In theory</i>, you do have a vote. If a majority of miners were to clu=
b together and decide to change the protocol against the wishes of the wide=
r user base, then we&#39;d get a fight between the hashpower majority and t=
he so-called economic=C2=A0majority. And because bitcoins only have value b=
ecause you can buy things with them, in theory, the wishes of the economic =
majority should always win.</div><div><br></div><div><i>In practice</i>, th=
e code we have today doesn&#39;t let us measure what the economic majority =
wants. It&#39;s not even really clear how that term is defined. Intuitively=
 we can understand that people who are trading real goods and services for =
bitcoin have the final say, because they can always just refuse to accept B=
TC. But defining it precisely enough to put in an algorithm is tricky.</div=
><div><br></div><div>Then you have the question of how to express the vote?=
 For miners, it&#39;s easy: they express their vote by switching to a diffe=
rent full node implementation that gives them different blocks.=C2=A0</div>=
<div><br></div><div>For users, it&#39;d mean switching to a different walle=
t. If their wallet is fully validating and the decision is implemented via =
hard fork, this is sufficient. If the wallet is <i>not</i>=C2=A0fully valid=
ating and cannot detect the fork point by itself, then it&#39;d need help i=
n the form of checkpointing. Some months ago I pointed out this possibility=
 and a whole bunch of people freaked out - then <a href=3D"http://bitcoin.o=
rg">bitcoin.org</a> decided to start censoring any wallet that said it&#39;=
d ignore what miners wanted.</div><div><br></div><div>So if you want a user=
 vote, that&#39;s an issue that&#39;d have to be tackled: the people who ad=
min the main communication channels Bitcoin users have vowed to censor any =
program that doesn&#39;t slavishly follow 51%+ hash power. That attempt to =
control the conversation is certainly not libertarian or democratic in natu=
re, but there you go.</div><div><br></div><div>We can also imagine voting v=
ia proof-of-stake. This might be useful as a form of opinion poll, but wall=
et developers would have to actually add support for such a protocol to the=
ir apps, and then we&#39;re back to the same issue as with mining pools. Pl=
us, of course, static wealth does not equal economic importance.=C2=A0</div=
><div><br></div><div>Luckily the wallet market is a decentralisation succes=
s story. There are wallets everywhere these days. Man+dog make their own wa=
llet, it seems. So it&#39;s not silly to think a coin voting protocol could=
 one day happen.</div><div><br></div><div><br></div></div></div></div>

--047d7bdc9e4e0d2ebc051d5e7b0a--