path: root/e2/fd3138304c87135df6551c2820d64fbbadf842

Return-Path: <hectorchu@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 40B5626C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  4 Aug 2015 09:30:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f42.google.com (mail-la0-f42.google.com
	[209.85.215.42])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A40357C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  4 Aug 2015 09:30:15 +0000 (UTC)
Received: by labow3 with SMTP id ow3so3103146lab.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 04 Aug 2015 02:30:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=/fE9KmWKy+uTHn34N1Dj9rmnGH5ml2cQPKQ/5E2GV5M=;
	b=KLVJEmhFiGPRKlTMfLcudqtiuMWBuFjrWr5Qa9hHSv+bjd1KReGhxYomao5s3aewoh
	PXNuzERdq1TcZB+9EScryq3uQOdZf1PATYrPzQISZDbNyU5G7zBFacEtC3f8FvCXQB+V
	DqDaaSbVhGbDF8UDZaQCDg/LRsoEWJQz4ArdPmKXx3IlmvwPjwhO9zqC1/RteV7EMvog
	q/YCtXyTOjzmEHF3QkaGLCx0SbBncSgDZLyD54flNAkgxuOCo6K8+7T8TzkwVMp98PdP
	vOUhuqptlESl93NSQjGqCl7ppIue6yv85ZWU8IIFG8gpsfJx5OunVPMzTD7WW9b0M+PS
	LN1w==
X-Received: by 10.112.144.69 with SMTP id sk5mr2331127lbb.6.1438680614044;
	Tue, 04 Aug 2015 02:30:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.22.25 with HTTP; Tue, 4 Aug 2015 02:29:54 -0700 (PDT)
In-Reply-To: <CAPg+sBgvMS112vO3=TjBXitmXLLa1CngeqmK+RWqwR+WOoj2VA@mail.gmail.com>
References: <1c808715eac12f67cf9865dfd97c0a37@xbt.hk>
	<CAPg+sBgvMS112vO3=TjBXitmXLLa1CngeqmK+RWqwR+WOoj2VA@mail.gmail.com>
From: Hector Chu <hectorchu@gmail.com>
Date: Tue, 4 Aug 2015 10:29:54 +0100
Message-ID: <CAAO2FKF8eFDVMwh_fM5T1n5x+2S=1m7sn2gjYM5tEhKtkkQuiA@mail.gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b3432f4f20b39051c78ee96
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:30:17 -0000

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

On 4 August 2015 at 10:03, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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.
>
Nearly all the fiat currencies I'm familiar with have their economic policy
dictated by the government or the relevant central bank committee. Ordinary
users of the banking system are not consulted.

> Bitcoin's consensus rules are a consensus system, not a democracy. Find a
> solution that everyone agrees on, or don't.
>
That's correct. The people who disagree will cease using the system, and
quite possibly move to a different one (i.e. Bitcoin XT). The people left
on the old system will indeed have a solution that they all can agree on.


> 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 usu=
al
>> 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 coinbas=
e
>> 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 wi=
ll
>> 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 implementatio=
ns.
>> 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, OKCo=
in,
>> 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 exchang=
e
>> 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, payme=
nt
>> 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 candid=
ate 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
>> approval rate: final votes for the most popular candidate / all valid vo=
tes
>>
>> 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 iden=
tity by
>> email, website, or digital signature. The trusted person will collect vo=
tes
>> 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 som=
e
>> 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 s=
olo
>> 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 si=
nce
>> they are contributing more than other people.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 4=
 August 2015 at 10:03, Pieter Wuille via bitcoin-dev <span dir=3D"ltr">&lt;=
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=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-left:1px #ccc solid=
;padding-left:1ex"><p dir=3D"ltr">If you want to let a majority decide abou=
t economic policy of a currency, I suggest fiat currencies. They have been =
using this approach for quite a while, I hear.<br></p></blockquote><div>Nea=
rly all the fiat currencies I&#39;m familiar with have their economic polic=
y dictated by the government or the relevant central bank committee. Ordina=
ry users of the banking system are not consulted.=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><p dir=3D"ltr"></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></bloc=
kquote><div>That&#39;s correct. The people who disagree will cease using th=
e system, and quite possibly move to a different one (i.e. Bitcoin XT). The=
 people left on the old system will indeed have a solution that they all ca=
n agree on.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div cla=
ss=3D"HOEnZb"><div class=3D"h5">
<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" tar=
get=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br type=
=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">As now we have some concret=
e proposals (<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin=
-dev/2015-July/009808.html" rel=3D"noreferrer" target=3D"_blank">https://li=
sts.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html</a>), I=
 think we should wrap up the endless debate with voting by different stakeh=
older 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>
</div></div><br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">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>
<br></blockquote></div><br></div></div>

--047d7b3432f4f20b39051c78ee96--