đź“… Original date posted:2017-02-02
đź“ť Original message: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 at 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.
Luke Dashjr [ARCHIVE] /
npub1tf…rfq0n
2023-06-07 17:55:54
in reply to nevent1q…mtj7
Author Public Key
npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0nPublished at
2023-06-07 17:55:54Event JSON
{
"id": "d05ee3422b06a85f2de3405e3f04df4ab088a0a4739ee6d668cf9982084bcfb1",
"pubkey": "5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803",
"created_at": 1686160554,
"kind": 1,
"tags": [
[
"e",
"d447d44a3cade4696209fafd675287737f41909f4c6d131472bfe3b93fdade69",
"",
"root"
],
[
"e",
"6042b7a9bde6f38069ab8ecd3016d6451eb393ce41057b44499164535d8dd620",
"",
"reply"
],
[
"p",
"adcb53cdbd72e2a0c22452a9087f173c6b55edc7b504ff9b861e9c02af9a87d4"
]
],
"content": "📅 Original date posted:2017-02-02\n📝 Original message:Strongly disagree with buying \"votes\", or portraying open standards as a \nvoting process. Also, this depends on address reuse, so it's fundamentally \nflawed in design.\n\nSome way for people to express their support weighed by coins (without \nlosing/spending them), and possibly weighed by running a full node, might \nstill be desirable. The most straightforward way to do this is to support \nmessage signatures somehow (ideally without using the same pubkey as \nspending), and some [inherently unreliable, but perhaps useful if the \ncommunity \"colludes\" to not-cheat] way to sign with ones' full node.\n\nNote also that the BIP process already has BIP Comments for leaving textual \nopinions on the BIP unrelated to stake. See BIP 2 for details on that.\n\nLuke\n\n\nOn Thursday, February 02, 2017 7:39:51 PM t. khan via bitcoin-dev wrote:\n\u003e Please comment on this work-in-progress BIP.\n\u003e \n\u003e Thanks,\n\u003e \n\u003e - t.k.\n\u003e \n\u003e ----------------------\n\u003e BIP: ?\n\u003e Layer: Process\n\u003e Title: Community Consensus Voting System\n\u003e Author: t.khan \u003cteekhan42 at gmail.com\u003e\n\u003e Comments-Summary: No comments yet.\n\u003e Comments-URI: TBD\n\u003e Status: Draft\n\u003e Type: Standards Track\n\u003e Created: 2017-02-02\n\u003e License: BSD-2\n\u003e Voting Address: 3CoFA3JiK5wxe9ze2HoDGDTmZvkE5Uuwh8 (just an example, don’t\n\u003e send to this!)\n\u003e \n\u003e Abstract\n\u003e Community Consensus Voting System (CCVS) will allow developers to measure\n\u003e support for BIPs prior to implementation.\n\u003e \n\u003e Motivation\n\u003e We currently have no way of measuring consensus for potential changes to\n\u003e the Bitcoin protocol. This is especially problematic for controversial\n\u003e changes such as the max block size limit. As a result, we have many\n\u003e proposed solutions but no clear direction.\n\u003e \n\u003e Also, due to our lack of ability to measure consensus, there is a general\n\u003e feeling among many in the community that developers aren’t listening to\n\u003e their concerns. This is a valid complaint, as it’s not possible to listen\n\u003e to thousands of voices all shouting different things in a crowded\n\u003e room—basically the situation in the Bitcoin community today.\n\u003e \n\u003e The CCVS will allow the general public, miners, companies using Bitcoin,\n\u003e and developers to vote for their preferred BIP in a way that’s public and\n\u003e relatively difficult (expensive) to manipulate.\n\u003e \n\u003e Specification\n\u003e Each competing BIP will be assigned a unique bitcoin address which is added\n\u003e to each header. Anyone who wanted to vote would cast their ballot by\n\u003e sending a small amount (0.0001 btc) to their preferred BIP's address. Each\n\u003e transaction counts as 1 vote.\n\u003e \n\u003e Confirmed Vote Multiplier:\n\u003e Mining Pools, companies using Bitcoin, and Core maintainers/contributors\n\u003e are allowed one confirmed vote each. A confirmed vote is worth 10,000x a\n\u003e regular vote.\n\u003e \n\u003e For example:\n\u003e \n\u003e Slush Pool casts a vote for their preferred BIP and then states publicly\n\u003e (on their blog) their vote and the transaction ID and emails the URL to the\n\u003e admin of this system. In the final tally, this vote will count as 10,000\n\u003e votes.\n\u003e \n\u003e Coinbase, Antpool, BitPay, BitFury, etc., all do the same.\n\u003e \n\u003e Confirmed votes would be added to a new section in each respective BIP as a\n\u003e public record.\n\u003e \n\u003e Voting would run for a pre-defined period, ending when a particular block\n\u003e number is mined.\n\u003e \n\u003e \n\u003e Rationale\n\u003e Confirmed Vote Multiplier - The purpose of this is twofold; it gives a\n\u003e larger voice to organizations and the people who will have to do the work\n\u003e to implement whatever BIP the community prefers, and it will negate the\n\u003e effect of anyone trying to skew the results by voting repeatedly.\n\u003e \n\u003e Definitions\n\u003e Miner: any individual or organization that has mined at least one valid\n\u003e block in the last 2016 blocks.\n\u003e \n\u003e Company using Bitcoin: any organization using Bitcoin for financial, asset\n\u003e or other purposes, with either under development and released solutions.\n\u003e \n\u003e Developer: any individual who has or had commit access, and any individual\n\u003e who has authored a BIP\n\u003e \n\u003e Unresolved Issues\n\u003e Node voting: It would be desirable for any full node running an up-to-date\n\u003e blockchain to also be able to vote with a multiplier (e.g. 100x). But as\n\u003e this would require code changes, it is outside the scope of this BIP.\n\u003e \n\u003e Copyright\n\u003e This BIP is licensed under the BSD 2-clause license.",
"sig": "f3bdc1c658cbb9ab1210e56fe2a66aafc7dd755a6128559221ca091d11f553f21288a96baff27dcf0c766616c901405f9264f176f110e8ecc1c3a2180c130be1"
}