Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.47 as permitted sender)
	client-ip=209.85.215.47; envelope-from=melvincarvalho@gmail.com;
	helo=mail-la0-f47.google.com; 
MIME-Version: 1.0
In-Reply-To: <CAPaL=UWcKmnChw0zYGVduzHHdQ-AgG7uqbCLvjjuW6Q67zmS0g@mail.gmail.com>
References: <CAPaL=UWcKmnChw0zYGVduzHHdQ-AgG7uqbCLvjjuW6Q67zmS0g@mail.gmail.com>
Date: Sat, 22 Jun 2013 14:05:41 +0200
Message-ID: <CAKaEYhL2YY6wWnUYJuwWo2czHq7hRiYsQouR1B64oE31ZEochg@mail.gmail.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: John Dillon <john.dillon892@googlemail.com>
Content-Type: multipart/alternative; boundary=001a11c242fe96fe7504dfbcff84
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal: Vote on the blocksize limit
 with proof-of-stake voting
Precedence: list

--001a11c242fe96fe7504dfbcff84
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.
>

Thinking about this a little more, I guess it does not hurt to build some
kind of voting system into the clients.  But I think it's more useful for
straw polls.  For example a bug fix 100% of people should agree on.  A
protocol optimization perhaps 80% would agree on.  A protocol change that
redistributes wealth or incentives perhaps only 60% will agree on.

At this point in time it's far too easy to deliver contentious changes into
the hands of the general population.  I think that fortunately we're
blessed with a very strong dev team, but the fundamental philosophy of
bitcoin is to not put too much trust in single point, but rather, to
distribute and diversify trust to the edges.


> -----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-----
>
>
> ------------------------------------------------------------------------------
> 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
>

--001a11c242fe96fe7504dfbcff84
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:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<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></blockquote><div><br></div><div>Thinking about this a l=
ittle more, I guess it does not hurt to build some kind of voting system in=
to the clients.=A0 But I think it&#39;s more useful for straw polls.=A0 For=
 example a bug fix 100% of people should agree on.=A0 A protocol optimizati=
on perhaps 80% would agree on.=A0 A protocol change that redistributes weal=
th or incentives perhaps only 60% will agree on.=A0 <br>
<br></div><div>At this point in time it&#39;s far too easy to deliver conte=
ntious changes into the hands of the general population.=A0 I think that fo=
rtunately we&#39;re blessed with a very strong dev team, but the fundamenta=
l philosophy of bitcoin is to not put too much trust in single point, but r=
ather, to distribute and diversify trust to the edges.=A0 <br>
</div><div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-----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>
<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>

--001a11c242fe96fe7504dfbcff84--