path: root/75/dc8f7a5c5e9ebe3f1b589b7019f9dd3c6433a9

Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 0FDE97F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  4 Aug 2015 09:03:25 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f177.google.com (mail-io0-f177.google.com
	[209.85.223.177])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 997A511E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  4 Aug 2015 09:03:23 +0000 (UTC)
Received: by ioeg141 with SMTP id g141so10485079ioe.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 04 Aug 2015 02:03:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=KKFZZwMbc6zFFi1SiKqbB7BSeUVa6dszV9TpSl6immU=;
	b=hs6txM0xqt8zsHdrO5HwWPwkwmnypOvT79Re+/pTYDK1xvhGX6IpinPcmz8sy4qbct
	nSmH9HYc3YyMuR01x48TMHbT53THIqRVaWAaipojaLvhsbJ2aXnTvrtA3anhUfChM8sf
	/YbnJu9S0da5NMaGKQxxm4aTDN9LaDhSvUKCGs1TIsDZlQZEYFKIe6mmBRhCBzZ1lNVV
	TbM/4JgpJZragqohzm1hz/p/QG2ey/BDY8CT1PZ81g107uULvEh1QOkiAiVX7cUw2NK+
	YzrrtyVPfkZImAjwbFYg/OZToorl38JyLrRVDfvXnrFK34r2yjbfRpCBU4ABqO/fTCwv
	Pa7Q==
MIME-Version: 1.0
X-Received: by 10.107.37.142 with SMTP id l136mr2369154iol.126.1438679002920; 
	Tue, 04 Aug 2015 02:03:22 -0700 (PDT)
Received: by 10.36.77.201 with HTTP; Tue, 4 Aug 2015 02:03:22 -0700 (PDT)
Received: by 10.36.77.201 with HTTP; Tue, 4 Aug 2015 02:03:22 -0700 (PDT)
In-Reply-To: <1c808715eac12f67cf9865dfd97c0a37@xbt.hk>
References: <1c808715eac12f67cf9865dfd97c0a37@xbt.hk>
Date: Tue, 4 Aug 2015 11:03:22 +0200
Message-ID: <CAPg+sBgvMS112vO3=TjBXitmXLLa1CngeqmK+RWqwR+WOoj2VA@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: jl2012@xbt.hk
Content-Type: multipart/alternative; boundary=001a1140269aea3cf2051c788efd
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [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 09:03:25 -0000

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

I would like to withdraw my proposal from your self-appointed vote.

If you want to let a majority decide about economic policy of a currency, I
suggest fiat currencies. They have been using this approach for quite a
while, I hear.

Bitcoin's consensus rules are a consensus system, not a democracy. Find a
solution that everyone agrees on, or don't.
On Aug 4, 2015 9:51 AM, "jl2012 via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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 usua=
l
> 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 =
change=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 wil=
l
> 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 i=
n
> 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, OKCoi=
n,
> 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, paymen=
t
> 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 o=
ne
> 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 lef=
t,
> which is the most popular candidate. The result is presented as the
> approval rate: final votes for the most popular candidate / all valid vot=
es
>
> After the most popular candidate is determined, the whole counting proces=
s
> 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 approva=
l
> rate. However, ranking is more important than the approval rate, unless t=
he
> difference in approval rate is really huge. 90% support would be excellen=
t;
> 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 ident=
ity by
> email, website, or digital signature. The trusted person will collect vot=
es
> 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 afte=
r
> 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 sin=
ce
> they are contributing more than other people.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<p dir=3D"ltr">I would like to withdraw my proposal from your self-appointe=
d vote.</p>
<p dir=3D"ltr">If you want to let a majority decide about economic policy o=
f a currency, I suggest fiat currencies. They have been using this approach=
 for quite a while, I hear.</p>
<p dir=3D"ltr">Bitcoin&#39;s consensus rules are a consensus system, not a =
democracy. Find a solution that everyone agrees on, or don&#39;t.</p>
<div class=3D"gmail_quote">On Aug 4, 2015 9:51 AM, &quot;jl2012 via bitcoin=
-dev&quot; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bit=
coin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br type=3D"attribution"><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">As now we have some concrete proposals (<a hr=
ef=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009=
808.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundatio=
n.org/pipermail/bitcoin-dev/2015-July/009808.html</a>), I think we should w=
rap up the endless debate with voting by different stakeholder groups.<br>
<br>
---------------------------------<br>
Candidate proposals<br>
<br>
Candidate proposals must be complete BIPs with reference implementation whi=
ch are ready to merge immediately. They must first go through the usual pee=
r review process and get approved by the developers in a technical standpoi=
nt, without political or philosophical considerations. Any fine tune of a c=
andidate proposal may not become an independent candidate, unless it introd=
uces 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 independ=
ently. (The time frames mentioned below are just for example.)<br>
<br>
Miners: miners of blocks with timestamp between 1 to 30 Sept 2015 are eligi=
ble to vote. One block one vote. Miners will cast their votes by signing wi=
th the bitcoin address in coinbase. If there are multiple coinbase outputs,=
 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 digita=
lly sign their votes. In case there is any dispute, the digitally signed vo=
te will be counted.<br>
<br>
Bitcoin holders: People with bitcoin in the UTXO at block 372500 (around ea=
rly 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-sig.<b=
r>
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 eligible to=
 vote in general. May be judged case-by-case<br>
<br>
Developers: People with certain amount of contribution in the past year in =
Bitcoin Core or other open sources wallet / alternative implementations. On=
e person one vote.<br>
<br>
Exchanges: Centralized exchanges listed on Coindesk Bitcoin Index, Winkdex,=
 or NYSE Bitcoin index, with 30 days volume &gt;100,000BTC are invited. Thi=
s includes Bitfinex, BTC China, BitStamp, BTC-E, itBit, OKCoin, Huobi, Coin=
base. 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.<br>
<br>
Merchants and service providers: This category includes all bitcoin accepti=
ng 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 w=
ithout relying on third party. They should process at least 100BTC in the l=
ast 30-days. One merchant one vote.<br>
<br>
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. V=
ote 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/w=
iki/Single_transferable_vote" rel=3D"noreferrer" target=3D"_blank">https://=
en.wikipedia.org/wiki/Single_transferable_vote</a>). 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.<br>
Vote counting starts with every voter=E2=80=99s 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 le=
ft, which is the most popular candidate. The result is presented as the app=
roval rate: final votes for the most popular candidate / all valid votes<br=
>
<br>
After the most popular candidate is determined, the whole counting process =
is repeated by eliminating this candidate, which will find the approval rat=
e for the second most popular candidate. The process repeats until all prop=
osals 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 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; &lt;50% is failed.<br>
<br>
--------------------<br>
Technical issues:<br>
<br>
Voting by the miners, developers, exchanges, and merchants are probably the=
 easiest. We need a trusted person to verify the voters=E2=80=99 identity b=
y email, website, or digital signature. The trusted person will collect vot=
es 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 interface=
 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 some a=
utomatic system to collect and count the votes. If people are worrying abou=
t reduced security due to exposed raw public key, they should move their bi=
tcoin to a new address before voting.<br>
<br>
Double voting: people are generally not allowed to change their mind after =
voting, especially for anonymous voters like bitcoin holders and solo miner=
s. A double voting attempt from these classes will invalidate all related v=
otes.<br>
<br>
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.<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--001a1140269aea3cf2051c788efd--