path: root/0c/3f341b071a509ed22f2ec4fc231748e8a54923

Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <melvincarvalho@gmail.com>) id 1UlxEw-0003Br-E8
	for bitcoin-development@lists.sourceforge.net;
	Mon, 10 Jun 2013 08:14:10 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.49 as permitted sender)
	client-ip=209.85.215.49; envelope-from=melvincarvalho@gmail.com;
	helo=mail-la0-f49.google.com; 
Received: from mail-la0-f49.google.com ([209.85.215.49])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1UlxEu-00048M-K1
	for bitcoin-development@lists.sourceforge.net;
	Mon, 10 Jun 2013 08:14:10 +0000
Received: by mail-la0-f49.google.com with SMTP id ea20so1873983lab.8
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 10 Jun 2013 01:14:01 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.61.199 with SMTP id s7mr162590lbr.53.1370852041831; Mon,
	10 Jun 2013 01:14:01 -0700 (PDT)
Received: by 10.112.2.8 with HTTP; Mon, 10 Jun 2013 01:14:01 -0700 (PDT)
In-Reply-To: <CAPaL=UWcKmnChw0zYGVduzHHdQ-AgG7uqbCLvjjuW6Q67zmS0g@mail.gmail.com>
References: <CAPaL=UWcKmnChw0zYGVduzHHdQ-AgG7uqbCLvjjuW6Q67zmS0g@mail.gmail.com>
Date: Mon, 10 Jun 2013 10:14:01 +0200
Message-ID: <CAKaEYhLsSm6KTr3YV+GxQGiBBNX0psxxOYkgwR1pm4ZpBY0Ymw@mail.gmail.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: John Dillon <john.dillon892@googlemail.com>
Content-Type: multipart/alternative; boundary=001a1133d17afe3b8704dec85cd5
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(melvincarvalho[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1UlxEu-00048M-K1
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal: Vote on the blocksize limit
 with proof-of-stake voting
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 10 Jun 2013 08:14:10 -0000

--001a1133d17afe3b8704dec85cd5
Content-Type: text/plain; charset=ISO-8859-1

On 10 June 2013 06:09, John Dillon <john.dillon892@googlemail.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> It has been suggested that we leave the decision of what the blocksize to
> be
> entirely up to miners. However this leaves a parameter that affects every
> Bitcoin participant in the control of a small minority. Of course we can
> not
> force miners to increase the blocksize if they choose to decrease it,
> because
> the contents of the blocks they make are their decision and their decision
> only. However proposals to leave the maximum size unlimited to allow
> miners to
> force us to accept arbitrarily large blocks even if the will of the
> majority of
> Bitcoin participants is that they wish to remain able to validate the
> blockchain.
>
> What we need is a way to balance this asymetrical power relationship.
>
> Proof-of-stake voting gives us a way of achieving that balance.
> Essentially for
> a miner to prove that the majority will of the poeple is to accept a larger
> blocksize they must prove that the majority has in fact voted for that
> increase. The upper limit on the blocksize is then determined by the
> median of
> all votes, where each txout in the UTXO set is one vote, weighted by txout
> value. A txout without a corresponding vote is considered to be a vote for
> the
> status quo. To allow the voting process to continue even if coins are
> "lost"
> votes, including default votes, are weighted inversely according to their
> age
> in years after 1 year. IE a vote with weight 1BTC that is 1.5 years old
> will be
> recorded the same as a <1 year old vote weighted as 0.67BTC, and a 1 day
> old
> and 6 months old UTXO are treated equivalently. The 1 year minimum is
> simply to
> make voting required no more than once per year. (of course, a real
> implementation should do all of these figures by block height, IE after
> 52,560
> blocks instead of after 1 year)
>
> A vote will consist of a txout with a scriptPubKey of the following form:
>
>     OP_RETURN magic vote_id txid vout vote scriptSig
>
> Where scriptSig is a valid signature for a transaction with nLockTime
> 500,000,000-1 spending txid:vout to scriptPubKey:
>
>     OP_HASH160 H(OP_RETURN magic vote_id txid vout vote) OP_EQUAL
>
> vote_id is the ID of the specific vote being made, and magic is included to
> allow UTXO proof implementations a as yet unspecified way of identifying
> votes
> and including the weighted median as part of the UTXO tree sums. (it also
> allows SPV clients to verify the vote if the UTXO set is a Patricia tree of
> scriptPubKeys) vote is just the numerical vote itself. The vote must
> compute
> the median, rather than the mean, so as to not allow someone to skew the
> vote
> by simply setting their value extremely high. Someone who still remembers
> their
> statistics classes should chime in on the right way to compute a median in
> a
> merkle-sum-tree.
>
> The slightly unusual construction of votes makes implementation by wallet
> software as simple as possible within existing code-paths. Votes could
> still be
> constructed even in wallets lacking specific voting capability provided the
> wallet software does have the ability to set nLockTime.
>
> Of course in the future the voting mechanism can be used for additional
> votes
> with an additional vote_id. For instance the Bitcoin community could vote
> to
> increase the inflation subsidy, another example of a situation where the
> wishes
> of miners may conflict with the wishes of the broader community.
>
> Users may of course actually create these specially encoded txouts
> themselves
> and get them into the blockchain.  However doing so is not needed as a
> given
> vote is only required to actually be in the chain by a miner wishing to
> increase the blocksize. Thus we should extend the P2P protocol with a
> mechanism
> by which votes can be broadcast independently of transactions. To prevent
> DoS
> attacks only votes with known vote_id's will be accepted, and only for
> txid:vout's already in the blockchain, and a record of txouts for whom
> votes
> have already broadcast will be kept. (this record need not be
> authoritative as
> its purpose is only to prevent DoS attacks) Miners wishing to increase the
> blocksize can record these votes and include them in the blocks they mine
> as
> required. To reduce the cost of including votes in blocks 5% of every block
> should be assigned to voting only. (this can be implemented by a soft-fork)
>
> For any given block actual limit in effect is then the rolling median of
> the
> blocks in the last year. At the beginning of every year the value
> considered to
> be the status quo resets to the mean of the limit at the beginning and end
> of
> the interval.  (again, by "year" we really mean 52,560 blocks) The rolling
> median and periodic reset process ensures that the limit changes gradually
> and
> is not influenced by temporary events such as hacks to large exchanges or
> malicious wallet software.  The rolling median also ensures that for a
> miner
> the act of including a vote is never wasted due to the txout later being
> spent.
>
> Implementing the voting system can happen prior to an actual hard-fork
> allowing
> for an increase and can be an important part of determining if the
> hard-fork is
> required at all.
>
> Coercion and vote buying is of course possible in this system. A miner
> could
> say that they will only accept transactions accompanied by a vote for a
> given
> limit. However in a decentralized system completely preventing vote buying
> is
> of course impossble, and the design of Bitcoin itself has a fundemental
> assumption that a majority of miners will behave in a specific kind of
> "honest"
> way.
>
> A voting process ensures that any increase to the blocksize genuinely
> represents the desires of the Bitcoin community, and the process described
> above ensures that any changes happen at a rate that gives all participants
> time to react. The process also gives a mechanism for the community to
> vote to
> decrease the limit if it turns out that the new one was in fact too high.
> (note
> how the way the status quo is set ensures the default action is for the
> limit
> to gradually decrease even if everyone stops voting)
>
> As many of you know I have been quite vocal that the 1MB limit should
> stay. But
> I would be happy to support the outcome of a vote done properly, whatever
> that
> outcome may be.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iQEcBAEBCAAGBQJRtVFBAAoJEEWCsU4mNhiP6EAIAMjq4UgXxmEjOgHWf0KcmwmH
> Ra/I3oY7krvg/lu1YCa+ACMBdoca9WODySUIe7R3niphKXEnknHGUIf8tm/Vrq4H
> gPF4cgYEr18EYTVtvT9J1pZUB4f5dxkXXNpcQ60juaz9KervFQMOGnpr6Fyxi3dS
> ghObNYcr3D2v1fjx56sp7BCNn0XHxTb1ZLUJB0BZhDKlamfgcxruKMbpsZmACJUj
> gTNLNweaAomBIH++j7cnXeB0jZc/1ilv8qLA/f3TGb43FDkAQcvvSjGijI+OJOm6
> Fh/WRBav1BJiV6PKs9xuHXsaxZ/T7Fb8Wg8EynSi0mSj47QXdKZgeZCi3XlSyxM=
> =aKBD
> -----END PGP SIGNATURE-----
>

-1

Firstly I appreciate the ingenious thought that went into this post.

However, Bitcoin's fundamental philosophy was one CPU one vote.

Voting is easily gamed.  While this may work in one particular case, it is
perhaps a bad precedent to set.  Establishing methods of voting can lead to
single points of failure.

The asymmetry lies in psychological terms, in that new defaults tend to be
adopted 80% of the time, so core devs have disproportionate amount of power
as things stand.

Unless there's a very good reason not to, e.g. miners are clearly abusing
the system, we should stick with 1 CPU one vote.


>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--001a1133d17afe3b8704dec85cd5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 10 June 2013 06:09, John Dillon <span dir=3D"ltr">&lt;<a href=3D=
"mailto:john.dillon892@googlemail.com" target=3D"_blank">john.dillon892@goo=
glemail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">-----BEGIN PGP SIGNED MES=
SAGE-----<br>
Hash: SHA256<br>
<br>
It has been suggested that we leave the decision of what the blocksize to b=
e<br>
entirely up to miners. However this leaves a parameter that affects every<b=
r>
Bitcoin participant in the control of a small minority. Of course we can no=
t<br>
force miners to increase the blocksize if they choose to decrease it, becau=
se<br>
the contents of the blocks they make are their decision and their decision<=
br>
only. However proposals to leave the maximum size unlimited to allow miners=
 to<br>
force us to accept arbitrarily large blocks even if the will of the majorit=
y of<br>
Bitcoin participants is that they wish to remain able to validate the<br>
blockchain.<br>
<br>
What we need is a way to balance this asymetrical power relationship.<br>
<br>
Proof-of-stake voting gives us a way of achieving that balance. Essentially=
 for<br>
a miner to prove that the majority will of the poeple is to accept a larger=
<br>
blocksize they must prove that the majority has in fact voted for that<br>
increase. The upper limit on the blocksize is then determined by the median=
 of<br>
all votes, where each txout in the UTXO set is one vote, weighted by txout<=
br>
value. A txout without a corresponding vote is considered to be a vote for =
the<br>
status quo. To allow the voting process to continue even if coins are &quot=
;lost&quot;<br>
votes, including default votes, are weighted inversely according to their a=
ge<br>
in years after 1 year. IE a vote with weight 1BTC that is 1.5 years old wil=
l be<br>
recorded the same as a &lt;1 year old vote weighted as 0.67BTC, and a 1 day=
 old<br>
and 6 months old UTXO are treated equivalently. The 1 year minimum is simpl=
y to<br>
make voting required no more than once per year. (of course, a real<br>
implementation should do all of these figures by block height, IE after 52,=
560<br>
blocks instead of after 1 year)<br>
<br>
A vote will consist of a txout with a scriptPubKey of the following form:<b=
r>
<br>
=A0 =A0 OP_RETURN magic vote_id txid vout vote scriptSig<br>
<br>
Where scriptSig is a valid signature for a transaction with nLockTime<br>
500,000,000-1 spending txid:vout to scriptPubKey:<br>
<br>
=A0 =A0 OP_HASH160 H(OP_RETURN magic vote_id txid vout vote) OP_EQUAL<br>
<br>
vote_id is the ID of the specific vote being made, and magic is included to=
<br>
allow UTXO proof implementations a as yet unspecified way of identifying vo=
tes<br>
and including the weighted median as part of the UTXO tree sums. (it also<b=
r>
allows SPV clients to verify the vote if the UTXO set is a Patricia tree of=
<br>
scriptPubKeys) vote is just the numerical vote itself. The vote must comput=
e<br>
the median, rather than the mean, so as to not allow someone to skew the vo=
te<br>
by simply setting their value extremely high. Someone who still remembers t=
heir<br>
statistics classes should chime in on the right way to compute a median in =
a<br>
merkle-sum-tree.<br>
<br>
The slightly unusual construction of votes makes implementation by wallet<b=
r>
software as simple as possible within existing code-paths. Votes could stil=
l be<br>
constructed even in wallets lacking specific voting capability provided the=
<br>
wallet software does have the ability to set nLockTime.<br>
<br>
Of course in the future the voting mechanism can be used for additional vot=
es<br>
with an additional vote_id. For instance the Bitcoin community could vote t=
o<br>
increase the inflation subsidy, another example of a situation where the wi=
shes<br>
of miners may conflict with the wishes of the broader community.<br>
<br>
Users may of course actually create these specially encoded txouts themselv=
es<br>
and get them into the blockchain. =A0However doing so is not needed as a gi=
ven<br>
vote is only required to actually be in the chain by a miner wishing to<br>
increase the blocksize. Thus we should extend the P2P protocol with a mecha=
nism<br>
by which votes can be broadcast independently of transactions. To prevent D=
oS<br>
attacks only votes with known vote_id&#39;s will be accepted, and only for<=
br>
txid:vout&#39;s already in the blockchain, and a record of txouts for whom =
votes<br>
have already broadcast will be kept. (this record need not be authoritative=
 as<br>
its purpose is only to prevent DoS attacks) Miners wishing to increase the<=
br>
blocksize can record these votes and include them in the blocks they mine a=
s<br>
required. To reduce the cost of including votes in blocks 5% of every block=
<br>
should be assigned to voting only. (this can be implemented by a soft-fork)=
<br>
<br>
For any given block actual limit in effect is then the rolling median of th=
e<br>
blocks in the last year. At the beginning of every year the value considere=
d to<br>
be the status quo resets to the mean of the limit at the beginning and end =
of<br>
the interval. =A0(again, by &quot;year&quot; we really mean 52,560 blocks) =
The rolling<br>
median and periodic reset process ensures that the limit changes gradually =
and<br>
is not influenced by temporary events such as hacks to large exchanges or<b=
r>
malicious wallet software. =A0The rolling median also ensures that for a mi=
ner<br>
the act of including a vote is never wasted due to the txout later being sp=
ent.<br>
<br>
Implementing the voting system can happen prior to an actual hard-fork allo=
wing<br>
for an increase and can be an important part of determining if the hard-for=
k is<br>
required at all.<br>
<br>
Coercion and vote buying is of course possible in this system. A miner coul=
d<br>
say that they will only accept transactions accompanied by a vote for a giv=
en<br>
limit. However in a decentralized system completely preventing vote buying =
is<br>
of course impossble, and the design of Bitcoin itself has a fundemental<br>
assumption that a majority of miners will behave in a specific kind of &quo=
t;honest&quot;<br>
way.<br>
<br>
A voting process ensures that any increase to the blocksize genuinely<br>
represents the desires of the Bitcoin community, and the process described<=
br>
above ensures that any changes happen at a rate that gives all participants=
<br>
time to react. The process also gives a mechanism for the community to vote=
 to<br>
decrease the limit if it turns out that the new one was in fact too high. (=
note<br>
how the way the status quo is set ensures the default action is for the lim=
it<br>
to gradually decrease even if everyone stops voting)<br>
<br>
As many of you know I have been quite vocal that the 1MB limit should stay.=
 But<br>
I would be happy to support the outcome of a vote done properly, whatever t=
hat<br>
outcome may be.<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.11 (GNU/Linux)<br>
<br>
iQEcBAEBCAAGBQJRtVFBAAoJEEWCsU4mNhiP6EAIAMjq4UgXxmEjOgHWf0KcmwmH<br>
Ra/I3oY7krvg/lu1YCa+ACMBdoca9WODySUIe7R3niphKXEnknHGUIf8tm/Vrq4H<br>
gPF4cgYEr18EYTVtvT9J1pZUB4f5dxkXXNpcQ60juaz9KervFQMOGnpr6Fyxi3dS<br>
ghObNYcr3D2v1fjx56sp7BCNn0XHxTb1ZLUJB0BZhDKlamfgcxruKMbpsZmACJUj<br>
gTNLNweaAomBIH++j7cnXeB0jZc/1ilv8qLA/f3TGb43FDkAQcvvSjGijI+OJOm6<br>
Fh/WRBav1BJiV6PKs9xuHXsaxZ/T7Fb8Wg8EynSi0mSj47QXdKZgeZCi3XlSyxM=3D<br>
=3DaKBD<br>
-----END PGP SIGNATURE-----<br></blockquote><div><br></div><div>-1<br><br><=
/div><div>Firstly I appreciate the ingenious thought that went into this po=
st.<br></div><div><br></div><div>However, Bitcoin&#39;s fundamental philoso=
phy was one CPU one vote.<br>
<br>Voting is easily gamed.=A0 While this may work in one particular case, =
it is perhaps a bad precedent to set.=A0 Establishing methods of voting can=
 lead to single points of failure.<br><br></div><div>The asymmetry lies in =
psychological terms, in that new defaults tend to be adopted 80% of the tim=
e, so core devs have disproportionate amount of power as things stand.=A0 <=
br>
<br></div><div>Unless there&#39;s a very good reason not to, e.g. miners ar=
e clearly abusing the system, we should stick with 1 CPU one vote.<br></div=
><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<br>
---------------------------------------------------------------------------=
---<br>
How ServiceNow helps IT people transform IT departments:<br>
1. A cloud service to automate IT design, transition and operations<br>
2. Dashboards that offer high-level views of enterprise services<br>
3. A single system of record for all IT processes<br>
<a href=3D"http://p.sf.net/sfu/servicenow-d2d-j" target=3D"_blank">http://p=
.sf.net/sfu/servicenow-d2d-j</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div><br></div></div>

--001a1133d17afe3b8704dec85cd5--