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

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

[t. khan]

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

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.

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

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

[David Vorick]

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

I like the idea of having some way for developers to show that they've
given an idea legitimate consideration, as I feel some proposals are often
considered much more in depth before rejection than the proposer realizes,
however I don't think any sort of on-chain system really makes sense. It
complicates things a lot, adds code, incentives, etc. when really all you
care about is some sort of indication of consideration, support, or
rejection.

I also prefer to think of Bitcoin as a system of vetos rather than a system
of approvals. A lot of times changes will be small, highly technical, and
have no visible impact to your every day user. These types of changes don't
really need support outside the devs. Furthermore, I frankly don't give a
crap if we proposal has support from 85% of the participants if there is a
legitimate technical, social, or political reason that it is a bad idea.

And finally, I don't think it should cost money or political power to raise
an objection. A 13yo who has never been seen before should be able to raise
an objection if they indeed have a legitimate objection. Involving money is
almost certainly going to shut down important valid opinions.

And again, I mostly agree with the motivation. It would be good if it were
easier to figure out who had considered a proposal and what their
objections or praises were. But I would like to see that without any
systemization around what is required to pass or fail a proposal, and with
no barrier to entry (such as voting or sending coins or having a recognized
name like 'Bitfury') to provide an opinion.

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

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

[Luke Dashjr]

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.

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

[Dave Scotese]

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

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

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

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

[alp alp]

[-- 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 --]

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

[t. khan]

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

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 the
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 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 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 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
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

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

[alp alp]

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

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 <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 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 the
> 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 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 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 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
>>>
>>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>

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

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

[Chris Priest]

Personally I think once the blocksize arguments are solved, there will
be no more contentious changes for this voting system to deal with.
What other contentious issues have come up in the past 3 years or so
that wasn't blocksize/scaling related? Do other protocols like TCP/IP
and the HTTP protocol have developers arguing every day over issues no
one can agree on?

On 2/3/17, t. khan via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> 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 the
> 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 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 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
>>> 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
>>>
>>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>

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

[t. khan]

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

On Fri, Feb 3, 2017 at 2:22 PM, alp alp <alp.bitcoin@gmail.com> wrote:

> 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.
>

The less centralized decision making there is, the better. All confirmed
votes will be added to each BIP, so everyone can make their own decision as
to whether or not they want to count it. Remember, this is about gauging
community support.

Rogue employees?: The company in question would have to deal with that.


> Registering domain names is trivial and can be automated if the incentives
> were needed for it.
>

Mountains out of mole hills here—if the domain name is registered after
voting is called, that would be a pretty clear indicator it's a fake
company.


> 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?
>

After further consideration, and as the goal of this is to determine what
the community will support, developers won't have a confirmed vote. They
would get a standard vote though, just like everyone else.

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

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

[t. khan]

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

On Thu, Feb 2, 2017 at 7:24 PM, Luke Dashjr <luke@dashjr.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.
>

The point of this is it's available right now. It's not ideal, but it will
work. It doesn't require any code and we can do it today.

In case you haven't been paying attention; there's already enough support
for Unlimited to prevent SegWit from ever being adopted. Without
significant community outreach (which is the purpose of the CCVS) and a
compelling solution to max block size, Core as a product is dead.

Also, you need to be pretty paranoid to believe that address reuse is an
issue in this situation.

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.
>

This does nothing for the community in general. Plus there's no way to
measure that sort of feedback.

- t.k.

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

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

[Staf Verhaegen]

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

Chris Priest via bitcoin-dev schreef op vr 03-02-2017 om 16:57 [-0800]:
> Personally I think once the blocksize arguments are solved, there will
> be no more contentious changes for this voting system to deal with.
> What other contentious issues have come up in the past 3 years or so
> that wasn't blocksize/scaling related? Do other protocols like TCP/IP
> and the HTTP protocol have developers arguing every day over issues no
> one can agree on?

Yes, DRM for example.
Staf.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

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

[Peter Todd]

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

On Sat, Feb 11, 2017 at 04:57:46PM +0100, Staf Verhaegen via bitcoin-dev wrote:
> Chris Priest via bitcoin-dev schreef op vr 03-02-2017 om 16:57 [-0800]:
> > Personally I think once the blocksize arguments are solved, there will
> > be no more contentious changes for this voting system to deal with.
> > What other contentious issues have come up in the past 3 years or so
> > that wasn't blocksize/scaling related? Do other protocols like TCP/IP
> > and the HTTP protocol have developers arguing every day over issues no
> > one can agree on?
> 
> Yes, DRM for example.

...and note how, like blocksize, the roots of the DRM argument at W3C aren't a
technical disagreement, but rather a political disagreement.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]