<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 10 June 2013 06:09, John Dillon <span dir="ltr">&lt;<a href="mailto:john.dillon892@googlemail.com" target="_blank">john.dillon892@googlemail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #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 be<br>
entirely up to miners. However this leaves a parameter that affects every<br>
Bitcoin participant in the control of a small minority. Of course we can not<br>
force miners to increase the blocksize if they choose to decrease it, because<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 majority 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 age<br>
in years after 1 year. IE a vote with weight 1BTC that is 1.5 years old will 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 simply 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:<br>
<br>
    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>
    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 votes<br>
and including the weighted median as part of the UTXO tree sums. (it also<br>
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 compute<br>
the median, rather than the mean, so as to not allow someone to skew the vote<br>
by simply setting their value extremely high. Someone who still remembers their<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<br>
software as simple as possible within existing code-paths. Votes could still 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 votes<br>
with an additional vote_id. For instance the Bitcoin community could vote to<br>
increase the inflation subsidy, another example of a situation where the wishes<br>
of miners may conflict with the wishes of the broader community.<br>
<br>
Users may of course actually create these specially encoded txouts themselves<br>
and get them into the blockchain.  However doing so is not needed as a given<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 mechanism<br>
by which votes can be broadcast independently of transactions. To prevent DoS<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 as<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 the<br>
blocks in the last year. At the beginning of every year the value considered to<br>
be the status quo resets to the mean of the limit at the beginning and end of<br>
the interval.  (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<br>
malicious wallet software.  The rolling median also ensures that for a miner<br>
the act of including a vote is never wasted due to the txout later being spent.<br>
<br>
Implementing the voting system can happen prior to an actual hard-fork allowing<br>
for an increase and can be an important part of determining if the hard-fork is<br>
required at all.<br>
<br>
Coercion and vote buying is of course possible in this system. A miner could<br>
say that they will only accept transactions accompanied by a vote for a given<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 &quot;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 limit<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 that<br>
outcome may be.<br></blockquote><div><br></div><div>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&#39;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.  <br>
<br></div><div>At this point in time it&#39;s far too easy to deliver contentious changes into the hands of the general population.  I think that fortunately we&#39;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.  <br>
</div><div><br></div><div> </div><blockquote class="gmail_quote" style="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=<br>
=aKBD<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="http://p.sf.net/sfu/servicenow-d2d-j" target="_blank">http://p.sf.net/sfu/servicenow-d2d-j</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
</blockquote></div><br></div></div>