<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;">> 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 "lost"<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 <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's will be accepted, and
only for<br>
> txid:vout'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 "year" 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 "honest"<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>
><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 class="moz-txt-link-freetext" href="http://p.sf.net/sfu/servicenow-d2d-j">http://p.sf.net/sfu/servicenow-d2d-j</a><br>
> _______________________________________________<br>
> Bitcoin-development mailing list<br>
> <a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
>
<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>
> .<br>
></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>