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

Discussion:

t. khan via bitcoin-dev

2017-02-02 19:39:51 UTC

Please comment on this work-in-progress BIP.

Thanks,

- t.k.

----------------------
BIP: ?
Layer: Process
Title: Community Consensus Voting System
Author: t.khan <***@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.

David Vorick via bitcoin-dev

2017-02-02 23:19:39 UTC

Permalink

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.

Luke Dashjr via bitcoin-dev

2017-02-03 00:24:09 UTC

Permalink

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

Post by t. khan via bitcoin-dev
Please comment on this work-in-progress BIP.
Thanks,
- t.k.
----------------------
BIP: ?
Layer: Process
Title: Community Consensus Voting System
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.
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.
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.

Dave Scotese via bitcoin-dev

2017-02-03 01:32:34 UTC

Permalink

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 <

Post by Luke Dashjr via bitcoin-dev
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

donât

Post by t. khan via bitcoin-dev
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

Post by t. khan via bitcoin-dev
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

Post by t. khan via bitcoin-dev
transaction counts as 1 vote.
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.
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

Post by t. khan via bitcoin-dev
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

Post by t. khan via bitcoin-dev
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

Post by t. khan via bitcoin-dev
or other purposes, with either under development and released solutions.
Developer: any individual who has or had commit access, and any

individual

Post by t. khan via bitcoin-dev
who has authored a BIP
Unresolved Issues
Node voting: It would be desirable for any full node running an

up-to-date

Post by t. khan via bitcoin-dev
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
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

alp alp via bitcoin-dev

2017-02-03 16:19:19 UTC

Permalink

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 <

Post by Dave Scotese via bitcoin-dev
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
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 <

donât

Post by t. khan via bitcoin-dev
send to this!)
Abstract
Community Consensus Voting System (CCVS) will allow developers to

measure

Post by t. khan via bitcoin-dev
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

Post by t. khan via bitcoin-dev
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

Post by t. khan via bitcoin-dev
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

Post by t. khan via bitcoin-dev
relatively difficult (expensive) to manipulate.
Specification
Each competing BIP will be assigned a unique bitcoin address which is

added

Post by t. khan via bitcoin-dev
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

the

as a

Post by t. khan via bitcoin-dev
public record.
Voting would run for a pre-defined period, ending when a particular

block

Post by t. khan via bitcoin-dev
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

Post by t. khan via bitcoin-dev
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

Post by t. khan via bitcoin-dev
or other purposes, with either under development and released solutions.
Developer: any individual who has or had commit access, and any

individual

Post by t. khan via bitcoin-dev
who has authored a BIP
Unresolved Issues
Node voting: It would be desirable for any full node running an

up-to-date

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

t. khan via bitcoin-dev

2017-02-03 18:20:13 UTC

Permalink

Post by alp alp via bitcoin-dev
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.

Post by alp alp via bitcoin-dev
Is there some kind of centralized database that one registers?

No.

Post by alp alp via bitcoin-dev
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.

Post by alp alp via bitcoin-dev
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.

Post by alp alp via bitcoin-dev
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.

Post by alp alp via bitcoin-dev
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 <

Post by alp alp via bitcoin-dev
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 <

Post by Dave Scotese via bitcoin-dev
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
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 <

Post by Luke Dashjr via bitcoin-dev
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

donât

Post by t. khan via bitcoin-dev
send to this!)
Abstract
Community Consensus Voting System (CCVS) will allow developers to

measure

Post by t. khan via bitcoin-dev
support for BIPs prior to implementation.
Motivation
We currently have no way of measuring consensus for potential changes

Post by t. khan via bitcoin-dev
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

Post by t. khan via bitcoin-dev
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

Bitcoin,

Post by t. khan via bitcoin-dev
and developers to vote for their preferred BIP in a way thatâs public

and

Post by t. khan via bitcoin-dev
relatively difficult (expensive) to manipulate.
Specification
Each competing BIP will be assigned a unique bitcoin address which is

added

Post by t. khan via bitcoin-dev
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

Post by t. khan via bitcoin-dev
transaction counts as 1 vote.
Mining Pools, companies using Bitcoin, and Core

maintainers/contributors

Post by t. khan via bitcoin-dev
are allowed one confirmed vote each. A confirmed vote is worth 10,000x

Post by t. khan via bitcoin-dev
regular vote.
Slush Pool casts a vote for their preferred BIP and then states

publicly

Post by t. khan via bitcoin-dev
(on their blog) their vote and the transaction ID and emails the URL

to the

Post by t. khan via bitcoin-dev
admin of this system. In the final tally, this vote will count as

10,000

Post by t. khan via bitcoin-dev
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

Post by t. khan via bitcoin-dev
public record.
Voting would run for a pre-defined period, ending when a particular

block

work

asset

Post by t. khan via bitcoin-dev
or other purposes, with either under development and released

solutions.

Post by t. khan via bitcoin-dev
Developer: any individual who has or had commit access, and any

individual

Post by t. khan via bitcoin-dev
who has authored a BIP
Unresolved Issues
Node voting: It would be desirable for any full node running an

up-to-date

Post by t. khan via bitcoin-dev
blockchain to also be able to vote with a multiplier (e.g. 100x). But

Post by t. khan via bitcoin-dev
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
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

alp alp via bitcoin-dev

2017-02-03 19:22:10 UTC

Permalink

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.

Post by t. khan via bitcoin-dev

Post by alp alp via bitcoin-dev
Who decides on which companies are eligible?

Post by alp alp via bitcoin-dev
Is there some kind of centralized database that one registers?

No.

Post by alp alp via bitcoin-dev
Who administers this?

Post by alp alp via bitcoin-dev
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.

Post by alp alp via bitcoin-dev
How does a company make it's vote?

Post by alp alp via bitcoin-dev
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 <

Post by Dave Scotese via bitcoin-dev
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
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 <

example, donât

Post by t. khan via bitcoin-dev
send to this!)
Abstract
Community Consensus Voting System (CCVS) will allow developers to

measure

Post by t. khan via bitcoin-dev
support for BIPs prior to implementation.
Motivation
We currently have no way of measuring consensus for potential changes

general

Post by t. khan via bitcoin-dev
feeling among many in the community that developers arenât listening

Post by t. khan via bitcoin-dev
their concerns. This is a valid complaint, as itâs not possible to

listen

Bitcoin,

Post by t. khan via bitcoin-dev
and developers to vote for their preferred BIP in a way thatâs public

and

Post by t. khan via bitcoin-dev
relatively difficult (expensive) to manipulate.
Specification
Each competing BIP will be assigned a unique bitcoin address which is

added

Post by t. khan via bitcoin-dev
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

Post by t. khan via bitcoin-dev
transaction counts as 1 vote.
Mining Pools, companies using Bitcoin, and Core

maintainers/contributors

Post by t. khan via bitcoin-dev
are allowed one confirmed vote each. A confirmed vote is worth

10,000x a

Post by t. khan via bitcoin-dev
regular vote.
Slush Pool casts a vote for their preferred BIP and then states

publicly

Post by t. khan via bitcoin-dev
(on their blog) their vote and the transaction ID and emails the URL

to the

Post by t. khan via bitcoin-dev
admin of this system. In the final tally, this vote will count as

10,000

Post by t. khan via bitcoin-dev
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

Post by t. khan via bitcoin-dev
public record.
Voting would run for a pre-defined period, ending when a particular

block

work

Post by t. khan via bitcoin-dev
to implement whatever BIP the community prefers, and it will negate

the

Post by t. khan via bitcoin-dev
effect of anyone trying to skew the results by voting repeatedly.
Definitions
Miner: any individual or organization that has mined at least one

valid

Post by t. khan via bitcoin-dev
block in the last 2016 blocks.
Company using Bitcoin: any organization using Bitcoin for financial,

asset

Post by t. khan via bitcoin-dev
or other purposes, with either under development and released

solutions.

Post by t. khan via bitcoin-dev
Developer: any individual who has or had commit access, and any

individual

Post by t. khan via bitcoin-dev
who has authored a BIP
Unresolved Issues
Node voting: It would be desirable for any full node running an

up-to-date

Post by t. khan via bitcoin-dev
blockchain to also be able to vote with a multiplier (e.g. 100x). But

Post by t. khan via bitcoin-dev
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
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

t. khan via bitcoin-dev

2017-02-04 21:23:19 UTC

Permalink

Post by alp alp via bitcoin-dev
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.

Post by alp alp via bitcoin-dev
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.

Post by alp alp via bitcoin-dev
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.

Chris Priest via bitcoin-dev

2017-02-04 00:57:52 UTC

Permalink

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

Post by t. khan via bitcoin-dev

Post by alp alp via bitcoin-dev
Who decides on which companies are eligible?

Post by alp alp via bitcoin-dev
Is there some kind of centralized database that one registers?

No.

Post by alp alp via bitcoin-dev
Who administers this?

Post by alp alp via bitcoin-dev
What is to stop someone from creating a million fake companies to sway the

Post by alp alp via bitcoin-dev
How does a company make it's vote?

Post by alp alp via bitcoin-dev
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 <

Post by Dave Scotese via bitcoin-dev
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
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 <

don’t

Post by t. khan via bitcoin-dev
send to this!)
Abstract
Community Consensus Voting System (CCVS) will allow developers to

measure

Post by t. khan via bitcoin-dev
support for BIPs prior to implementation.
Motivation
We currently have no way of measuring consensus for potential changes

Post by t. khan via bitcoin-dev
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

Post by t. khan via bitcoin-dev
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

Post by t. khan via bitcoin-dev
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,

Post by t. khan via bitcoin-dev
and developers to vote for their preferred BIP in a way that’s public

and

Post by t. khan via bitcoin-dev
relatively difficult (expensive) to manipulate.
Specification
Each competing BIP will be assigned a unique bitcoin address which is

added

Post by t. khan via bitcoin-dev
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

Post by t. khan via bitcoin-dev
transaction counts as 1 vote.
Mining Pools, companies using Bitcoin, and Core

maintainers/contributors

Post by t. khan via bitcoin-dev
are allowed one confirmed vote each. A confirmed vote is worth 10,000x

Post by t. khan via bitcoin-dev
regular vote.
Slush Pool casts a vote for their preferred BIP and then states

publicly

Post by t. khan via bitcoin-dev
(on their blog) their vote and the transaction ID and emails the URL

to the

Post by t. khan via bitcoin-dev
admin of this system. In the final tally, this vote will count as

10,000

Post by t. khan via bitcoin-dev
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

Post by t. khan via bitcoin-dev
public record.
Voting would run for a pre-defined period, ending when a particular

block

work

asset

Post by t. khan via bitcoin-dev
or other purposes, with either under development and released

solutions.

Post by t. khan via bitcoin-dev
Developer: any individual who has or had commit access, and any

individual

Post by t. khan via bitcoin-dev
who has authored a BIP
Unresolved Issues
Node voting: It would be desirable for any full node running an

up-to-date

Post by t. khan via bitcoin-dev
blockchain to also be able to vote with a multiplier (e.g. 100x). But

Post by t. khan via bitcoin-dev
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
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

Staf Verhaegen via bitcoin-dev

2017-02-11 15:57:46 UTC

Permalink

Post by Chris Priest via bitcoin-dev
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.

Peter Todd via bitcoin-dev

2017-02-14 12:33:17 UTC

Permalink

Post by Staf Verhaegen via bitcoin-dev

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

t. khan via bitcoin-dev

2017-02-04 22:02:00 UTC

Permalink

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

Post by Luke Dashjr via bitcoin-dev
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.

Continue reading on narkive:

Search results for '[bitcoin-dev] [Pre-BIP] Community Consensus Voting System' (Questions and Answers)

replies

Do you think Americans are too arrogant?

started 2011-01-16 13:03:13 UTC

politics

replies

Excuse me? Is this a Non-Christain community? I ask because ?

started 2008-08-21 13:09:51 UTC

religion & spirituality