Topic: Proposal: We should vote on the blocksize limit with proof-of-stake voting - page 3. (Read 6343 times)

I think the trick is to make it easy to veto increases.

My proposal was this (to be run during difficulty changes) :


Note that there is no provision for limit decreases.  All increases are permanent.

.95 and 4 are magic numbers.  .95 needs to be very high, to allow an easy veto of the next increase.  If miners want bigger blocks for some reason, they can certainly pad their blocks.  This isn't a big deal, since roughly 6% of the network could execute the veto.  Higher values of .95 mean less mining power is needed for the veto.  Oh, nifty extra benefit, if the size increase is really warranted, those trying to veto will have to pay for it passing up fees.  4 is just a limit on the rate of growth.  A bigger number may be wise here, since the opportunity for limit growth comes up so often.

I hate to say it, but it really looks like this is yet another place where reality intervenes to make POS systems unworkable.

I've suggested this before (many times actually), so naturally I applaud your proposal. I hope you are more persuasive than I am.

Sorry in advance if my approval turns people against the idea.

e.g.

I like the idea. It would definitely be a step towards democracy, which IMHO is quite needed already.

I have some questions about the specifics of the implementations, though.

1. What is the purpose of setting nLockTime to 500,000,000-1?
Is it to prevent old miners (that do not know about voting txs) from mining such transactions?

2. Is it that older coins would have less voting power - or is it only older votes?
Either way I do not get the part when someone casts a vote, then moves the coins and then votes again using the new ones - repeating this over and over...
How do you do the vote accounting to prevent that?

3. Enough vote-type-txs that voted in favor must be mined into block-chain, in order to allow an increase in the block size (or some other change in the protocol) - correct?
But how are you going to decide about the definition of the majority? I mean, there will surely be coins that wont vote at all and we have no idea whether it will be 20, 50 or 80% of the existing coins. Do you also need to mine the votes that were against the change? If so: why would you want to do that?

4. As you have noticed yourself plenty of coins are kept at exchanges - and I do not know if it's better or worse to move the problem of centralization of voting power from mining pools to bitcoin banks, which will likely hold even more coins in the future, because of the increasing on-chain transactions costs.
I agree that how many bitcoins one holds seems to be a better approach to weighting the votes (from how much hashing power one can control), but I am afraid that it goes against the bitcoin's security design, so it might not work well enough. But maybe I just don't see the whole picture yet, so if you don't mind drawing it a bit further..

My full reply: http://sourceforge.net/mailarchive/message.php?msg_id=31037850

Something to keep in mind about the proposal is it is very carefully constructed to ensure that miners can't sway the vote. Remember that miners can always decide to decrease the blocksize by just mining small blocks; it's increasing the blocksize that is the issue.

The proposal is very clear that miners can only increase the blocksize by proving to the community that there exist votes to increase it which is why simply doing nothing in the proposal is you voting to keep the status quo. If that weren't the case miners could simply block votes they don't like and force whatever increase they wanted.

If just a few such votes exist representing just a small portion of the Bitcoins in circulation, the maximum blocksize will increase by a very small amount, if a solid consensus exists, the blocksize can increase by as much as the community wants.

Finally the proposal is careful to take "lost coins" into account by making coins that haven't moved in more than 1 year have an increasingly smaller weight in the vote.

It's a solid proposal and a democratic way of making a very tough decision.

(also posted to the -dev email list)

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