On 10 June 2013 06:09, John Dillon 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 >