Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C77A6C2C for ; Fri, 3 Feb 2017 19:22:14 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lf0-f43.google.com (mail-lf0-f43.google.com [209.85.215.43]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9712516C for ; Fri, 3 Feb 2017 19:22:12 +0000 (UTC) Received: by mail-lf0-f43.google.com with SMTP id z134so15241716lff.3 for ; Fri, 03 Feb 2017 11:22:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Lg4lYM/FTgesTSgkBHR9jObXDuJ2x+P9mFzcEmGNWEo=; b=cTkDgt1RfrtbJY5gKmkbjWDrNTm0KKMzBelhFLwMCVwCX4pBF8LbsB4fr46bWnggQu Yw+QJHolYGEGvnsgB1kFN8X/8KeF0702VFE/4nyoU/CbI4YzUeuNmPDD240QwRPV2iEJ 7KVVrmFHumyI+4Clx6Sb3elHbIL55Ky0uHNYgLlV7J3VCLIehDnM7H+FLj6ERLWfB1Ub MoWHM+hNFRL/IjV6Htcv/fTxm0BZZ3g0N9is3RHm74yvGSw6IL9E1PD+QtBF6o+klN73 wco98wuNb+B0SnL8gLMdw0I8yIOx8z+k8dgxhDs2B+fJYPwa3lwtQCom0vG0QyrXzTrm cgEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Lg4lYM/FTgesTSgkBHR9jObXDuJ2x+P9mFzcEmGNWEo=; b=MccWsRG4Wg8uxF44yUizUguZX60UUFwNovLA55p2d8L/XjsMfWkQmN4ASqBbVCGeHR 4gSQM55SABs+6Jrj9J0N62NVvp7wgYaUZJoQ/5oOObF6TRHb/y+C7py+R4vbJ3yshKY5 N2wYYa2Y2Gsa1aF8ujeDTmg2298r2qQLYnuji/SIARsYdxsIikQaseQ0L5c1ifh641vB kI9d2iWSwqj3ioGnxQulyxWjOXYK+LzAox87RUoOwrbmu+1urlTlMvoxfrzwqJlQhMg2 sBA0es7OmScxJjCXTM1eBRNXQ+vez387Swtxbbuv5w1DeSsxVyy8+Xe9nZkDBROvxKar nnDg== X-Gm-Message-State: AIkVDXKrW7TwUaWgZbS1sy32IP39vUYhnE4ra6APbJ74vQYTTOsu8fxDjBkoo+1WitzCsJrLBiE7s87qRLl59Q== X-Received: by 10.46.21.23 with SMTP id s23mr5904852ljd.54.1486149730888; Fri, 03 Feb 2017 11:22:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.21.92 with HTTP; Fri, 3 Feb 2017 11:22:10 -0800 (PST) In-Reply-To: References: <201702030024.10232.luke@dashjr.org> From: alp alp Date: Fri, 3 Feb 2017 13:22:10 -0600 Message-ID: To: "t. khan" Content-Type: multipart/alternative; boundary=94eb2c1cc926caf0a20547a532e9 X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sun, 05 Feb 2017 15:32:56 +0000 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 19:22:14 -0000 --94eb2c1cc926caf0a20547a532e9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable These are non-answers. Someone must decide. Someone must decide what kind of company counts (e.g. does a dark market seller count as a business? Does some guy who sells $10/year worth of goods using Bitcoin count the same as large companies like Coinbase/BitPay/Blockstream). Someone must decide which websites are checked for votes or addresses. Someone must decide if a rogue employee made a transaction on behalf of the company or not. Registering domain names is trivial and can be automated if the incentives were needed for it. You mention developers who have commit access. This excludes the vast majority of developers. You also don't mention which repositories count. Do the developers of bcoin count or not? These questions all would need to be answered before any kind of proposal like this can be taken seriously. Without these kinds of answers, this proposal is far from complete. On Fri, Feb 3, 2017 at 12:20 PM, t. khan wrote: > Most of these are answered in the BIP, but for clarity: > > >Who decides on which companies are eligible? > Preferably no one decides. The company would have to exist prior to the > vote, and would need a public-facing website. In the event of contested > votes (meaning someone finds evidence of a fake company), the admin could > investigate and post results. > > >Is there some kind of centralized database that one registers? > No. > > >Who administers this? > I don't know. I'm happy to volunteer, if no one else wants to be > responsible for it. The only task would be adding the confirmed votes to > each respective BIP. From there, everything's public and can be confirmed > by everyone. > > >What is to stop someone from creating a million fake companies to sway > the voting? > The logistics of doing that prevent it. But let's say 10 fake companies > ... first, you'd need to register ten domain names, host and customize th= e > website, all before the vote and in a way that no one would notice. > > >How does a company make it's vote? > Someone at the company sends a very small transaction to the BIP's vote > address. Someone at the company then posts what the vote was and its > transaction ID on the company's blog/twitter, etc., and then emails the U= RL > to the administrator. > > >How does one verify that the person voting on behalf of a company is > actually the correct person? > They post it on their company blog. > > On Fri, Feb 3, 2017 at 11:19 AM, alp alp via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> This proposal seems hopelessly broken. >> >> Who decides on which companies are eligible? Is there some kind of >> centralized database that one registers? Who administers this? What is= to >> stop someone from creating a million fake companies to sway the voting? >> How does a company make it's vote? How does one verify that the person >> voting on behalf of a company is actually the correct person? >> >> >> >> On Thu, Feb 2, 2017 at 7:32 PM, Dave Scotese via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >>> 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 suppor= ted >>> - 1bigblock or 12mbblk or whatever - based on a supporter-provided secr= et >>> 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. Coun= ting >>> actual, real people is still a technology in its infancy, and I don't t= hink >>> 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 be= en >>> 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 w= ould >>> 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 >>>> fundamentally >>>> 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 >>>> textual >>>> 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 wrot= e: >>>> > Please comment on this work-in-progress BIP. >>>> > >>>> > Thanks, >>>> > >>>> > - t.k. >>>> > >>>> > ---------------------- >>>> > BIP: ? >>>> > Layer: Process >>>> > Title: Community Consensus Voting System >>>> > Author: t.khan >>>> > 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 >>>> measure >>>> > support for BIPs prior to implementation. >>>> > >>>> > Motivation >>>> > We currently have no way of measuring consensus for potential change= s >>>> to >>>> > the Bitcoin protocol. This is especially problematic for controversi= al >>>> > 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 >>>> general >>>> > feeling among many in the community that developers aren=E2=80=99t l= istening >>>> to >>>> > their concerns. This is a valid complaint, as it=E2=80=99s not possi= ble 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 i= s >>>> 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/contributors >>>> > 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 >>>> publicly >>>> > (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,000 >>>> > 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 >>>> block >>>> > 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 >>>> work >>>> > 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). Bu= t >>>> as >>>> > 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 >>>> >>> >>> >>> >>> -- >>> I like to provide some work at no charge to prove my value. Do you need >>> a techie? >>> I own Litmocracy and Meme Racing >>> (in alpha). >>> I'm the webmaster for The Voluntaryist >>> which now accepts Bitcoin. >>> I also code for The Dollar Vigilante . >>> "He ought to find it more profitable to play by the rules" - Satoshi >>> Nakamoto >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > --94eb2c1cc926caf0a20547a532e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
These are non-answers.=C2=A0 Someone must decide.=C2=A0 So= meone must decide what kind of company counts (e.g. does a dark market sell= er count as a business?=C2=A0 Does some guy who sells $10/year worth of goo= ds using Bitcoin count the same as large companies like Coinbase/BitPay/Blo= ckstream).=C2=A0 Someone must decide which websites are checked for votes o= r addresses.=C2=A0 Someone must decide if a rogue employee made a transacti= on on behalf of the company or not.

Registering domain n= ames is trivial and can be automated if the incentives were needed for it.<= /div>

You mention developers who have commit access.=C2= =A0 This excludes the vast majority of developers.=C2=A0 You also don't= mention which repositories count.=C2=A0 Do the developers of bcoin count o= r not?

These questions all would need to be answer= ed before any kind of proposal like this can be taken seriously.=C2=A0 With= out these kinds of answers, this proposal is far from complete.
<= br>

On= Fri, Feb 3, 2017 at 12:20 PM, t. khan <teekhan42@gmail.com> wrote:
Most of these = are answered in the BIP, but for clarity:

>Who decides on which = companies are eligible?
Preferably no one decides. The company would have to ex= ist prior to the vote, and would need a public-facing website. In the event= of contested votes (meaning someone finds evidence of a fake company), the= admin could investigate and post results.

>Is there some kind of centra= lized database that one registers?
No.

>Who administers this?
I don't know. I'm happy to volunte= er, if no one else wants to be responsible for it. The only task would be a= dding the confirmed votes to each respective BIP. From there, everything= 9;s public and can be confirmed by everyone.
<= div>
>What is to stop someone fr= om creating a million fake companies to sway the voting?
The logistics of doing= that prevent it. But let's say 10 fake companies ... first, you'd = need to register ten domain names, host and customize the website, all befo= re the vote and in a way that no one would notice.

=
>How does a company = make it's vote?
Someone at the company sends a very small transaction to th= e BIP's vote address. Someone at the company then posts what the vote w= as and its transaction ID on the company's blog/twitter, etc., and then= emails the URL to the administrator.

>How does one verify that the = person voting on behalf of a company is actually the correct person?=
They post it on their = company blog.

On Fri, Feb 3, 2017 at 11:19 AM, alp alp vi= a bitcoin-dev <bitcoin-dev@lists.linuxfoundation.= org> wrote:
This pr= oposal seems hopelessly broken.

Who decides on which co= mpanies are eligible?=C2=A0 Is there some kind of centralized database that= one registers?=C2=A0 Who administers this?=C2=A0 What is to stop someone f= rom creating a million fake companies to sway the voting?=C2=A0 How does a = company make it's vote?=C2=A0 How does one verify that the person votin= g on behalf of a company is actually the correct person?

=


On Thu, Feb 2, 2017 at 7:32 PM, Da= ve Scotese via bitcoin-dev <bitcoin-dev@lists.linuxfou= ndation.org> wrote:
There are two ideas here for "on-chain" voting, b= oth 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:

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 bit= coin into their own vanity address and then whoever wants to can create a w= ebsite to display the matching addresses and explain that this is the finan= cial power in the hands of supporters and how to add your "financial p= ower vote."

Those who simply want to "buy votes"= ; can use their funds in marketing efforts to promote the proposal they sup= port.

This second method, of course, can be abused.=C2=A0 The = first actually requires people to control bitcoin in order to represent sup= port.=C2=A0 Counting actual, real people is still a technology in its infan= cy, and I don't think I want to see it progress much. People are not un= its, 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 t= he best people have died paupers. If bitcoin-discuss got more traffic, I th= ink this discussion would be better had on that list.

notplato=

On Thu, Fe= b 2, 2017 at 4:24 PM, Luke Dashjr via bitcoin-dev <bit= coin-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 fundamenta= lly
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' ful= l node.

Note also that the BIP process already has BIP Comments for leaving textual=
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=C2=A0 (just an= example, don=E2=80=99t
> send to this!)
>
> Abstract
> Community Consensus Voting System (CCVS) will allow developers to meas= ure
> support for BIPs prior to implementation.
>
> Motivation
> We currently have no way of measuring consensus for potential changes = to
> 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 gene= ral
> feeling among many in the community that developers aren=E2=80=99t lis= tening to
> their concerns. This is a valid complaint, as it=E2=80=99s not possibl= e 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 Bitcoi= n,
> 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 addre= ss. Each
> transaction counts as 1 vote.
>
> Confirmed Vote Multiplier:
> Mining Pools, companies using Bitcoin, and Core maintainers/contributo= rs
> 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 public= ly
> (on their blog) their vote and the transaction ID and emails the URL t= o the
> admin of this system. In the final tally, this vote will count as 10,0= 00
> 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 bl= ock
> 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 w= ork
> to implement whatever BIP the community prefers, and it will negate th= e
> effect of anyone trying to skew the results by voting repeatedly.
>
> Definitions
> Miner: any individual or organization that has mined at least one vali= d
> block in the last 2016 blocks.
>
> Company using Bitcoin: any organization using Bitcoin for financial, a= sset
> or other purposes, with either under development and released solution= s.
>
> Developer: any individual who has or had commit access, and any indivi= dual
> 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 = as
> this would require code changes, it is outside the scope of this BIP.<= br> >
> 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



--
I like to provide some= work at no charge to prove my value. Do you need a techie?=C2=A0
I own= Litmocracy and= Meme Racing (i= n alpha).
I'm the webmaster for The Voluntaryist which now accepts Bitcoin.
I= also code for Th= e Dollar Vigilante.
"He ought to find it more profitable to pla= y by the rules" - Satoshi Nakamoto

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev



_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev



--94eb2c1cc926caf0a20547a532e9--