diff options
author | Dave Scotese <dscotese@litmocracy.com> | 2017-02-02 17:32:34 -0800 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2017-02-03 01:32:37 +0000 |
commit | 114f51ce0fc8848ba2ca0d1fa976e2b956975f85 (patch) | |
tree | f0b64f582615b3d43f474d6c818aba125f6d3585 | |
parent | de3071e2c5ef43afb2528f118d90e6e52eaf46e8 (diff) | |
download | pi-bitcoindev-114f51ce0fc8848ba2ca0d1fa976e2b956975f85.tar.gz pi-bitcoindev-114f51ce0fc8848ba2ca0d1fa976e2b956975f85.zip |
Re: [bitcoin-dev] [Pre-BIP] Community Consensus Voting System
-rw-r--r-- | 36/681e5f1fd9cf98e5d11d437cbde06654926fd7 | 454 |
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 "on-chain= +" 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."<br><br></div>Those who simply want to &quo= +t;buy votes" 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'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'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"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" ta= +rget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></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 "vote= +s", or portraying open standards as a<br> +voting process. Also, this depends on address reuse, so it'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 "colludes" to not-cheat] way to sign with ones' 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= +> +> Please comment on this work-in-progress BIP.<br> +><br> +> Thanks,<br> +><br> +> - t.k.<br> +><br> +> ----------------------<br> +> BIP: ?<br> +> Layer: Process<br> +> Title: Community Consensus Voting System<br> +> Author: t.khan <<a href=3D"mailto:teekhan42@gmail.com">teekhan42@gm= +ail.com</a>><br> +> Comments-Summary: No comments yet.<br> +> Comments-URI: TBD<br> +> Status: Draft<br> +> Type: Standards Track<br> +> Created: 2017-02-02<br> +> License: BSD-2<br> +> Voting Address: 3CoFA3JiK5wxe9ze2HoDGDTmZvkE5U<wbr>uwh8=C2=A0 (just an= + example, don=E2=80=99t<br> +> send to this!)<br> +><br> +> Abstract<br> +> Community Consensus Voting System (CCVS) will allow developers to meas= +ure<br> +> support for BIPs prior to implementation.<br> +><br> +> Motivation<br> +> We currently have no way of measuring consensus for potential changes = +to<br> +> the Bitcoin protocol. This is especially problematic for controversial= +<br> +> changes such as the max block size limit. As a result, we have many<br= +> +> proposed solutions but no clear direction.<br> +><br> +> Also, due to our lack of ability to measure consensus, there is a gene= +ral<br> +> feeling among many in the community that developers aren=E2=80=99t lis= +tening to<br> +> their concerns. This is a valid complaint, as it=E2=80=99s not possibl= +e to listen<br> +> to thousands of voices all shouting different things in a crowded<br> +> room=E2=80=94basically the situation in the Bitcoin community today.<b= +r> +><br> +> The CCVS will allow the general public, miners, companies using Bitcoi= +n,<br> +> and developers to vote for their preferred BIP in a way that=E2=80=99s= + public and<br> +> relatively difficult (expensive) to manipulate.<br> +><br> +> Specification<br> +> Each competing BIP will be assigned a unique bitcoin address which is = +added<br> +> to each header. Anyone who wanted to vote would cast their ballot by<b= +r> +> sending a small amount (0.0001 btc) to their preferred BIP's addre= +ss. Each<br> +> transaction counts as 1 vote.<br> +><br> +> Confirmed Vote Multiplier:<br> +> Mining Pools, companies using Bitcoin, and Core maintainers/contributo= +rs<br> +> are allowed one confirmed vote each. A confirmed vote is worth 10,000x= + a<br> +> regular vote.<br> +><br> +> For example:<br> +><br> +> Slush Pool casts a vote for their preferred BIP and then states public= +ly<br> +> (on their blog) their vote and the transaction ID and emails the URL t= +o the<br> +> admin of this system. In the final tally, this vote will count as 10,0= +00<br> +> votes.<br> +><br> +> Coinbase, Antpool, BitPay, BitFury, etc., all do the same.<br> +><br> +> Confirmed votes would be added to a new section in each respective BIP= + as a<br> +> public record.<br> +><br> +> Voting would run for a pre-defined period, ending when a particular bl= +ock<br> +> number is mined.<br> +><br> +><br> +> Rationale<br> +> Confirmed Vote Multiplier - The purpose of this is twofold; it gives a= +<br> +> larger voice to organizations and the people who will have to do the w= +ork<br> +> to implement whatever BIP the community prefers, and it will negate th= +e<br> +> effect of anyone trying to skew the results by voting repeatedly.<br> +><br> +> Definitions<br> +> Miner: any individual or organization that has mined at least one vali= +d<br> +> block in the last 2016 blocks.<br> +><br> +> Company using Bitcoin: any organization using Bitcoin for financial, a= +sset<br> +> or other purposes, with either under development and released solution= +s.<br> +><br> +> Developer: any individual who has or had commit access, and any indivi= +dual<br> +> who has authored a BIP<br> +><br> +> Unresolved Issues<br> +> Node voting: It would be desirable for any full node running an up-to-= +date<br> +> blockchain to also be able to vote with a multiplier (e.g. 100x). But = +as<br> +> this would require code changes, it is outside the scope of this BIP.<= +br> +><br> +> Copyright<br> +> 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'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>"He ought to find it more profitable= + to play by the rules" - Satoshi Nakamoto</div></div> +</div> + +--001a113f4790994d3205479641a2-- + |