summaryrefslogtreecommitdiff
path: root/36/681e5f1fd9cf98e5d11d437cbde06654926fd7
blob: e0ae5cd6e4c3fd9c179d60d0ac85e03bb377bdaa (plain)
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
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
Return-Path: <dscotese@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 193FB2C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  3 Feb 2017 01:32:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f172.google.com (mail-qt0-f172.google.com
	[209.85.216.172])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A787C187
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  3 Feb 2017 01:32:35 +0000 (UTC)
Received: by mail-qt0-f172.google.com with SMTP id v23so11092144qtb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 02 Feb 2017 17:32:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:sender:in-reply-to:references:from:date:message-id
	:subject:to:cc;
	bh=hDbcCNkKpia766+H6IoCeRc6DMlHOywzxbG9DuxP7PE=;
	b=Wt4teqMRd63oAXHogVPdKoJChIXLBUwlcqnU/9QKUP6y2/oHcDdse6/V7af2yj0+Fr
	RQzxjE3nNMfw2oinPEJReCTyvaiZwDU0QkmB9Aj6Wjkjyw2+3ttcEaGHOt4DIxaI0DaX
	hAznQy8s5C7hu4TIsULdKhdKEwjuwU7Vk61rTEuQ+alluh1DwfpIkpIep/z3jEoYPQTU
	ynRTSJ1NcbHYnILkeOmIjnea3EdSBK90JrL9fjhlR40I9mpgFHVuyKLzoQHOKI4RRPk6
	YMyhSrOMidjp5xVFNxqbF9ePyFht/Tt3fIJrEtCOyPoTn183Fp/4risvX6hO5SZKmK9m
	jwhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
	:date:message-id:subject:to:cc;
	bh=hDbcCNkKpia766+H6IoCeRc6DMlHOywzxbG9DuxP7PE=;
	b=AxpYiEeph/LKeaq6OIX+3b9H9Sbf8PR/4DIBBwEuCGjTMg+OBKuQqZ4S/5ly6WHVni
	Qu8XiuhALgsOd9xg0noty+a2bHfD2kXIErwHWj4NmuYDfXkDloyrGmra1tlwyJADiR5/
	HOoB3CUQ0yLhknsMBTozs41WGHY7QWIXz+z6cjBWvIrwLAJJX4RAe9N9rqD1PEFKTWw6
	1r/Kwv345NglTRpjR8ay8+SsHcuMVD1DhVdBv8Mzi5bM26Lbsn38zGKL24zcNeVbgD0U
	G5vZchx0pzlkScjwsU/PwRN2C1IJMRvbjTvKXb/uheQ3pI1Ht1UItzF9vvGFWXjjT2mc
	g4nA==
X-Gm-Message-State: AIkVDXKjNNh5/jXVL/ulto2x7hMRPlyQX/aHjIHJFjozEAUJAQ+nJ/3HbQy9IvvqS0OrzdiTRwYbeMbmEcxaHw==
X-Received: by 10.200.38.196 with SMTP id 4mr10663852qtp.96.1486085554783;
	Thu, 02 Feb 2017 17:32:34 -0800 (PST)
MIME-Version: 1.0
Sender: dscotese@gmail.com
Received: by 10.140.43.5 with HTTP; Thu, 2 Feb 2017 17:32:34 -0800 (PST)
In-Reply-To: <201702030024.10232.luke@dashjr.org>
References: <CAGCNRJqNg9-aYG62OxTz5RJyx+JJkx-kt2odooZWs92f5teZiw@mail.gmail.com>
	<201702030024.10232.luke@dashjr.org>
From: Dave Scotese <dscotese@litmocracy.com>
Date: Thu, 2 Feb 2017 17:32:34 -0800
X-Google-Sender-Auth: bQOZdOKByb5QQW6gyNKQbT62ICI
Message-ID: <CAGLBAhdzPOC6MppMyuL6SwnoY_D829ZRs78pTF47k3rnHPjE1A@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a113f4790994d3205479641a2
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_LOW,
	RCVD_IN_SORBS_SPAM 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 01:32:37 -0000

--001a113f4790994d3205479641a2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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

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

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

This second method, of course, can be abused.  The first actually requires
people to control bitcoin in order to represent support.  Counting actual,
real people is still a technology in its infancy, and I don't think I want
to see it progress much. People are not units, but individuals, and their
value only becomes correlated to their net worth after they've been alive
for many years, and even then, some of the best people have died paupers.
If bitcoin-discuss got more traffic, I think this discussion would be
better had on that list.

notplato

On Thu, Feb 2, 2017 at 4:24 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Strongly disagree with buying "votes", or portraying open standards as a
> voting process. Also, this depends on address reuse, so it's fundamentall=
y
> 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 textu=
al
> opinions on the BIP unrelated to stake. See BIP 2 for details on that.
>
> Luke
>
>
> On Thursday, February 02, 2017 7:39:51 PM t. khan via bitcoin-dev wrote:
> > Please comment on this work-in-progress BIP.
> >
> > Thanks,
> >
> > - t.k.
> >
> > ----------------------
> > BIP: ?
> > Layer: Process
> > Title: Community Consensus Voting System
> > Author: t.khan <teekhan42@gmail.com>
> > Comments-Summary: No comments yet.
> > Comments-URI: TBD
> > Status: Draft
> > Type: Standards Track
> > Created: 2017-02-02
> > License: BSD-2
> > Voting Address: 3CoFA3JiK5wxe9ze2HoDGDTmZvkE5Uuwh8  (just an example,
> don=E2=80=99t
> > send to this!)
> >
> > Abstract
> > Community Consensus Voting System (CCVS) will allow developers to measu=
re
> > support for BIPs prior to implementation.
> >
> > Motivation
> > We currently have no way of measuring consensus for potential changes t=
o
> > 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 gener=
al
> > feeling among many in the community that developers aren=E2=80=99t list=
ening to
> > their concerns. This is a valid complaint, as it=E2=80=99s not possible=
 to listen
> > to thousands of voices all shouting different things in a crowded
> > room=E2=80=94basically 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=E2=80=99s =
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/contributor=
s
> > 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 publicl=
y
> > (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,00=
0
> > 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 blo=
ck
> > 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 wo=
rk
> > 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 a=
s
> > this would require code changes, it is outside the scope of this BIP.
> >
> > Copyright
> > This BIP is licensed under the BSD 2-clause license.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>



--=20
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

--001a113f4790994d3205479641a2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>There are two ideas here for &quot;on-chain=
&quot; voting, both of which require changes to the software.=C2=A0 I agree=
 with David that on-chain solutions complicate things.=C2=A0 Both proposals=
 can be effected without any software changes:<br><br>Those who wish to use=
 proof of stake can provide a service for making vanity addresses containin=
g some indicator of the proposal to be supported - 1bigblock or 12mbblk or =
whatever - based on a supporter-provided secret key, and then supporters ca=
n move their bitcoin into their own vanity address and then whoever wants t=
o can create a website to display the matching addresses and explain that t=
his is the financial power in the hands of supporters and how to add your &=
quot;financial power vote.&quot;<br><br></div>Those who simply want to &quo=
t;buy votes&quot; can use their funds in marketing efforts to promote the p=
roposal they support.<br><br></div>This second method, of course, can be ab=
used.=C2=A0 The first actually requires people to control bitcoin in order =
to represent support.=C2=A0 Counting actual, real people is still a technol=
ogy in its infancy, and I don&#39;t think I want to see it progress much. P=
eople are not units, but individuals, and their value only becomes correlat=
ed to their net worth after they&#39;ve been alive for many years, and even=
 then, some of the best people have died paupers. If bitcoin-discuss got mo=
re traffic, I think this discussion would be better had on that list.<br><b=
r></div>notplato<br></div><div class=3D"gmail_extra"><br><div class=3D"gmai=
l_quote">On Thu, Feb 2, 2017 at 4:24 PM, Luke Dashjr via bitcoin-dev <span =
dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" ta=
rget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">Strongly disagree with buying &quot;vote=
s&quot;, or portraying open standards as a<br>
voting process. Also, this depends on address reuse, so it&#39;s fundamenta=
lly<br>
flawed in design.<br>
<br>
Some way for people to express their support weighed by coins (without<br>
losing/spending them), and possibly weighed by running a full node, might<b=
r>
still be desirable. The most straightforward way to do this is to support<b=
r>
message signatures somehow (ideally without using the same pubkey as<br>
spending), and some [inherently unreliable, but perhaps useful if the<br>
community &quot;colludes&quot; to not-cheat] way to sign with ones&#39; ful=
l node.<br>
<br>
Note also that the BIP process already has BIP Comments for leaving textual=
<br>
opinions on the BIP unrelated to stake. See BIP 2 for details on that.<br>
<br>
Luke<br>
<div><div class=3D"h5"><br>
<br>
On Thursday, February 02, 2017 7:39:51 PM t. khan via bitcoin-dev wrote:<br=
>
&gt; Please comment on this work-in-progress BIP.<br>
&gt;<br>
&gt; Thanks,<br>
&gt;<br>
&gt; - t.k.<br>
&gt;<br>
&gt; ----------------------<br>
&gt; BIP: ?<br>
&gt; Layer: Process<br>
&gt; Title: Community Consensus Voting System<br>
&gt; Author: t.khan &lt;<a href=3D"mailto:teekhan42@gmail.com">teekhan42@gm=
ail.com</a>&gt;<br>
&gt; Comments-Summary: No comments yet.<br>
&gt; Comments-URI: TBD<br>
&gt; Status: Draft<br>
&gt; Type: Standards Track<br>
&gt; Created: 2017-02-02<br>
&gt; License: BSD-2<br>
&gt; Voting Address: 3CoFA3JiK5wxe9ze2HoDGDTmZvkE5U<wbr>uwh8=C2=A0 (just an=
 example, don=E2=80=99t<br>
&gt; send to this!)<br>
&gt;<br>
&gt; Abstract<br>
&gt; Community Consensus Voting System (CCVS) will allow developers to meas=
ure<br>
&gt; support for BIPs prior to implementation.<br>
&gt;<br>
&gt; Motivation<br>
&gt; We currently have no way of measuring consensus for potential changes =
to<br>
&gt; the Bitcoin protocol. This is especially problematic for controversial=
<br>
&gt; changes such as the max block size limit. As a result, we have many<br=
>
&gt; proposed solutions but no clear direction.<br>
&gt;<br>
&gt; Also, due to our lack of ability to measure consensus, there is a gene=
ral<br>
&gt; feeling among many in the community that developers aren=E2=80=99t lis=
tening to<br>
&gt; their concerns. This is a valid complaint, as it=E2=80=99s not possibl=
e to listen<br>
&gt; to thousands of voices all shouting different things in a crowded<br>
&gt; room=E2=80=94basically the situation in the Bitcoin community today.<b=
r>
&gt;<br>
&gt; The CCVS will allow the general public, miners, companies using Bitcoi=
n,<br>
&gt; and developers to vote for their preferred BIP in a way that=E2=80=99s=
 public and<br>
&gt; relatively difficult (expensive) to manipulate.<br>
&gt;<br>
&gt; Specification<br>
&gt; Each competing BIP will be assigned a unique bitcoin address which is =
added<br>
&gt; to each header. Anyone who wanted to vote would cast their ballot by<b=
r>
&gt; sending a small amount (0.0001 btc) to their preferred BIP&#39;s addre=
ss. Each<br>
&gt; transaction counts as 1 vote.<br>
&gt;<br>
&gt; Confirmed Vote Multiplier:<br>
&gt; Mining Pools, companies using Bitcoin, and Core maintainers/contributo=
rs<br>
&gt; are allowed one confirmed vote each. A confirmed vote is worth 10,000x=
 a<br>
&gt; regular vote.<br>
&gt;<br>
&gt; For example:<br>
&gt;<br>
&gt; Slush Pool casts a vote for their preferred BIP and then states public=
ly<br>
&gt; (on their blog) their vote and the transaction ID and emails the URL t=
o the<br>
&gt; admin of this system. In the final tally, this vote will count as 10,0=
00<br>
&gt; votes.<br>
&gt;<br>
&gt; Coinbase, Antpool, BitPay, BitFury, etc., all do the same.<br>
&gt;<br>
&gt; Confirmed votes would be added to a new section in each respective BIP=
 as a<br>
&gt; public record.<br>
&gt;<br>
&gt; Voting would run for a pre-defined period, ending when a particular bl=
ock<br>
&gt; number is mined.<br>
&gt;<br>
&gt;<br>
&gt; Rationale<br>
&gt; Confirmed Vote Multiplier - The purpose of this is twofold; it gives a=
<br>
&gt; larger voice to organizations and the people who will have to do the w=
ork<br>
&gt; to implement whatever BIP the community prefers, and it will negate th=
e<br>
&gt; effect of anyone trying to skew the results by voting repeatedly.<br>
&gt;<br>
&gt; Definitions<br>
&gt; Miner: any individual or organization that has mined at least one vali=
d<br>
&gt; block in the last 2016 blocks.<br>
&gt;<br>
&gt; Company using Bitcoin: any organization using Bitcoin for financial, a=
sset<br>
&gt; or other purposes, with either under development and released solution=
s.<br>
&gt;<br>
&gt; Developer: any individual who has or had commit access, and any indivi=
dual<br>
&gt; who has authored a BIP<br>
&gt;<br>
&gt; Unresolved Issues<br>
&gt; Node voting: It would be desirable for any full node running an up-to-=
date<br>
&gt; blockchain to also be able to vote with a multiplier (e.g. 100x). But =
as<br>
&gt; this would require code changes, it is outside the scope of this BIP.<=
br>
&gt;<br>
&gt; Copyright<br>
&gt; This BIP is licensed under the BSD 2-clause license.<br>
</div></div>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">I like to provi=
de some work at no charge to prove my value. Do you need a techie?=C2=A0 <b=
r>I own <a href=3D"http://www.litmocracy.com" target=3D"_blank">Litmocracy<=
/a> and <a href=3D"http://www.memeracing.net" target=3D"_blank">Meme Racing=
</a> (in alpha). <br>I&#39;m the webmaster for <a href=3D"http://www.volunt=
aryist.com" target=3D"_blank">The Voluntaryist</a> which now accepts Bitcoi=
n.<br>I also code for <a href=3D"http://dollarvigilante.com/" target=3D"_bl=
ank">The Dollar Vigilante</a>.<br>&quot;He ought to find it more profitable=
 to play by the rules&quot; - Satoshi Nakamoto</div></div>
</div>

--001a113f4790994d3205479641a2--