summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDave Scotese <dscotese@litmocracy.com>2017-02-02 17:32:34 -0800
committerbitcoindev <bitcoindev@gnusha.org>2017-02-03 01:32:37 +0000
commit114f51ce0fc8848ba2ca0d1fa976e2b956975f85 (patch)
treef0b64f582615b3d43f474d6c818aba125f6d3585
parentde3071e2c5ef43afb2528f118d90e6e52eaf46e8 (diff)
downloadpi-bitcoindev-114f51ce0fc8848ba2ca0d1fa976e2b956975f85.tar.gz
pi-bitcoindev-114f51ce0fc8848ba2ca0d1fa976e2b956975f85.zip
Re: [bitcoin-dev] [Pre-BIP] Community Consensus Voting System
-rw-r--r--36/681e5f1fd9cf98e5d11d437cbde06654926fd7454
1 files changed, 454 insertions, 0 deletions
diff --git a/36/681e5f1fd9cf98e5d11d437cbde06654926fd7 b/36/681e5f1fd9cf98e5d11d437cbde06654926fd7
new file mode 100644
index 000000000..e0ae5cd6e
--- /dev/null
+++ b/36/681e5f1fd9cf98e5d11d437cbde06654926fd7
@@ -0,0 +1,454 @@
+Return-Path: <dscotese@gmail.com>
+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
+ [172.17.192.35])
+ by mail.linuxfoundation.org (Postfix) with ESMTPS id 193FB2C
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Fri, 3 Feb 2017 01:32:37 +0000 (UTC)
+X-Greylist: whitelisted by SQLgrey-1.7.6
+Received: from mail-qt0-f172.google.com (mail-qt0-f172.google.com
+ [209.85.216.172])
+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A787C187
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Fri, 3 Feb 2017 01:32:35 +0000 (UTC)
+Received: by mail-qt0-f172.google.com with SMTP id v23so11092144qtb.0
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Thu, 02 Feb 2017 17:32:35 -0800 (PST)
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
+ h=mime-version:sender:in-reply-to:references:from:date:message-id
+ :subject:to:cc;
+ bh=hDbcCNkKpia766+H6IoCeRc6DMlHOywzxbG9DuxP7PE=;
+ b=Wt4teqMRd63oAXHogVPdKoJChIXLBUwlcqnU/9QKUP6y2/oHcDdse6/V7af2yj0+Fr
+ RQzxjE3nNMfw2oinPEJReCTyvaiZwDU0QkmB9Aj6Wjkjyw2+3ttcEaGHOt4DIxaI0DaX
+ hAznQy8s5C7hu4TIsULdKhdKEwjuwU7Vk61rTEuQ+alluh1DwfpIkpIep/z3jEoYPQTU
+ ynRTSJ1NcbHYnILkeOmIjnea3EdSBK90JrL9fjhlR40I9mpgFHVuyKLzoQHOKI4RRPk6
+ YMyhSrOMidjp5xVFNxqbF9ePyFht/Tt3fIJrEtCOyPoTn183Fp/4risvX6hO5SZKmK9m
+ jwhg==
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
+ d=1e100.net; s=20161025;
+ h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
+ :date:message-id:subject:to:cc;
+ bh=hDbcCNkKpia766+H6IoCeRc6DMlHOywzxbG9DuxP7PE=;
+ b=AxpYiEeph/LKeaq6OIX+3b9H9Sbf8PR/4DIBBwEuCGjTMg+OBKuQqZ4S/5ly6WHVni
+ Qu8XiuhALgsOd9xg0noty+a2bHfD2kXIErwHWj4NmuYDfXkDloyrGmra1tlwyJADiR5/
+ HOoB3CUQ0yLhknsMBTozs41WGHY7QWIXz+z6cjBWvIrwLAJJX4RAe9N9rqD1PEFKTWw6
+ 1r/Kwv345NglTRpjR8ay8+SsHcuMVD1DhVdBv8Mzi5bM26Lbsn38zGKL24zcNeVbgD0U
+ G5vZchx0pzlkScjwsU/PwRN2C1IJMRvbjTvKXb/uheQ3pI1Ht1UItzF9vvGFWXjjT2mc
+ g4nA==
+X-Gm-Message-State: AIkVDXKjNNh5/jXVL/ulto2x7hMRPlyQX/aHjIHJFjozEAUJAQ+nJ/3HbQy9IvvqS0OrzdiTRwYbeMbmEcxaHw==
+X-Received: by 10.200.38.196 with SMTP id 4mr10663852qtp.96.1486085554783;
+ Thu, 02 Feb 2017 17:32:34 -0800 (PST)
+MIME-Version: 1.0
+Sender: dscotese@gmail.com
+Received: by 10.140.43.5 with HTTP; Thu, 2 Feb 2017 17:32:34 -0800 (PST)
+In-Reply-To: <201702030024.10232.luke@dashjr.org>
+References: <CAGCNRJqNg9-aYG62OxTz5RJyx+JJkx-kt2odooZWs92f5teZiw@mail.gmail.com>
+ <201702030024.10232.luke@dashjr.org>
+From: Dave Scotese <dscotese@litmocracy.com>
+Date: Thu, 2 Feb 2017 17:32:34 -0800
+X-Google-Sender-Auth: bQOZdOKByb5QQW6gyNKQbT62ICI
+Message-ID: <CAGLBAhdzPOC6MppMyuL6SwnoY_D829ZRs78pTF47k3rnHPjE1A@mail.gmail.com>
+To: Luke Dashjr <luke@dashjr.org>,
+ Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
+Content-Type: multipart/alternative; boundary=001a113f4790994d3205479641a2
+X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
+ DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_LOW,
+ RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1
+X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
+ smtp1.linux-foundation.org
+Subject: Re: [bitcoin-dev] [Pre-BIP] Community Consensus Voting System
+X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
+X-Mailman-Version: 2.1.12
+Precedence: list
+List-Id: Bitcoin Protocol 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, 03 Feb 2017 01:32:37 -0000
+
+--001a113f4790994d3205479641a2
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: quoted-printable
+
+There are two ideas here for "on-chain" voting, both of which require
+changes to the software. I agree with David that on-chain solutions
+complicate things. Both proposals can be effected without any software
+changes:
+
+Those who wish to use proof of stake can provide a service for making
+vanity addresses containing some indicator of the proposal to be supported
+- 1bigblock or 12mbblk or whatever - based on a supporter-provided secret
+key, and then supporters can move their bitcoin into their own vanity
+address and then whoever wants to can create a website to display the
+matching addresses and explain that this is the financial power in the
+hands of supporters and how to add your "financial power vote."
+
+Those who simply want to "buy votes" can use their funds in marketing
+efforts to promote the proposal they support.
+
+This second method, of course, can be abused. The first actually requires
+people to control bitcoin in order to represent support. Counting actual,
+real people is still a technology in its infancy, and I don't think I want
+to see it progress much. People are not units, but individuals, and their
+value only becomes correlated to their net worth after they've been alive
+for many years, and even then, some of the best people have died paupers.
+If bitcoin-discuss got more traffic, I think this discussion would be
+better had on that list.
+
+notplato
+
+On Thu, Feb 2, 2017 at 4:24 PM, Luke Dashjr via bitcoin-dev <
+bitcoin-dev@lists.linuxfoundation.org> wrote:
+
+> Strongly disagree with buying "votes", or portraying open standards as a
+> voting process. Also, this depends on address reuse, so it's fundamentall=
+y
+> flawed in design.
+>
+> Some way for people to express their support weighed by coins (without
+> losing/spending them), and possibly weighed by running a full node, might
+> still be desirable. The most straightforward way to do this is to support
+> message signatures somehow (ideally without using the same pubkey as
+> spending), and some [inherently unreliable, but perhaps useful if the
+> community "colludes" to not-cheat] way to sign with ones' full node.
+>
+> Note also that the BIP process already has BIP Comments for leaving textu=
+al
+> opinions on the BIP unrelated to stake. See BIP 2 for details on that.
+>
+> Luke
+>
+>
+> On Thursday, February 02, 2017 7:39:51 PM t. khan via bitcoin-dev wrote:
+> > Please comment on this work-in-progress BIP.
+> >
+> > Thanks,
+> >
+> > - t.k.
+> >
+> > ----------------------
+> > BIP: ?
+> > Layer: Process
+> > Title: Community Consensus Voting System
+> > Author: t.khan <teekhan42@gmail.com>
+> > Comments-Summary: No comments yet.
+> > Comments-URI: TBD
+> > Status: Draft
+> > Type: Standards Track
+> > Created: 2017-02-02
+> > License: BSD-2
+> > Voting Address: 3CoFA3JiK5wxe9ze2HoDGDTmZvkE5Uuwh8 (just an example,
+> don=E2=80=99t
+> > send to this!)
+> >
+> > Abstract
+> > Community Consensus Voting System (CCVS) will allow developers to measu=
+re
+> > support for BIPs prior to implementation.
+> >
+> > Motivation
+> > We currently have no way of measuring consensus for potential changes t=
+o
+> > the Bitcoin protocol. This is especially problematic for controversial
+> > changes such as the max block size limit. As a result, we have many
+> > proposed solutions but no clear direction.
+> >
+> > Also, due to our lack of ability to measure consensus, there is a gener=
+al
+> > feeling among many in the community that developers aren=E2=80=99t list=
+ening to
+> > their concerns. This is a valid complaint, as it=E2=80=99s not possible=
+ to listen
+> > to thousands of voices all shouting different things in a crowded
+> > room=E2=80=94basically the situation in the Bitcoin community today.
+> >
+> > The CCVS will allow the general public, miners, companies using Bitcoin=
+,
+> > and developers to vote for their preferred BIP in a way that=E2=80=99s =
+public and
+> > relatively difficult (expensive) to manipulate.
+> >
+> > Specification
+> > Each competing BIP will be assigned a unique bitcoin address which is
+> added
+> > to each header. Anyone who wanted to vote would cast their ballot by
+> > sending a small amount (0.0001 btc) to their preferred BIP's address.
+> Each
+> > transaction counts as 1 vote.
+> >
+> > Confirmed Vote Multiplier:
+> > Mining Pools, companies using Bitcoin, and Core maintainers/contributor=
+s
+> > are allowed one confirmed vote each. A confirmed vote is worth 10,000x =
+a
+> > regular vote.
+> >
+> > For example:
+> >
+> > Slush Pool casts a vote for their preferred BIP and then states publicl=
+y
+> > (on their blog) their vote and the transaction ID and emails the URL to
+> the
+> > admin of this system. In the final tally, this vote will count as 10,00=
+0
+> > votes.
+> >
+> > Coinbase, Antpool, BitPay, BitFury, etc., all do the same.
+> >
+> > Confirmed votes would be added to a new section in each respective BIP
+> as a
+> > public record.
+> >
+> > Voting would run for a pre-defined period, ending when a particular blo=
+ck
+> > number is mined.
+> >
+> >
+> > Rationale
+> > Confirmed Vote Multiplier - The purpose of this is twofold; it gives a
+> > larger voice to organizations and the people who will have to do the wo=
+rk
+> > to implement whatever BIP the community prefers, and it will negate the
+> > effect of anyone trying to skew the results by voting repeatedly.
+> >
+> > Definitions
+> > Miner: any individual or organization that has mined at least one valid
+> > block in the last 2016 blocks.
+> >
+> > Company using Bitcoin: any organization using Bitcoin for financial,
+> asset
+> > or other purposes, with either under development and released solutions=
+.
+> >
+> > Developer: any individual who has or had commit access, and any
+> individual
+> > who has authored a BIP
+> >
+> > Unresolved Issues
+> > Node voting: It would be desirable for any full node running an
+> up-to-date
+> > blockchain to also be able to vote with a multiplier (e.g. 100x). But a=
+s
+> > this would require code changes, it is outside the scope of this BIP.
+> >
+> > Copyright
+> > This BIP is licensed under the BSD 2-clause license.
+> _______________________________________________
+> bitcoin-dev mailing list
+> bitcoin-dev@lists.linuxfoundation.org
+> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
+>
+
+
+
+--=20
+I like to provide some work at no charge to prove my value. Do you need a
+techie?
+I own Litmocracy <http://www.litmocracy.com> and Meme Racing
+<http://www.memeracing.net> (in alpha).
+I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
+now accepts Bitcoin.
+I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
+"He ought to find it more profitable to play by the rules" - Satoshi
+Nakamoto
+
+--001a113f4790994d3205479641a2
+Content-Type: text/html; charset=UTF-8
+Content-Transfer-Encoding: quoted-printable
+
+<div dir=3D"ltr"><div><div><div>There are two ideas here for &quot;on-chain=
+&quot; voting, both of which require changes to the software.=C2=A0 I agree=
+ with David that on-chain solutions complicate things.=C2=A0 Both proposals=
+ can be effected without any software changes:<br><br>Those who wish to use=
+ proof of stake can provide a service for making vanity addresses containin=
+g some indicator of the proposal to be supported - 1bigblock or 12mbblk or =
+whatever - based on a supporter-provided secret key, and then supporters ca=
+n move their bitcoin into their own vanity address and then whoever wants t=
+o can create a website to display the matching addresses and explain that t=
+his is the financial power in the hands of supporters and how to add your &=
+quot;financial power vote.&quot;<br><br></div>Those who simply want to &quo=
+t;buy votes&quot; can use their funds in marketing efforts to promote the p=
+roposal they support.<br><br></div>This second method, of course, can be ab=
+used.=C2=A0 The first actually requires people to control bitcoin in order =
+to represent support.=C2=A0 Counting actual, real people is still a technol=
+ogy in its infancy, and I don&#39;t think I want to see it progress much. P=
+eople are not units, but individuals, and their value only becomes correlat=
+ed to their net worth after they&#39;ve been alive for many years, and even=
+ then, some of the best people have died paupers. If bitcoin-discuss got mo=
+re traffic, I think this discussion would be better had on that list.<br><b=
+r></div>notplato<br></div><div class=3D"gmail_extra"><br><div class=3D"gmai=
+l_quote">On Thu, Feb 2, 2017 at 4:24 PM, Luke Dashjr via bitcoin-dev <span =
+dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" ta=
+rget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:=
+<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
+t:1px #ccc solid;padding-left:1ex">Strongly disagree with buying &quot;vote=
+s&quot;, or portraying open standards as a<br>
+voting process. Also, this depends on address reuse, so it&#39;s fundamenta=
+lly<br>
+flawed in design.<br>
+<br>
+Some way for people to express their support weighed by coins (without<br>
+losing/spending them), and possibly weighed by running a full node, might<b=
+r>
+still be desirable. The most straightforward way to do this is to support<b=
+r>
+message signatures somehow (ideally without using the same pubkey as<br>
+spending), and some [inherently unreliable, but perhaps useful if the<br>
+community &quot;colludes&quot; to not-cheat] way to sign with ones&#39; ful=
+l node.<br>
+<br>
+Note also that the BIP process already has BIP Comments for leaving textual=
+<br>
+opinions on the BIP unrelated to stake. See BIP 2 for details on that.<br>
+<br>
+Luke<br>
+<div><div class=3D"h5"><br>
+<br>
+On Thursday, February 02, 2017 7:39:51 PM t. khan via bitcoin-dev wrote:<br=
+>
+&gt; Please comment on this work-in-progress BIP.<br>
+&gt;<br>
+&gt; Thanks,<br>
+&gt;<br>
+&gt; - t.k.<br>
+&gt;<br>
+&gt; ----------------------<br>
+&gt; BIP: ?<br>
+&gt; Layer: Process<br>
+&gt; Title: Community Consensus Voting System<br>
+&gt; Author: t.khan &lt;<a href=3D"mailto:teekhan42@gmail.com">teekhan42@gm=
+ail.com</a>&gt;<br>
+&gt; Comments-Summary: No comments yet.<br>
+&gt; Comments-URI: TBD<br>
+&gt; Status: Draft<br>
+&gt; Type: Standards Track<br>
+&gt; Created: 2017-02-02<br>
+&gt; License: BSD-2<br>
+&gt; Voting Address: 3CoFA3JiK5wxe9ze2HoDGDTmZvkE5U<wbr>uwh8=C2=A0 (just an=
+ example, don=E2=80=99t<br>
+&gt; send to this!)<br>
+&gt;<br>
+&gt; Abstract<br>
+&gt; Community Consensus Voting System (CCVS) will allow developers to meas=
+ure<br>
+&gt; support for BIPs prior to implementation.<br>
+&gt;<br>
+&gt; Motivation<br>
+&gt; We currently have no way of measuring consensus for potential changes =
+to<br>
+&gt; the Bitcoin protocol. This is especially problematic for controversial=
+<br>
+&gt; changes such as the max block size limit. As a result, we have many<br=
+>
+&gt; proposed solutions but no clear direction.<br>
+&gt;<br>
+&gt; Also, due to our lack of ability to measure consensus, there is a gene=
+ral<br>
+&gt; feeling among many in the community that developers aren=E2=80=99t lis=
+tening to<br>
+&gt; their concerns. This is a valid complaint, as it=E2=80=99s not possibl=
+e to listen<br>
+&gt; to thousands of voices all shouting different things in a crowded<br>
+&gt; room=E2=80=94basically the situation in the Bitcoin community today.<b=
+r>
+&gt;<br>
+&gt; The CCVS will allow the general public, miners, companies using Bitcoi=
+n,<br>
+&gt; and developers to vote for their preferred BIP in a way that=E2=80=99s=
+ public and<br>
+&gt; relatively difficult (expensive) to manipulate.<br>
+&gt;<br>
+&gt; Specification<br>
+&gt; Each competing BIP will be assigned a unique bitcoin address which is =
+added<br>
+&gt; to each header. Anyone who wanted to vote would cast their ballot by<b=
+r>
+&gt; sending a small amount (0.0001 btc) to their preferred BIP&#39;s addre=
+ss. Each<br>
+&gt; transaction counts as 1 vote.<br>
+&gt;<br>
+&gt; Confirmed Vote Multiplier:<br>
+&gt; Mining Pools, companies using Bitcoin, and Core maintainers/contributo=
+rs<br>
+&gt; are allowed one confirmed vote each. A confirmed vote is worth 10,000x=
+ a<br>
+&gt; regular vote.<br>
+&gt;<br>
+&gt; For example:<br>
+&gt;<br>
+&gt; Slush Pool casts a vote for their preferred BIP and then states public=
+ly<br>
+&gt; (on their blog) their vote and the transaction ID and emails the URL t=
+o the<br>
+&gt; admin of this system. In the final tally, this vote will count as 10,0=
+00<br>
+&gt; votes.<br>
+&gt;<br>
+&gt; Coinbase, Antpool, BitPay, BitFury, etc., all do the same.<br>
+&gt;<br>
+&gt; Confirmed votes would be added to a new section in each respective BIP=
+ as a<br>
+&gt; public record.<br>
+&gt;<br>
+&gt; Voting would run for a pre-defined period, ending when a particular bl=
+ock<br>
+&gt; number is mined.<br>
+&gt;<br>
+&gt;<br>
+&gt; Rationale<br>
+&gt; Confirmed Vote Multiplier - The purpose of this is twofold; it gives a=
+<br>
+&gt; larger voice to organizations and the people who will have to do the w=
+ork<br>
+&gt; to implement whatever BIP the community prefers, and it will negate th=
+e<br>
+&gt; effect of anyone trying to skew the results by voting repeatedly.<br>
+&gt;<br>
+&gt; Definitions<br>
+&gt; Miner: any individual or organization that has mined at least one vali=
+d<br>
+&gt; block in the last 2016 blocks.<br>
+&gt;<br>
+&gt; Company using Bitcoin: any organization using Bitcoin for financial, a=
+sset<br>
+&gt; or other purposes, with either under development and released solution=
+s.<br>
+&gt;<br>
+&gt; Developer: any individual who has or had commit access, and any indivi=
+dual<br>
+&gt; who has authored a BIP<br>
+&gt;<br>
+&gt; Unresolved Issues<br>
+&gt; Node voting: It would be desirable for any full node running an up-to-=
+date<br>
+&gt; blockchain to also be able to vote with a multiplier (e.g. 100x). But =
+as<br>
+&gt; this would require code changes, it is outside the scope of this BIP.<=
+br>
+&gt;<br>
+&gt; Copyright<br>
+&gt; This BIP is licensed under the BSD 2-clause license.<br>
+</div></div>______________________________<wbr>_________________<br>
+bitcoin-dev mailing list<br>
+<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
+<wbr>linuxfoundation.org</a><br>
+<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
+rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
+/mailman/listinfo/bitcoin-<wbr>dev</a><br>
+</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
+nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">I like to provi=
+de some work at no charge to prove my value. Do you need a techie?=C2=A0 <b=
+r>I own <a href=3D"http://www.litmocracy.com" target=3D"_blank">Litmocracy<=
+/a> and <a href=3D"http://www.memeracing.net" target=3D"_blank">Meme Racing=
+</a> (in alpha). <br>I&#39;m the webmaster for <a href=3D"http://www.volunt=
+aryist.com" target=3D"_blank">The Voluntaryist</a> which now accepts Bitcoi=
+n.<br>I also code for <a href=3D"http://dollarvigilante.com/" target=3D"_bl=
+ank">The Dollar Vigilante</a>.<br>&quot;He ought to find it more profitable=
+ to play by the rules&quot; - Satoshi Nakamoto</div></div>
+</div>
+
+--001a113f4790994d3205479641a2--
+