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
|
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 B52EF8EC
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Aug 2015 23:26:50 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com
[209.85.212.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EC636A6
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Aug 2015 23:26:48 +0000 (UTC)
Received: by wicgj17 with SMTP id gj17so41040285wic.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 06 Aug 2015 16:26:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:date:message-id:subject
:from:to:content-type;
bh=cP3E8fT9/J0oZ1518/4xnXHwVWOTqloQG6tIEMHWDG4=;
b=L+yg2Pa6uJJuih3EhgZgpPZUu7emyOGiO8H2G7x42rPVpZYfuuDtSOow0nhs0ZHJ8m
xQ2muEBGBIhzKGOpt8Q73YuqpD6FpTFdT/2UT24VO9mHi9zjKcfV2xnsfQfwOHs49Dk5
xJ9nUyyktd6MdHdLXZ7mS7s75OjG66H+whyHD3pAQTLHfpkXEDe9tr+wPVixgwyO+sHr
jyH/jk6DoB0FtwgD+wjcBD2Jr1DwGIrNXgBnp8FjCeMBk0SFZSeN4NYPGBZNJWVaQRGM
7HLHyeRy6fSFj7AMAu6ynfFMxTPxJwyHJtEKk/aqtaRwoY6YDXEX0EfOzWlT584w+uFl
Dy6A==
MIME-Version: 1.0
X-Received: by 10.194.239.167 with SMTP id vt7mr8869463wjc.5.1438903607595;
Thu, 06 Aug 2015 16:26:47 -0700 (PDT)
Sender: dscotese@gmail.com
Received: by 10.27.184.134 with HTTP; Thu, 6 Aug 2015 16:26:47 -0700 (PDT)
In-Reply-To: <1c808715eac12f67cf9865dfd97c0a37@xbt.hk>
References: <1c808715eac12f67cf9865dfd97c0a37@xbt.hk>
Date: Thu, 6 Aug 2015 16:26:47 -0700
X-Google-Sender-Auth: abWuBeOEkJo9IKJnMpUhA7g4hsU
Message-ID: <CAGLBAhf34uqzxprY37QnfhDpP4FddfRKGnTeHe+o5Zh-rguD-Q@mail.gmail.com>
From: Dave Scotese <dscotese@litmocracy.com>
To: "jl2012@xbt.hk" <jl2012@xbt.hk>, bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=089e013c60c0659639051cacda17
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham
version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [bitcoin-dev] Wrapping up the block size debate with voting
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Thu, 06 Aug 2015 23:26:50 -0000
--089e013c60c0659639051cacda17
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
"Miners can do this unilaterally" maybe, if they are a closed group, based
on the 51% rule. But aren't they using full nodes for propagation? In this
sense, anyone can vote by coding.
If and when we need to vote, a pair-wise runoff ("condorcet method") will
find an option that is championed by a majority over each other option.
There may not be any such option, in which case no change would make the
most sense.
The voting proposal has several appeals to authority (which no one has)
like "People with certain amount of contribution" and "Exchanges operated
for at least 1 year with 100,000BTC 30-day volume may also apply": who
decided what amount or whether or not the application is approved? It also
doesn't specify how many btc equates to one vote.
> On Aug 4, 2015, at 12:50 AM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org <javascript:;>> wrote:
>
> As now we have some concrete proposals (
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.ht=
ml),
I think we should wrap up the endless debate with voting by different
stakeholder groups.
>
> ---------------------------------
> Candidate proposals
>
> Candidate proposals must be complete BIPs with reference implementation
which are ready to merge immediately. They must first go through the usual
peer review process and get approved by the developers in a technical
standpoint, without political or philosophical considerations. Any fine
tune of a candidate proposal may not become an independent candidate,
unless it introduces some =E2=80=9Creal=E2=80=9D difference. =E2=80=9CNo ch=
ange=E2=80=9D is also one of the
voting options.
> ---------------------------------
> Voter groups
>
> There will be several voter groups and their votes will be counted
independently. (The time frames mentioned below are just for example.)
>
> Miners: miners of blocks with timestamp between 1 to 30 Sept 2015 are
eligible to vote. One block one vote. Miners will cast their votes by
signing with the bitcoin address in coinbase. If there are multiple
coinbase outputs, the vote is discounted by output value / total coinbase
output value.
> Many well-known pools are reusing addresses and they may not need to
digitally sign their votes. In case there is any dispute, the digitally
signed vote will be counted.
>
> Bitcoin holders: People with bitcoin in the UTXO at block 372500 (around
early September) are eligible to vote. The total =E2=80=9Cbalance=E2=80=9D =
of each
scriptPubKey is calculated and this is the weight of the vote. People will
cast their votes by digital signature.
> Special output types:
> Multi-sig: vote must be signed according to the setting of the multi-sig.
> P2SH: the serialized script must be provided
> Publicly known private key: not eligible to vote
> Non-standard script according to latest Bitcoin Core rules: not eligible
to vote in general. May be judged case-by-case
>
> Developers: People with certain amount of contribution in the past year
in Bitcoin Core or other open sources wallet / alternative implementations.
One person one vote.
>
> Exchanges: Centralized exchanges listed on Coindesk Bitcoin Index,
Winkdex, or NYSE Bitcoin index, with 30 days volume >100,000BTC are
invited. This includes Bitfinex, BTC China, BitStamp, BTC-E, itBit, OKCoin,
Huobi, Coinbase. Exchanges operated for at least 1 year with 100,000BTC
30-day volume may also apply to be a voter in this category. One exchange
one vote.
>
> Merchants and service providers: This category includes all bitcoin
accepting business that is not centralized fiat-currency exchange, e.g.
virtual or physical stores, gambling sites, online wallet service, payment
processors like Bitpay, decentralized exchange like Localbitcoin, ETF
operators like Secondmarket Bitcoin Investment Trust. They must directly
process bitcoin without relying on third party. They should process at
least 100BTC in the last 30-days. One merchant one vote.
>
> Full nodes operators: People operating full nodes for at least 168 hours
(1 week) in July 2015 are eligible to vote, determined by the log of
Bitnodes. Time is set in the past to avoid manipulation. One IP address one
vote. Vote must be sent from the node=E2=80=99s IP address.
>
> --------------------
> Voting system
>
> Single transferable vote is applied. (
https://en.wikipedia.org/wiki/Single_transferable_vote). Voters are
required to rank their preference with =E2=80=9C1=E2=80=9D, =E2=80=9C2=E2=
=80=9D, =E2=80=9C3=E2=80=9D, etc, or use =E2=80=9CN=E2=80=9D to
indicate rejection of a candidate.
> Vote counting starts with every voter=E2=80=99s first choice. The candida=
te with
fewest votes is eliminated and those votes are transferred according to
their second choice. This process repeats until only one candidate is left,
which is the most popular candidate. The result is presented as the
approval rate: final votes for the most popular candidate / all valid votes
>
> After the most popular candidate is determined, the whole counting
process is repeated by eliminating this candidate, which will find the
approval rate for the second most popular candidate. The process repeats
until all proposals are ranked with the approval rate calculated.
>
> --------------------
> Interpretation of results:
>
> It is possible that a candidate with lower ranking to have higher
approval rate. However, ranking is more important than the approval rate,
unless the difference in approval rate is really huge. 90% support would be
excellent; 70% is good; 50% is marginal; <50% is failed.
>
> --------------------
> Technical issues:
>
> Voting by the miners, developers, exchanges, and merchants are probably
the easiest. We need a trusted person to verify the voters=E2=80=99 identit=
y by
email, website, or digital signature. The trusted person will collect votes
and publish the named votes so anyone could verify the results.
>
> For full nodes, we need a trusted person to setup a website as an
interface to vote. The votes with IP address will be published.
>
> For bitcoin holders, the workload could be very high and we may need some
automatic system to collect and count the votes. If people are worrying
about reduced security due to exposed raw public key, they should move
their bitcoin to a new address before voting.
>
> Double voting: people are generally not allowed to change their mind
after voting, especially for anonymous voters like bitcoin holders and solo
miners. A double voting attempt from these classes will invalidate all
related votes.
>
> Multiple identity: People may have multiple roles in the Bitcoin ecology.
I believe they should be allowed to vote in all applicable categories since
they are contributing more than other people.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org <javascript:;>
> 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
--089e013c60c0659639051cacda17
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
"Miners can do this unilaterally" maybe, if they are a closed gro=
up, based on the 51% rule. But aren't they using full nodes for propaga=
tion?=C2=A0 In this sense, anyone can vote by coding.<br>
<br>
If and when we need to vote, a pair-wise runoff ("condorcet method&quo=
t;) will find an option that is championed by a majority over each other op=
tion. There may not be any such option, in which case no change would make =
the most sense.<br>
<br>
The voting proposal has several appeals to authority (which no one has) lik=
e "People with certain amount of contribution" and "Exchange=
s operated for at least 1 year with 100,000BTC 30-day volume may also apply=
": who decided what amount or whether or not the application is approv=
ed?=C2=A0 It also doesn't specify how many btc equates to one vote.<br>
<br>
<br>
<br>
<br>
<br>
> On Aug 4, 2015, at 12:50 AM, jl2012 via bitcoin-dev <<a href=3D"jav=
ascript:;" onclick=3D"_e(event, 'cvml', 'bitcoin-dev@lists.linu=
xfoundation.org')">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:=
<br>
><br>
> As now we have some concrete proposals (<a href=3D"https://lists.linux=
foundation.org/pipermail/bitcoin-dev/2015-July/009808.html" target=3D"_blan=
k">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808=
.html</a>), I think we should wrap up the endless debate with voting by dif=
ferent stakeholder groups.<br>
><br>
> ---------------------------------<br>
> Candidate proposals<br>
><br>
> Candidate proposals must be complete BIPs with reference implementatio=
n which are ready to merge immediately. They must first go through the usua=
l peer review process and get approved by the developers in a technical sta=
ndpoint, without political or philosophical considerations. Any fine tune o=
f a candidate proposal may not become an independent candidate, unless it i=
ntroduces some =E2=80=9Creal=E2=80=9D difference. =E2=80=9CNo change=E2=80=
=9D is also one of the voting options.<br>
> ---------------------------------<br>
> Voter groups<br>
><br>
> There will be several voter groups and their votes will be counted ind=
ependently. (The time frames mentioned below are just for example.)<br>
><br>
> Miners: miners of blocks with timestamp between 1 to 30 Sept 2015 are =
eligible to vote. One block one vote. Miners will cast their votes by signi=
ng with the bitcoin address in coinbase. If there are multiple coinbase out=
puts, the vote is discounted by output value / total coinbase output value.=
<br>
> Many well-known pools are reusing addresses and they may not need to d=
igitally sign their votes. In case there is any dispute, the digitally sign=
ed vote will be counted.<br>
><br>
> Bitcoin holders: People with bitcoin in the UTXO at block 372500 (arou=
nd early September) are eligible to vote. The total =E2=80=9Cbalance=E2=80=
=9D of each scriptPubKey is calculated and this is the weight of the vote. =
People will cast their votes by digital signature.<br>
> Special output types:<br>
> Multi-sig: vote must be signed according to the setting of the multi-s=
ig.<br>
> P2SH: the serialized script must be provided<br>
> Publicly known private key: not eligible to vote<br>
> Non-standard script according to latest Bitcoin Core rules: not eligib=
le to vote in general. May be judged case-by-case<br>
><br>
> Developers: People with certain amount of contribution in the past yea=
r in Bitcoin Core or other open sources wallet / alternative implementation=
s. One person one vote.<br>
><br>
> Exchanges: Centralized exchanges listed on Coindesk Bitcoin Index, Win=
kdex, or NYSE Bitcoin index, with 30 days volume >100,000BTC are invited=
. This includes Bitfinex, BTC China, BitStamp, BTC-E, itBit, OKCoin, Huobi,=
Coinbase. Exchanges operated for at least 1 year with 100,000BTC 30-day vo=
lume may also apply to be a voter in this category. One exchange one vote.<=
br>
><br>
> Merchants and service providers: This category includes all bitcoin ac=
cepting business that is not centralized fiat-currency exchange, e.g. virtu=
al or physical stores, gambling sites, online wallet service, payment proce=
ssors like Bitpay, decentralized exchange like Localbitcoin, ETF operators =
like Secondmarket Bitcoin Investment Trust. They must directly process bitc=
oin without relying on third party. They should process at least 100BTC in =
the last 30-days. One merchant one vote.<br>
><br>
> Full nodes operators: People operating full nodes for at least 168 hou=
rs (1 week) in July 2015 are eligible to vote, determined by the log of Bit=
nodes. Time is set in the past to avoid manipulation. One IP address one vo=
te. Vote must be sent from the node=E2=80=99s IP address.<br>
><br>
> --------------------<br>
> Voting system<br>
><br>
> Single transferable vote is applied. (<a href=3D"https://en.wikipedia.=
org/wiki/Single_transferable_vote" target=3D"_blank">https://en.wikipedia.o=
rg/wiki/Single_transferable_vote</a>). Voters are required to rank their pr=
eference with =E2=80=9C1=E2=80=9D, =E2=80=9C2=E2=80=9D, =E2=80=9C3=E2=80=9D=
, etc, or use =E2=80=9CN=E2=80=9D to indicate rejection of a candidate.<br>
> Vote counting starts with every voter=E2=80=99s first choice. The cand=
idate with fewest votes is eliminated and those votes are transferred accor=
ding to their second choice. This process repeats until only one candidate =
is left, which is the most popular candidate. The result is presented as th=
e approval rate: final votes for the most popular candidate / all valid vot=
es<br>
><br>
> After the most popular candidate is determined, the whole counting pro=
cess is repeated by eliminating this candidate, which will find the approva=
l rate for the second most popular candidate. The process repeats until all=
proposals are ranked with the approval rate calculated.<br>
><br>
> --------------------<br>
> Interpretation of results:<br>
><br>
> It is possible that a candidate with lower ranking to have higher appr=
oval rate. However, ranking is more important than the approval rate, unles=
s the difference in approval rate is really huge. 90% support would be exce=
llent; 70% is good; 50% is marginal; <50% is failed.<br>
><br>
> --------------------<br>
> Technical issues:<br>
><br>
> Voting by the miners, developers, exchanges, and merchants are probabl=
y the easiest. We need a trusted person to verify the voters=E2=80=99 ident=
ity by email, website, or digital signature. The trusted person will collec=
t votes and publish the named votes so anyone could verify the results.<br>
><br>
> For full nodes, we need a trusted person to setup a website as an inte=
rface to vote. The votes with IP address will be published.<br>
><br>
> For bitcoin holders, the workload could be very high and we may need s=
ome automatic system to collect and count the votes. If people are worrying=
about reduced security due to exposed raw public key, they should move the=
ir bitcoin to a new address before voting.<br>
><br>
> Double voting: people are generally not allowed to change their mind a=
fter voting, especially for anonymous voters like bitcoin holders and solo =
miners. A double voting attempt from these classes will invalidate all rela=
ted votes.<br>
><br>
> Multiple identity: People may have multiple roles in the Bitcoin ecolo=
gy. I believe they should be allowed to vote in all applicable categories s=
ince they are contributing more than other people.<br>
><br>
> _______________________________________________<br>
> bitcoin-dev mailing list<br>
> <a href=3D"javascript:;" onclick=3D"_e(event, 'cvml', 'bit=
coin-dev@lists.linuxfoundation.org')">bitcoin-dev@lists.linuxfoundation=
.org</a><br>
> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" target=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/b=
itcoin-dev</a><br>
<br><br>-- <br><div dir=3D"ltr">I like to provide some work at no charge to=
prove my value. Do you need a techie?=C2=A0 <br>I own <a href=3D"http://ww=
w.litmocracy.com" target=3D"_blank">Litmocracy</a> and <a href=3D"http://ww=
w.memeracing.net" target=3D"_blank">Meme Racing</a> (in alpha). <br>I'm=
the webmaster for <a href=3D"http://www.voluntaryist.com" target=3D"_blank=
">The Voluntaryist</a> which now accepts Bitcoin.<br>I also code for <a hre=
f=3D"http://dollarvigilante.com/" target=3D"_blank">The Dollar Vigilante</a=
>.<br>"He ought to find it more profitable to play by the rules" =
- Satoshi Nakamoto</div><br>
--089e013c60c0659639051cacda17--
|