<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    -----BEGIN PGP SIGNED MESSAGE-----<br>
    Hash: SHA1<br>
    <br>
    John,<br>
    <br>
    What you are recommending is a drastic change that the conservative
    bitcoin developers probably wouldn't get behind (but let's see).
    However proof-of-stake voting on protocol soft-forks has vast
    implications even beyond the block size limit. Within Freicoin, we
    have looked at is as a possibility for determining how to distribute
    the demurrage, a proposal we are calling 'Republicoin' due to the
    fact that with proxy voting we expect a system to emerge similar to
    the government budgeting in parliamentary republics. Distributed,
    non-coersive government by protocol, if you will.<br>
    <br>
    So anyway, even if you get shot down, please continue to pursue this
    proposal. It very likely has uses that you haven't thought of yet.<br>
    <br>
    Cheers,<br>
    Mark<br>
    <br>
    On 6/9/13 9:09 PM, John Dillon wrote:<br>
    <span style="white-space: pre;">&gt; It has been suggested that we
      leave the decision of what the blocksize to be<br>
      &gt; entirely up to miners. However this leaves a parameter that
      affects every<br>
      &gt; Bitcoin participant in the control of a small minority. Of
      course we can not<br>
      &gt; force miners to increase the blocksize if they choose to
      decrease it, because<br>
      &gt; the contents of the blocks they make are their decision and
      their decision<br>
      &gt; only. However proposals to leave the maximum size unlimited
      to allow miners to<br>
      &gt; force us to accept arbitrarily large blocks even if the will
      of the majority of<br>
      &gt; Bitcoin participants is that they wish to remain able to
      validate the<br>
      &gt; blockchain.<br>
      &gt;<br>
      &gt; What we need is a way to balance this asymetrical power
      relationship.<br>
      &gt;<br>
      &gt; Proof-of-stake voting gives us a way of achieving that
      balance. Essentially for<br>
      &gt; a miner to prove that the majority will of the poeple is to
      accept a larger<br>
      &gt; blocksize they must prove that the majority has in fact voted
      for that<br>
      &gt; increase. The upper limit on the blocksize is then determined
      by the median of<br>
      &gt; all votes, where each txout in the UTXO set is one vote,
      weighted by txout<br>
      &gt; value. A txout without a corresponding vote is considered to
      be a vote for the<br>
      &gt; status quo. To allow the voting process to continue even if
      coins are "lost"<br>
      &gt; votes, including default votes, are weighted inversely
      according to their age<br>
      &gt; in years after 1 year. IE a vote with weight 1BTC that is 1.5
      years old will be<br>
      &gt; recorded the same as a &lt;1 year old vote weighted as
      0.67BTC, and a 1 day old<br>
      &gt; and 6 months old UTXO are treated equivalently. The 1 year
      minimum is simply to<br>
      &gt; make voting required no more than once per year. (of course,
      a real<br>
      &gt; implementation should do all of these figures by block
      height, IE after 52,560<br>
      &gt; blocks instead of after 1 year)<br>
      &gt;<br>
      &gt; A vote will consist of a txout with a scriptPubKey of the
      following form:<br>
      &gt;<br>
      &gt;&nbsp;&nbsp;&nbsp;&nbsp; OP_RETURN magic vote_id txid vout vote scriptSig<br>
      &gt;<br>
      &gt; Where scriptSig is a valid signature for a transaction with
      nLockTime<br>
      &gt; 500,000,000-1 spending txid:vout to scriptPubKey:<br>
      &gt;<br>
      &gt;&nbsp;&nbsp;&nbsp;&nbsp; OP_HASH160 H(OP_RETURN magic vote_id txid vout vote)
      OP_EQUAL<br>
      &gt;<br>
      &gt; vote_id is the ID of the specific vote being made, and magic
      is included to<br>
      &gt; allow UTXO proof implementations a as yet unspecified way of
      identifying votes<br>
      &gt; and including the weighted median as part of the UTXO tree
      sums. (it also<br>
      &gt; allows SPV clients to verify the vote if the UTXO set is a
      Patricia tree of<br>
      &gt; scriptPubKeys) vote is just the numerical vote itself. The
      vote must compute<br>
      &gt; the median, rather than the mean, so as to not allow someone
      to skew the vote<br>
      &gt; by simply setting their value extremely high. Someone who
      still remembers their<br>
      &gt; statistics classes should chime in on the right way to
      compute a median in a<br>
      &gt; merkle-sum-tree.<br>
      &gt;<br>
      &gt; The slightly unusual construction of votes makes
      implementation by wallet<br>
      &gt; software as simple as possible within existing code-paths.
      Votes could still be<br>
      &gt; constructed even in wallets lacking specific voting
      capability provided the<br>
      &gt; wallet software does have the ability to set nLockTime.<br>
      &gt;<br>
      &gt; Of course in the future the voting mechanism can be used for
      additional votes<br>
      &gt; with an additional vote_id. For instance the Bitcoin
      community could vote to<br>
      &gt; increase the inflation subsidy, another example of a
      situation where the wishes<br>
      &gt; of miners may conflict with the wishes of the broader
      community.<br>
      &gt;<br>
      &gt; Users may of course actually create these specially encoded
      txouts themselves<br>
      &gt; and get them into the blockchain.&nbsp; However doing so is not
      needed as a given<br>
      &gt; vote is only required to actually be in the chain by a miner
      wishing to<br>
      &gt; increase the blocksize. Thus we should extend the P2P
      protocol with a mechanism<br>
      &gt; by which votes can be broadcast independently of
      transactions. To prevent DoS<br>
      &gt; attacks only votes with known vote_id's will be accepted, and
      only for<br>
      &gt; txid:vout's already in the blockchain, and a record of txouts
      for whom votes<br>
      &gt; have already broadcast will be kept. (this record need not be
      authoritative as<br>
      &gt; its purpose is only to prevent DoS attacks) Miners wishing to
      increase the<br>
      &gt; blocksize can record these votes and include them in the
      blocks they mine as<br>
      &gt; required. To reduce the cost of including votes in blocks 5%
      of every block<br>
      &gt; should be assigned to voting only. (this can be implemented
      by a soft-fork)<br>
      &gt;<br>
      &gt; For any given block actual limit in effect is then the
      rolling median of the<br>
      &gt; blocks in the last year. At the beginning of every year the
      value considered to<br>
      &gt; be the status quo resets to the mean of the limit at the
      beginning and end of<br>
      &gt; the interval.&nbsp; (again, by "year" we really mean 52,560
      blocks) The rolling<br>
      &gt; median and periodic reset process ensures that the limit
      changes gradually and<br>
      &gt; is not influenced by temporary events such as hacks to large
      exchanges or<br>
      &gt; malicious wallet software.&nbsp; The rolling median also ensures
      that for a miner<br>
      &gt; the act of including a vote is never wasted due to the txout
      later being spent.<br>
      &gt;<br>
      &gt; Implementing the voting system can happen prior to an actual
      hard-fork allowing<br>
      &gt; for an increase and can be an important part of determining
      if the hard-fork is<br>
      &gt; required at all.<br>
      &gt;<br>
      &gt; Coercion and vote buying is of course possible in this
      system. A miner could<br>
      &gt; say that they will only accept transactions accompanied by a
      vote for a given<br>
      &gt; limit. However in a decentralized system completely
      preventing vote buying is<br>
      &gt; of course impossble, and the design of Bitcoin itself has a
      fundemental<br>
      &gt; assumption that a majority of miners will behave in a
      specific kind of "honest"<br>
      &gt; way.<br>
      &gt;<br>
      &gt; A voting process ensures that any increase to the blocksize
      genuinely<br>
      &gt; represents the desires of the Bitcoin community, and the
      process described<br>
      &gt; above ensures that any changes happen at a rate that gives
      all participants<br>
      &gt; time to react. The process also gives a mechanism for the
      community to vote to<br>
      &gt; decrease the limit if it turns out that the new one was in
      fact too high. (note<br>
      &gt; how the way the status quo is set ensures the default action
      is for the limit<br>
      &gt; to gradually decrease even if everyone stops voting)<br>
      &gt;<br>
      &gt; As many of you know I have been quite vocal that the 1MB
      limit should stay. But<br>
      &gt; I would be happy to support the outcome of a vote done
      properly, whatever that<br>
      &gt; outcome may be.<br>
      &gt;<br>
      &gt;
------------------------------------------------------------------------------<br>
      &gt; How ServiceNow helps IT people transform IT departments:<br>
      &gt; 1. A cloud service to automate IT design, transition and
      operations<br>
      &gt; 2. Dashboards that offer high-level views of enterprise
      services<br>
      &gt; 3. A single system of record for all IT processes<br>
      &gt; <a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/servicenow-d2d-j">http://p.sf.net/sfu/servicenow-d2d-j</a><br>
      &gt; _______________________________________________<br>
      &gt; Bitcoin-development mailing list<br>
      &gt; <a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
      &gt;
      <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
      &gt; .<br>
      &gt;</span><br>
    <br>
    -----BEGIN PGP SIGNATURE-----<br>
    Version: GnuPG/MacGPG2 v2.0.19 (Darwin)<br>
    Comment: GPGTools - <a class="moz-txt-link-freetext" href="http://gpgtools.org">http://gpgtools.org</a><br>
    Comment: Using GnuPG with Thunderbird - <a class="moz-txt-link-freetext" href="http://www.enigmail.net/">http://www.enigmail.net/</a><br>
    <br>
    iQIcBAEBAgAGBQJRtgLYAAoJEAdzVfsmodw4vWEQAIWxuEXMZb80qTMFyvWiR0Tt<br>
    Cn/yx8iG2tPa4xGUq0ypwBU3doFEzYBj3bMyQuluGRP7BBhGat4qhrmI/qGVwYXW<br>
    RSQdbdgnp4DXhaOD2QzYh/5zDbN/1jCkuxyUvx/QNAeNEpmN1BoDKhDlM/ywCKdj<br>
    qfFZWj30pTzADJiY7P5upCu3TiYuQtTWTHlap2c4fToNsLxAMiLZJTOE1Ytdc31Q<br>
    O8iwkV7eFlueawtfFLh/dNz5zVKXSOoNz1sFmgjkO3QQaSqSzinBE1z3vR9QYL+A<br>
    R7X1v0sQXDpE0XiPymWE8adjGIai3CBUVZcvnJrPtUznydmpe+OvLf3UZE+QfCuJ<br>
    tLP9u42e+gjOb6r9qp4tLZBGlTR2moY/IPtVs8KiMDWt9Nq1fO94IBGyJgFYOxRn<br>
    Zq6/funKTO6SO8d+ppQ158s2faVmN3OKMrn6BNnfddWD3/EBhGzEDzuNuNAvfKqQ<br>
    nrqEusWrfOZOh66pIs6qvROSamaC42FXMUwBU0wA3W3MEuQhXrGM1S2huKykgZ9W<br>
    WsOpC6ng6j5H5dSIs4tvnsDY9hUa9zWIB1+i368pXDv8biOs7ULKEP3mdC1q+4YD<br>
    tM/MkC0xKax2zG4wbbez8FpwTpUOOznpYPMZqXkLOkGCAdiAyg2UnLPduudaAkQz<br>
    adXXe284XHjjOcZUDvGw<br>
    =trsn<br>
    -----END PGP SIGNATURE-----<br>
    <br>
  </body>
</html>