AbstractCommunity Consensus Voting System (CCVS) will allow developers to measuresupport for BIPs prior to implementation.

MotivationWe currently have no way of measuring consensus for potential changes tothe Bitcoin protocol. This is especially problematic for controversialchanges such as the max block size limit. As a result, we have manyproposed solutions but no clear direction.

Also, due to our lack of ability to measure consensus, there is a generalfeeling among many in the community that developers arenât listening totheir concerns. This is a valid complaint, as itâs not possible to listento thousands of voices all shouting different things in a crowdedroomâ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 andrelatively difficult (expensive) to manipulate.

SpecificationEach competing BIP will be assigned a unique bitcoin address which is addedto each header. Anyone who wanted to vote would cast their ballot bysending a small amount (0.0001 btc) to their preferred BIP's address. Eachtransaction counts as 1 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 theadmin of this system. In the final tally, this vote will count as 10,000votes.

Coinbase, Antpool, BitPay, BitFury, etc., all do the same.

Confirmed votes would be added to a new section in each respective BIP as apublic record.

Voting would run for a pre-defined period, ending when a particular blocknumber is mined.

RationaleConfirmed Vote Multiplier - The purpose of this is twofold; it gives alarger voice to organizations and the people who will have to do the workto implement whatever BIP the community prefers, and it will negate theeffect of anyone trying to skew the results by voting repeatedly.

DefinitionsMiner: any individual or organization that has mined at least one validblock in the last 2016 blocks.

Company using Bitcoin: any organization using Bitcoin for financial, assetor other purposes, with either under development and released solutions.

Developer: any individual who has or had commit access, and any individualwho has authored a BIP

Unresolved IssuesNode voting: It would be desirable for any full node running an up-to-dateblockchain to also be able to vote with a multiplier (e.g. 100x). But asthis would require code changes, it is outside the scope of this BIP.

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

I also prefer to think of Bitcoin as a system of vetos rather than a systemof approvals. A lot of times changes will be small, highly technical, andhave no visible impact to your every day user. These types of changes don'treally need support outside the devs. Furthermore, I frankly don't give acrap if we proposal has support from 85% of the participants if there is alegitimate 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 raisean objection. A 13yo who has never been seen before should be able to raisean objection if they indeed have a legitimate objection. Involving money isalmost certainly going to shut down important valid opinions.

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

Strongly disagree with buying "votes", or portraying open standards as avoting process. Also, this depends on address reuse, so it's fundamentallyflawed in design.

Some way for people to express their support weighed by coins (withoutlosing/spending them), and possibly weighed by running a full node, mightstill be desirable. The most straightforward way to do this is to supportmessage signatures somehow (ideally without using the same pubkey asspending), and some [inherently unreliable, but perhaps useful if thecommunity "colludes" to not-cheat] way to sign with ones' full node.

Note also that the BIP process already has BIP Comments for leaving textualopinions on the BIP unrelated to stake. See BIP 2 for details on that.

Luke

Post by t. khan via bitcoin-devPlease comment on this work-in-progress BIP.Thanks,- t.k.----------------------BIP: ?Layer: ProcessTitle: Community Consensus Voting SystemComments-Summary: No comments yet.Comments-URI: TBDStatus: DraftType: Standards TrackCreated: 2017-02-02License: BSD-2Voting Address: 3CoFA3JiK5wxe9ze2HoDGDTmZvkE5Uuwh8 (just an example, don’tsend to this!)AbstractCommunity Consensus Voting System (CCVS) will allow developers to measuresupport for BIPs prior to implementation.MotivationWe currently have no way of measuring consensus for potential changes tothe Bitcoin protocol. This is especially problematic for controversialchanges such as the max block size limit. As a result, we have manyproposed solutions but no clear direction.Also, due to our lack of ability to measure consensus, there is a generalfeeling among many in the community that developers aren’t listening totheir concerns. This is a valid complaint, as it’s not possible to listento thousands of voices all shouting different things in a crowdedroom—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 andrelatively difficult (expensive) to manipulate.SpecificationEach competing BIP will be assigned a unique bitcoin address which is addedto each header. Anyone who wanted to vote would cast their ballot bysending a small amount (0.0001 btc) to their preferred BIP's address. Eachtransaction counts as 1 vote.Mining Pools, companies using Bitcoin, and Core maintainers/contributorsare allowed one confirmed vote each. A confirmed vote is worth 10,000x aregular 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 theadmin of this system. In the final tally, this vote will count as 10,000votes.Coinbase, Antpool, BitPay, BitFury, etc., all do the same.Confirmed votes would be added to a new section in each respective BIP as apublic record.Voting would run for a pre-defined period, ending when a particular blocknumber is mined.RationaleConfirmed Vote Multiplier - The purpose of this is twofold; it gives alarger voice to organizations and the people who will have to do the workto implement whatever BIP the community prefers, and it will negate theeffect of anyone trying to skew the results by voting repeatedly.DefinitionsMiner: any individual or organization that has mined at least one validblock in the last 2016 blocks.Company using Bitcoin: any organization using Bitcoin for financial, assetor other purposes, with either under development and released solutions.Developer: any individual who has or had commit access, and any individualwho has authored a BIPUnresolved IssuesNode voting: It would be desirable for any full node running an up-to-dateblockchain to also be able to vote with a multiplier (e.g. 100x). But asthis would require code changes, it is outside the scope of this BIP.CopyrightThis BIP is licensed under the BSD 2-clause license.

There are two ideas here for "on-chain" voting, both of which requirechanges to the software. I agree with David that on-chain solutionscomplicate things. Both proposals can be effected without any softwarechanges:

Those who wish to use proof of stake can provide a service for makingvanity addresses containing some indicator of the proposal to be supported- 1bigblock or 12mbblk or whatever - based on a supporter-provided secretkey, and then supporters can move their bitcoin into their own vanityaddress and then whoever wants to can create a website to display thematching addresses and explain that this is the financial power in thehands of supporters and how to add your "financial power vote."

Those who simply want to "buy votes" can use their funds in marketingefforts to promote the proposal they support.

This second method, of course, can be abused. The first actually requirespeople 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 wantto see it progress much. People are not units, but individuals, and theirvalue only becomes correlated to their net worth after they've been alivefor many years, and even then, some of the best people have died paupers.If bitcoin-discuss got more traffic, I think this discussion would bebetter 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-devStrongly disagree with buying "votes", or portraying open standards as avoting process. Also, this depends on address reuse, so it's fundamentallyflawed in design.Some way for people to express their support weighed by coins (withoutlosing/spending them), and possibly weighed by running a full node, mightstill be desirable. The most straightforward way to do this is to supportmessage signatures somehow (ideally without using the same pubkey asspending), and some [inherently unreliable, but perhaps useful if thecommunity "colludes" to not-cheat] way to sign with ones' full node.Note also that the BIP process already has BIP Comments for leaving textualopinions on the BIP unrelated to stake. See BIP 2 for details on that.Luke

Post by t. khan via bitcoin-devsend to this!)AbstractCommunity Consensus Voting System (CCVS) will allow developers to measuresupport for BIPs prior to implementation.MotivationWe currently have no way of measuring consensus for potential changes tothe Bitcoin protocol. This is especially problematic for controversialchanges such as the max block size limit. As a result, we have manyproposed solutions but no clear direction.Also, due to our lack of ability to measure consensus, there is a generalfeeling among many in the community that developers arenât listening totheir concerns. This is a valid complaint, as itâs not possible to listento thousands of voices all shouting different things in a crowdedroomâ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 andrelatively difficult (expensive) to manipulate.SpecificationEach competing BIP will be assigned a unique bitcoin address which is

added

Post by t. khan via bitcoin-devto each header. Anyone who wanted to vote would cast their ballot bysending a small amount (0.0001 btc) to their preferred BIP's address.

Each

Post by t. khan via bitcoin-devtransaction counts as 1 vote.Mining Pools, companies using Bitcoin, and Core maintainers/contributorsare allowed one confirmed vote each. A confirmed vote is worth 10,000x aregular 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-devadmin of this system. In the final tally, this vote will count as 10,000votes.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-devpublic record.Voting would run for a pre-defined period, ending when a particular blocknumber is mined.RationaleConfirmed Vote Multiplier - The purpose of this is twofold; it gives alarger voice to organizations and the people who will have to do the workto implement whatever BIP the community prefers, and it will negate theeffect of anyone trying to skew the results by voting repeatedly.DefinitionsMiner: any individual or organization that has mined at least one validblock in the last 2016 blocks.Company using Bitcoin: any organization using Bitcoin for financial,

asset

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

Post by t. khan via bitcoin-devblockchain to also be able to vote with a multiplier (e.g. 100x). But asthis would require code changes, it is outside the scope of this BIP.CopyrightThis BIP is licensed under the BSD 2-clause license.

--I like to provide some work at no charge to prove my value. Do you need atechie?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> whichnow accepts Bitcoin.I also code for The Dollar Vigilante <http://dollarvigilante.com/>."He ought to find it more profitable to play by the rules" - SatoshiNakamoto

Who decides on which companies are eligible? Is there some kind ofcentralized database that one registers? Who administers this? What is tostop 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 personvoting 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-devThere are two ideas here for "on-chain" voting, both of which requirechanges to the software. I agree with David that on-chain solutionscomplicate things. Both proposals can be effected without any softwareThose who wish to use proof of stake can provide a service for makingvanity addresses containing some indicator of the proposal to be supported- 1bigblock or 12mbblk or whatever - based on a supporter-provided secretkey, and then supporters can move their bitcoin into their own vanityaddress and then whoever wants to can create a website to display thematching addresses and explain that this is the financial power in thehands of supporters and how to add your "financial power vote."Those who simply want to "buy votes" can use their funds in marketingefforts to promote the proposal they support.This second method, of course, can be abused. The first actually requirespeople 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 wantto see it progress much. People are not units, but individuals, and theirvalue only becomes correlated to their net worth after they've been alivefor many years, and even then, some of the best people have died paupers.If bitcoin-discuss got more traffic, I think this discussion would bebetter had on that list.notplatoOn Thu, Feb 2, 2017 at 4:24 PM, Luke Dashjr via bitcoin-dev <

Post by Luke Dashjr via bitcoin-devStrongly disagree with buying "votes", or portraying open standards as avoting process. Also, this depends on address reuse, so it's fundamentallyflawed in design.Some way for people to express their support weighed by coins (withoutlosing/spending them), and possibly weighed by running a full node, mightstill be desirable. The most straightforward way to do this is to supportmessage signatures somehow (ideally without using the same pubkey asspending), and some [inherently unreliable, but perhaps useful if thecommunity "colludes" to not-cheat] way to sign with ones' full node.Note also that the BIP process already has BIP Comments for leaving textualopinions on the BIP unrelated to stake. See BIP 2 for details on that.Luke

Post by t. khan via bitcoin-devsupport for BIPs prior to implementation.MotivationWe currently have no way of measuring consensus for potential changes tothe Bitcoin protocol. This is especially problematic for controversialchanges such as the max block size limit. As a result, we have manyproposed 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-devfeeling among many in the community that developers arenât listening totheir concerns. This is a valid complaint, as itâs not possible to

listen

Post by t. khan via bitcoin-devto thousands of voices all shouting different things in a crowdedroomâ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-devrelatively difficult (expensive) to manipulate.SpecificationEach competing BIP will be assigned a unique bitcoin address which is

added

Post by t. khan via bitcoin-devto each header. Anyone who wanted to vote would cast their ballot bysending a small amount (0.0001 btc) to their preferred BIP's address.

Each

Post by t. khan via bitcoin-devtransaction counts as 1 vote.Mining Pools, companies using Bitcoin, and Core maintainers/contributorsare allowed one confirmed vote each. A confirmed vote is worth 10,000x aregular 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-devadmin of this system. In the final tally, this vote will count as 10,000votes.Coinbase, Antpool, BitPay, BitFury, etc., all do the same.Confirmed votes would be added to a new section in each respective BIP

Post by t. khan via bitcoin-devnumber is mined.RationaleConfirmed Vote Multiplier - The purpose of this is twofold; it gives alarger voice to organizations and the people who will have to do the

work

Post by t. khan via bitcoin-devto implement whatever BIP the community prefers, and it will negate theeffect of anyone trying to skew the results by voting repeatedly.DefinitionsMiner: any individual or organization that has mined at least one validblock in the last 2016 blocks.Company using Bitcoin: any organization using Bitcoin for financial,

asset

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

Post by t. khan via bitcoin-devblockchain to also be able to vote with a multiplier (e.g. 100x). But asthis would require code changes, it is outside the scope of this BIP.CopyrightThis BIP is licensed under the BSD 2-clause license.

--I like to provide some work at no charge to prove my value. Do you need atechie?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" - SatoshiNakamoto_______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Preferably no one decides. The company would have to exist prior to thevote, and would need a public-facing website. In the event of contestedvotes (meaning someone finds evidence of a fake company), the admin couldinvestigate and post results.

I don't know. I'm happy to volunteer, if no one else wants to beresponsible for it. The only task would be adding the confirmed votes toeach respective BIP. From there, everything's public and can be confirmedby everyone.

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 thewebsite, all before the vote and in a way that no one would notice.

Someone at the company sends a very small transaction to the BIP's voteaddress. Someone at the company then posts what the vote was and itstransaction ID on the company's blog/twitter, etc., and then emails the URLto the administrator.

Post by alp alp via bitcoin-devThis proposal seems hopelessly broken.Who decides on which companies are eligible? Is there some kind ofcentralized database that one registers? Who administers this? What is tostop 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 personvoting 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-devThere are two ideas here for "on-chain" voting, both of which requirechanges to the software. I agree with David that on-chain solutionscomplicate things. Both proposals can be effected without any softwareThose who wish to use proof of stake can provide a service for makingvanity addresses containing some indicator of the proposal to be supported- 1bigblock or 12mbblk or whatever - based on a supporter-provided secretkey, and then supporters can move their bitcoin into their own vanityaddress and then whoever wants to can create a website to display thematching addresses and explain that this is the financial power in thehands of supporters and how to add your "financial power vote."Those who simply want to "buy votes" can use their funds in marketingefforts to promote the proposal they support.This second method, of course, can be abused. The first actuallyrequires people to control bitcoin in order to represent support. Countingactual, real people is still a technology in its infancy, and I don't thinkI want to see it progress much. People are not units, but individuals, andtheir value only becomes correlated to their net worth after they've beenalive for many years, and even then, some of the best people have diedpaupers. If bitcoin-discuss got more traffic, I think this discussion wouldbe better had on that list.notplatoOn Thu, Feb 2, 2017 at 4:24 PM, Luke Dashjr via bitcoin-dev <

Post by Luke Dashjr via bitcoin-devStrongly disagree with buying "votes", or portraying open standards as avoting process. Also, this depends on address reuse, so it'sfundamentallyflawed in design.Some way for people to express their support weighed by coins (withoutlosing/spending them), and possibly weighed by running a full node, mightstill be desirable. The most straightforward way to do this is to supportmessage signatures somehow (ideally without using the same pubkey asspending), and some [inherently unreliable, but perhaps useful if thecommunity "colludes" to not-cheat] way to sign with ones' full node.Note also that the BIP process already has BIP Comments for leaving textualopinions on the BIP unrelated to stake. See BIP 2 for details on that.Luke

Post by t. khan via bitcoin-devthe Bitcoin protocol. This is especially problematic for controversialchanges such as the max block size limit. As a result, we have manyproposed 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-devfeeling among many in the community that developers arenât listening totheir concerns. This is a valid complaint, as itâs not possible to

listen

Post by t. khan via bitcoin-devto thousands of voices all shouting different things in a crowdedroomâbasically the situation in the Bitcoin community today.The CCVS will allow the general public, miners, companies using

Post by t. khan via bitcoin-devnumber is mined.RationaleConfirmed Vote Multiplier - The purpose of this is twofold; it gives alarger voice to organizations and the people who will have to do the

work

Post by t. khan via bitcoin-devto implement whatever BIP the community prefers, and it will negate theeffect of anyone trying to skew the results by voting repeatedly.DefinitionsMiner: any individual or organization that has mined at least one validblock in the last 2016 blocks.Company using Bitcoin: any organization using Bitcoin for financial,

--I like to provide some work at no charge to prove my value. Do you need atechie?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" - SatoshiNakamoto_______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

These are non-answers. Someone must decide. Someone must decide what kindof 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 thesame as large companies like Coinbase/BitPay/Blockstream). Someone mustdecide which websites are checked for votes or addresses. Someone mustdecide if a rogue employee made a transaction on behalf of the company ornot.

Registering domain names is trivial and can be automated if the incentiveswere needed for it.

You mention developers who have commit access. This excludes the vastmajority 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 proposallike this can be taken seriously. Without these kinds of answers, thisproposal is far from complete.

Preferably no one decides. The company would have to exist prior to thevote, and would need a public-facing website. In the event of contestedvotes (meaning someone finds evidence of a fake company), the admin couldinvestigate and post results.

I don't know. I'm happy to volunteer, if no one else wants to beresponsible for it. The only task would be adding the confirmed votes toeach respective BIP. From there, everything's public and can be confirmedby everyone.

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 thewebsite, all before the vote and in a way that no one would notice.

Someone at the company sends a very small transaction to the BIP's voteaddress. Someone at the company then posts what the vote was and itstransaction ID on the company's blog/twitter, etc., and then emails the URLto the administrator.

Post by alp alp via bitcoin-devThis proposal seems hopelessly broken.Who decides on which companies are eligible? Is there some kind ofcentralized database that one registers? Who administers this? What is tostop 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 personvoting 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-devThere are two ideas here for "on-chain" voting, both of which requirechanges to the software. I agree with David that on-chain solutionscomplicate things. Both proposals can be effected without any softwareThose who wish to use proof of stake can provide a service for makingvanity addresses containing some indicator of the proposal to be supported- 1bigblock or 12mbblk or whatever - based on a supporter-provided secretkey, and then supporters can move their bitcoin into their own vanityaddress and then whoever wants to can create a website to display thematching addresses and explain that this is the financial power in thehands of supporters and how to add your "financial power vote."Those who simply want to "buy votes" can use their funds in marketingefforts to promote the proposal they support.This second method, of course, can be abused. The first actuallyrequires people to control bitcoin in order to represent support. Countingactual, real people is still a technology in its infancy, and I don't thinkI want to see it progress much. People are not units, but individuals, andtheir value only becomes correlated to their net worth after they've beenalive for many years, and even then, some of the best people have diedpaupers. If bitcoin-discuss got more traffic, I think this discussion wouldbe better had on that list.notplatoOn Thu, Feb 2, 2017 at 4:24 PM, Luke Dashjr via bitcoin-dev <

Post by Luke Dashjr via bitcoin-devStrongly disagree with buying "votes", or portraying open standards as avoting process. Also, this depends on address reuse, so it's fundamentallyflawed in design.Some way for people to express their support weighed by coins (withoutlosing/spending them), and possibly weighed by running a full node, mightstill be desirable. The most straightforward way to do this is to supportmessage signatures somehow (ideally without using the same pubkey asspending), and some [inherently unreliable, but perhaps useful if thecommunity "colludes" to not-cheat] way to sign with ones' full node.Note also that the BIP process already has BIP Comments for leaving textualopinions on the BIP unrelated to stake. See BIP 2 for details on that.Luke

Post by t. khan via bitcoin-devthe Bitcoin protocol. This is especially problematic for controversialchanges such as the max block size limit. As a result, we have manyproposed solutions but no clear direction.Also, due to our lack of ability to measure consensus, there is a

Post by t. khan via bitcoin-devto thousands of voices all shouting different things in a crowdedroomâbasically the situation in the Bitcoin community today.The CCVS will allow the general public, miners, companies using

--I like to provide some work at no charge to prove my value. Do you needa 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" - SatoshiNakamoto_______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Post by alp alp via bitcoin-devThese are non-answers. Someone must decide. Someone must decide whatkind of company counts (e.g. does a dark market seller count as abusiness? Does some guy who sells $10/year worth of goods using Bitcoincount 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 thecompany or not.

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

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

Mountains out of mole hills hereâif the domain name is registered aftervoting is called, that would be a pretty clear indicator it's a fakecompany.

Post by alp alp via bitcoin-devYou mention developers who have commit access. This excludes the vastmajority 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 whatthe community will support, developers won't have a confirmed vote. Theywould get a standard vote though, just like everyone else.

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

Preferably no one decides. The company would have to exist prior to thevote, and would need a public-facing website. In the event of contestedvotes (meaning someone finds evidence of a fake company), the admin couldinvestigate and post results.

I don't know. I'm happy to volunteer, if no one else wants to beresponsible for it. The only task would be adding the confirmed votes toeach respective BIP. From there, everything's public and can be confirmedby everyone.

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 thewebsite, all before the vote and in a way that no one would notice.

Someone at the company sends a very small transaction to the BIP's voteaddress. Someone at the company then posts what the vote was and itstransaction ID on the company's blog/twitter, etc., and then emails the URLto the administrator.

Post by alp alp via bitcoin-devThis proposal seems hopelessly broken.Who decides on which companies are eligible? Is there some kind ofcentralized database that one registers? Who administers this? What is tostop 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 personvoting 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-devThere are two ideas here for "on-chain" voting, both of which requirechanges to the software. I agree with David that on-chain solutionscomplicate things. Both proposals can be effected without any softwareThose who wish to use proof of stake can provide a service for makingvanity addresses containing some indicator of the proposal to be supported- 1bigblock or 12mbblk or whatever - based on a supporter-provided secretkey, and then supporters can move their bitcoin into their own vanityaddress and then whoever wants to can create a website to display thematching addresses and explain that this is the financial power in thehands of supporters and how to add your "financial power vote."Those who simply want to "buy votes" can use their funds in marketingefforts to promote the proposal they support.This second method, of course, can be abused. The first actuallyrequires people to control bitcoin in order to represent support.Countingactual, real people is still a technology in its infancy, and I don't thinkI want to see it progress much. People are not units, but individuals, andtheir value only becomes correlated to their net worth after they've beenalive for many years, and even then, some of the best people have diedpaupers. If bitcoin-discuss got more traffic, I think this discussion wouldbe better had on that list.notplatoOn Thu, Feb 2, 2017 at 4:24 PM, Luke Dashjr via bitcoin-dev <

Post by Luke Dashjr via bitcoin-devStrongly disagree with buying "votes", or portraying open standards as avoting process. Also, this depends on address reuse, so it's fundamentallyflawed in design.Some way for people to express their support weighed by coins (withoutlosing/spending them), and possibly weighed by running a full node, mightstill be desirable. The most straightforward way to do this is to supportmessage signatures somehow (ideally without using the same pubkey asspending), and some [inherently unreliable, but perhaps useful if thecommunity "colludes" to not-cheat] way to sign with ones' full node.Note also that the BIP process already has BIP Comments for leaving textualopinions on the BIP unrelated to stake. See BIP 2 for details on that.Luke

Post by t. khan via bitcoin-devthe Bitcoin protocol. This is especially problematic forcontroversialchanges such as the max block size limit. As a result, we have manyproposed 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-devfeeling among many in the community that developers aren’t listening totheir concerns. This is a valid complaint, as it’s not possible to

listen

Post by t. khan via bitcoin-devto thousands of voices all shouting different things in a crowdedroom—basically the situation in the Bitcoin community today.The CCVS will allow the general public, miners, companies using

Post by t. khan via bitcoin-devnumber is mined.RationaleConfirmed Vote Multiplier - The purpose of this is twofold; it gives alarger voice to organizations and the people who will have to do the

work

Post by t. khan via bitcoin-devto implement whatever BIP the community prefers, and it will negate theeffect of anyone trying to skew the results by voting repeatedly.DefinitionsMiner: any individual or organization that has mined at least one validblock in the last 2016 blocks.Company using Bitcoin: any organization using Bitcoin for financial,

--I like to provide some work at no charge to prove my value. Do you need atechie?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" - SatoshiNakamoto_______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Post by Chris Priest via bitcoin-devPersonally I think once the blocksize arguments are solved, there willbe no more contentious changes for this voting system to deal with.What other contentious issues have come up in the past 3 years or sothat wasn't blocksize/scaling related? Do other protocols like TCP/IPand the HTTP protocol have developers arguing every day over issues noone can agree on?

Post by Chris Priest via bitcoin-devPersonally I think once the blocksize arguments are solved, there willbe no more contentious changes for this voting system to deal with.What other contentious issues have come up in the past 3 years or sothat wasn't blocksize/scaling related? Do other protocols like TCP/IPand the HTTP protocol have developers arguing every day over issues noone can agree on?

Yes, DRM for example.

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

Post by Luke Dashjr via bitcoin-devStrongly disagree with buying "votes", or portraying open standards as avoting process. Also, this depends on address reuse, so it's fundamentallyflawed in design.

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

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

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

Note also that the BIP process already has BIP Comments for leaving textual