1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
|
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C588340C
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 3 Feb 2017 00:24:35 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 2632C1CE
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 3 Feb 2017 00:24:35 +0000 (UTC)
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:a45d:823b:2d27:961c])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 4270F38A179B;
Fri, 3 Feb 2017 00:24:11 +0000 (UTC)
X-Hashcash: 1:25:170203:bitcoin-dev@lists.linuxfoundation.org::kUhwb9BJ5GYs7Z1l:y9Zj
X-Hashcash: 1:25:170203:teekhan42@gmail.com::U4gzlnCtnfaIL6an:cxCZU
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
"t. khan" <teekhan42@gmail.com>
Date: Fri, 3 Feb 2017 00:24:09 +0000
User-Agent: KMail/1.13.7 (Linux/4.4.45-gentoo; KDE/4.14.24; x86_64; ; )
References: <CAGCNRJqNg9-aYG62OxTz5RJyx+JJkx-kt2odooZWs92f5teZiw@mail.gmail.com>
In-Reply-To: <CAGCNRJqNg9-aYG62OxTz5RJyx+JJkx-kt2odooZWs92f5teZiw@mail.gmail.com>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201702030024.10232.luke@dashjr.org>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] [Pre-BIP] Community Consensus Voting System
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Feb 2017 00:24:35 -0000
Strongly disagree with buying "votes", or portraying open standards as a=20
voting process. Also, this depends on address reuse, so it's fundamentally=
=20
flawed in design.
Some way for people to express their support weighed by coins (without=20
losing/spending them), and possibly weighed by running a full node, might=20
still be desirable. The most straightforward way to do this is to support=20
message signatures somehow (ideally without using the same pubkey as=20
spending), and some [inherently unreliable, but perhaps useful if the=20
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=
=20
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.
>=20
> Thanks,
>=20
> - t.k.
>=20
> ----------------------
> BIP: ?
> Layer: Process
> Title: Community Consensus Voting System
> Author: t.khan <teekhan42@gmail.com>
> Comments-Summary: No comments yet.
> Comments-URI: TBD
> Status: Draft
> Type: Standards Track
> Created: 2017-02-02
> License: BSD-2
> Voting Address: 3CoFA3JiK5wxe9ze2HoDGDTmZvkE5Uuwh8 (just an example, don=
=E2=80=99t
> send to this!)
>=20
> Abstract
> Community Consensus Voting System (CCVS) will allow developers to measure
> support for BIPs prior to implementation.
>=20
> 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.
>=20
> Also, due to our lack of ability to measure consensus, there is a general
> feeling among many in the community that developers aren=E2=80=99t listen=
ing to
> their concerns. This is a valid complaint, as it=E2=80=99s not possible t=
o listen
> to thousands of voices all shouting different things in a crowded
> room=E2=80=94basically the situation in the Bitcoin community today.
>=20
> The CCVS will allow the general public, miners, companies using Bitcoin,
> and developers to vote for their preferred BIP in a way that=E2=80=99s pu=
blic and
> relatively difficult (expensive) to manipulate.
>=20
> Specification
> Each competing BIP will be assigned a unique bitcoin address which is add=
ed
> 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.
>=20
> 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.
>=20
> For example:
>=20
> 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 t=
he
> admin of this system. In the final tally, this vote will count as 10,000
> votes.
>=20
> Coinbase, Antpool, BitPay, BitFury, etc., all do the same.
>=20
> Confirmed votes would be added to a new section in each respective BIP as=
a
> public record.
>=20
> Voting would run for a pre-defined period, ending when a particular block
> number is mined.
>=20
>=20
> 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.
>=20
> Definitions
> Miner: any individual or organization that has mined at least one valid
> block in the last 2016 blocks.
>=20
> Company using Bitcoin: any organization using Bitcoin for financial, asset
> or other purposes, with either under development and released solutions.
>=20
> Developer: any individual who has or had commit access, and any individual
> who has authored a BIP
>=20
> 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.
>=20
> Copyright
> This BIP is licensed under the BSD 2-clause license.
|
