Re: [bitcoin-dev] [Pre-BIP] Community Consensus Voting System

[alp alp <alp.bitcoin@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 7669 bytes --]

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 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 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 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’t
>> > 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 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
>> general
>> > feeling among many in the community that developers aren’t listening to
>> > their concerns. This is a valid complaint, as it’s not possible to
>> listen
>> > to thousands of voices all shouting different things in a crowded
>> > room—basically 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’s 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/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). But 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 <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
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 9593 bytes --]