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
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id BB81A7E
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 4 Aug 2015 07:50:45 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from s47.web-hosting.com (s47.web-hosting.com [199.188.200.16])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2199D7D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 4 Aug 2015 07:50:44 +0000 (UTC)
Received: from localhost ([::1]:53747 helo=server47.web-hosting.com)
by server47.web-hosting.com with esmtpa (Exim 4.85)
(envelope-from <jl2012@xbt.hk>) id 1ZMWzj-004G5J-BG
for bitcoin-dev@lists.linuxfoundation.org;
Tue, 04 Aug 2015 03:50:43 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
format=flowed
Content-Transfer-Encoding: 8bit
Date: Tue, 04 Aug 2015 03:50:43 -0400
From: jl2012@xbt.hk
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <1c808715eac12f67cf9865dfd97c0a37@xbt.hk>
X-Sender: jl2012@xbt.hk
User-Agent: Roundcube Webmail/1.0.5
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - server47.web-hosting.com
X-AntiAbuse: Original Domain - lists.linuxfoundation.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - xbt.hk
X-Get-Message-Sender-Via: server47.web-hosting.com: authenticated_id:
jl2012@xbt.hk
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_40,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: Tue, 04 Aug 2015 07:50:45 -0000
As now we have some concrete proposals
(https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html),
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 “real” difference. “No change” 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 “balance” 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’s 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 “1”, “2”, “3”, etc, or use “N” to
indicate rejection of a candidate.
Vote counting starts with every voter’s first choice. The candidate 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’ identity 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.
|
