Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 60DB7847 for ; 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 ; Sat, 15 Aug 2015 19:21:52 +0000 (UTC) Received: by igbjg10 with SMTP id jg10so31811340igb.0 for ; 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: <55CF871E.9050500@sky-ip.org> Date: Sat, 15 Aug 2015 21:21:52 +0200 Message-ID: From: Mike Hearn 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
I use bitcoin heavily (not from time to time) bu= t 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 clu= b together and decide to change the protocol against the wishes of the wide= r user base, then we'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.

In practice, th= e 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 B= TC. 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 diffe= rent full node implementation that gives them different blocks.=C2=A0
=

For users, it'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 not=C2=A0fully valid= ating and cannot detect the fork point by itself, then it'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 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 ad= min 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 natu= re, but there you go.

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're back to the same issue as with mining pools. Pl= us, of course, static wealth does not equal economic importance.=C2=A0

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's not silly to think a coin voting protocol could= one day happen.


--047d7bdc9e4e0d2ebc051d5e7b0a--