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

Ah a man after my own heart. I couldn't agree more.

You should check out the thread on netcoin which is an ambitious plan to implement some of these principles. I'm pretty sure this is going to be an iterative process (e.g.. think of ppcoin as the first several iterations).

Proof-of-stake voting is a superb idea.

Its potential is much wider than resolving the specific blocksize limit question. However, I don't believe it is right for Bitcoin. Bitcoin can't adopt major changes easily, if at all.

An altcoin supporting proof-of-stake voting could allow continuous voting on the block reward(inflation rate), transaction fee, awarding bounties, hashing algorithm parameters, etc.

The Bitcoin model has been to have a genius choose all these parameters correctly 5 years ago. That's worked well, but it is inflexible. A proof-of-stake voting model would trust the owners of a currency to modify the parameters as the currency and environment evolved. I trust the owners of a currency to vote in a way that strengthens the currency they own. Owner's interests are perfectly aligned with the long-term success of a currency. I'd like to see an altcoin where the owners decide monetary policy through proof-of-stake voting.

Yeah, gmaxwell's comments yesterday were extremely helpful. 
But it's not the first time I saw him talking bullshit, so I'm used to this.

@jdillon, you want to use self-moderated threads so nobody could tell you again that your idea is stupid?
way to go, man - that's how smart people solve problems

I need to get better at not touching that "show/hide" option... But on IRC yesterday most of the developers put piotr_n on ignore for being an idiot who wouldn't listen to people showing why his idea was stupid and wasting everyones' time instead: http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/06/28#l7875194 gmaxwell has the patience of a saint. (or a C++ developer on a slow machine)

Remind me to use the self-moderated threads option more often.


EDIT: I'll also point out how this "one-line-change" DoS attack was something that at least one of the Bitcoin developers knew about but didn't even realize it was an issue: http://sourceforge.net/mailarchive/message.php?msg_id=31074593 Hopefully the other developers were just keeping their mouth shut and immediately understood how serious that issue was, but obviously it took a bit of insight on Peter's part to realize that the problem existed.

Heck, here's a Bitcoin for your efforts. Thank you!


-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.11 (GNU/Linux)

hQEMA8xUMVQPvvGFAQf/frPPA2CHPDlMz9R28K05T3/wVmGhQ54v803OH8+SImg+
RQ8dGqh5H8Tgar8cuKE8jhikr5bg6NBf369F4h1L4Ir1lnplY2wDJj4tRr97Ea8b
4ADm91Fr0CWT03pa9XIp4LsgIC1oc3l2PUXxCQ/icVUnZk0jhSyp4ZnR0MYsRGqi
GuoVGHP765Xai7I56nLIO4E6LFqnvj5zIGgKYjc4o9ujmOs73gph5eGWEdna3rOG
GKkHrajshLviRgKGa99uG2RxtFltE8BcFkW1D7xweV8TLLH6jAGhIG2XrPol+bLc
RoQQZr3zR1w0ORdXL6GkIerxw4MNBI5hKRm4w93WRIUBDAO4Pc5vOCVNqAEIALeU
FJZZ8BUtgiQ4mMIUrEFXOD5h1BqqIsavUosOR3mVJNWtlnHuasYGn2LvFqJw1SzC
7uB1bGk7xyVNAOGECFDu6r5T9Diur6pr+CSxbRjh19dqNi+noKiD3V1z6yk6USf/
rqlfm13k7Tat6T4b1Kp/4JC8ofarL3ogyCzF3MXFbdnCBuqndklqDakb66iQv4SE
BI7rwWwwtaeI83uUBTQpJkH0wL1boHfjKtpuh4jOETOQ8zKJxWOFm4BJl6TzHmYf
/hnm5Wc7JIsV1GMqQYwNreJ+6RRBpPV5mayomzF9n01yOwV/rKY7bDBAS0LU5LEV
DcSuqJ6FRbihiFibS0HSwN8BhY0LpbmFCGH9NrHYHQW7WQ8tZVbMGvVSEoOwUdEZ
JUV7Uj3nLIGnmZ9vfePcu7zxCwUbrMk3eX1huaBbeCwdv/zkHQtzMTTySOAhbgxx
LcCZuUTUXDdO8oFCJD/3PUlBJgxniVkSGcsbMUo2ev+Lr541iWGmd+J6FlZvgwsz
bE0PkOtIyttYvMBHfqUJ9DN7xLLKu/gJnzcs0UrLauXrbFvV3NsBL6LcuZ62zp4n
Sj+iy+9LOnr2tOjv7uVyujut4moCHteFcD7VIBjr0Lxuzxf/scdPSe73Y9Rgs4yX
n8e+RjgOV6k4hjMKeyQRSutHuUHKY0OTtdEW7dbfnUpFR+n8dDqnS0uueMrCNakM
b0xxdHEZSticRzuv7mY8FVJ2AIMFaIlrGInorYbUBtqiAnkcfCD+LI0Vqz7fX8RP
8s7EK584hzzKvFgIYUQ5h4sNgo19ryvnNoeEJh73z3Bho5e6+nVdyW0M8U8hreio
xFHANgf+s46k2vmj9cVl1sH8tW5NOxTfQa+POmRAnIunLCfR9IDJUWCfiJBeYXJI
=6qYH
-----END PGP MESSAGE-----

That's exactly what I am talking about.

A guy who fixed a bug in the official bitcoin client, by adding one line of code: a hero who saved the network from an extremely dangerous DoS attack.

A guy who dared to suggest that we should extend the net protocol to be able to prevent similar attacks in a future: a troll /ignore

You guys are just pathetic.

Thansk! Waiting however long you feel is required is fine by me.

Ah, that's who you are. Yeah /ignore


jdillon: I'll do a write-up in a week or so if you are interested, but waiting a bit longer isn't a bad idea; the network as a whole is safe right now but there are still a lot of non-upgraded nodes out there.

What? He saved the network? That's the best joke I've heard for days..

First of all, the DoS attack was not on the network, but on a buggy official client, which I don't even use myself, so I couldn't care less.
Moreover, yesterday on IRC I even proposed a simple improvement that would solve this kind of problems once and for all (fetching data length, along with the hash), but nobody did care about it, including the guy, who among others was extremely impolite to me, so I have just adopted myself to his standards.

Now you get it?

The guy who last week saved the Bitcoin network from an extremely serious DoS attack that could have easily taken down a large fraction of the network  goes to the trouble of writing an intelligent and detailed response and you obviously don't even read it? Then you go off on conspiracy crap? Troll.

/ignore


Peter: write up what exactly you did there, I'd love to hear the full story. I didn't realize you had written that patch as the main network was being attacked! I guess it would have had the effect of inoculating the whole network because the truncated messages would propagate faster than the non-truncated ones, clever!

So what?
Rich people, or exchange owners, can also easily "peer with each other".
That's not an argument - I'm all for people peering witch each other.

But I'm still waiting for the answer to my question: what is your business in promoting bitcoin banks to rule the protocol?

The design of Bitcoin only requires a majority of miners to be economically rational for Bitcoin to work correctly; good or evil has nothing to do with it. It's easy to see how if a majority of miners think that it is economically advantageous for them to mine large blocks they have every reason to do so and every reason to do "evil" things like block votes against a blocksize increase. (after all, they're just "protecting" Bitcoin from those who want to "hold it back")



Unfortunately you are quite wrong there. Pools can easily peer with each other with dedicated connections on fast servers to ensure that blocks propagate quickly to other pools and we can expect more of this in the future; the incentives to produce small blocks due to propagation delays and orphans are greatly diminished by peering because your block will reliably get to the majority of hashing power fast, the "little-guys" with the most decentralized hashing power be damned.

FWIW the real reason why pools have mostly switched to a 250KB limit seems to be just a change in the block creation code that makes the 250KB default limit a hard limit, rather than the previous behavior where the hard limit was 500KB and it took transactions with increasingly higher fees to fill up that space. If anything it just shows how little pool operators care about transaction fees right now in favor of the still very high inflation subsidy.

Interestingly the recent DoS attack against Bitcoin - caused by how Bitcoin was allowing messages up to 32MiB in size with no anti-DoS limits - gave me a unique opportunity to observe the speed at which extremely large messages propagated across the network, not unlike extremely large blocks. While successive waves of the attack hit my Amazon EC2 hosted nodes very quickly - seconds - due to their high bandwidth it took multiple minutes for those same messages to even begin to appear at less well connected nodes, such as at my apartment, and especially any node connected via Tor. It would have been nice to actually run some experiments, but unfortunately I was too busy trying to stop the attack and the patch that I wrote which fixed the issue had the useful side-effect of "innoculating" even unpatched nodes to the attack. Oh well.

One more comment, on lifting the max block size, which I myself was bitching about.
Today I am tending to say that I was wrong - it won't matter.
I see it now that most miming pools keep the limit at 250KB and even if you remove the hardcoded 1MB from the client, they will still keep their soft limits at whatever level they want - and it will be rather lower than higher.
Anyone who decides to mine bigger blocks is betting against himself, because bigger blocks need more time to propagate over the net, thus naturally having a bigger chance to get orphaned. Measure a difference between propagating 250KB vs 25MB block and you will not think twice of which one your mining pool prefers.

This is a brilliantly designed "ecosystem" that is regulating itself - therefore, seeing it at work, I am against any additional regulations.

Sorry, I wasn't talking to you.
It was more of a general comment, because I see it all the time (in other threads, but also outside the forum) that people are complaining about, or just using a term: "evil miners".
There is no such thing!

IMHO, miners are the least who would want this currency to not succeed. And people trying to overthrow the designed "bitcoin government", because they believe they found a more fair solution for the democracy, or whatever - it's just silly, not to use again the wold "stupid". They either don't understand what they are talking about (meaning: they don't know shit about how bitcoin works) - or they are expecting a miracle... I don't see a third option.

Miners are the government of this currency: like it or not, it is the fact and you cannot do anything about it. If they decide to increase or decrease a block size, or whatever else, they can just do it and no developer, nor any other self proclaimed genius, will be able to stop them - face it! If bitcoin users didn't follow any miners' decision - as I said: that would be their suicide.

Moreover "evil" is a religious term, so please if you are people of science, stop using it and start thinking in terms of what is technically possible, instead of what you think you should do in order to go to heaven.

Bitcoin is hopeless if majority of miners are evil. I don't think this will happen. I am just responding to jdillon's accusation:

I'm honestly tired reading all these silly accusations about how miners are evil and how we should resist against them.
It's just so stupid that I cannot even quantify the level of its stupidity.

First of all, miners are not evil - they are the power of the network by design and they should do their job, part of which being: decision making about the protocol.
And second, even if you wanted to, you cannot resist their power, because they are the power of the network by design.

You don't like the miners' ruling the bitcoin - invent your own virtual currency, one that has it designed otherwise.
In the virtual currency invented by Satoshi in 2009, miners are supposed to rule and so they do rule - you can't change it, it's impossible.
And if you don't like this idea, then obviously you have not yet found a digital currency that is suitable enough for you.

Myself, I am going to stick to the miners' ruled currency, because I do find this idea as a proper way to go.

As you assume that miners are evil enough to reject votes they don't like, certainly they are willing to do so.



This doesn't help at all. Evil miners will require people send the votes to them directly, or publish them on a public forum.

One of the more interesting aspects of John Dillon's proposal is that it could give many of those large Bitcoin holders a reason to move their coins so that the txouts will be fresher than 1 year old and can participate in the vote fully; seeing some really early coins vote would be fascinating.

It's almost certain that Satoshi is the richest Bitcoin holder, as well as other early adopters.  By definition these "rich" people are likely to be quite insightful and ideologically pure: they recognized Bitcoin's value and persevered when no one else was interested and the product was going through difficult times.  Personally, I'd trust him and other early adopters to make wiser decisions than any persons (or hashing power) showing up since this year's media explosion.

Rejecting transactions that are not accompanied by votes would be logisticly difficult. When you send a transaction generally only one of the outputs will be owned by you, often none of the outputs at all, so unless miners are willing to make it impossible for you to send funds to someone who is off-line or simply does not wish to vote they will be unable to coerce votes in that way. We can and should further strengthen this protection by having all nodes only relay votes for outputs of confirmed transactions, never unconfirmed ones.

I don't know how you're defining "random" here. Satoshi wrote that he expected blocks with 3,000 transactions/second in them if Bitcoin became successful, even before he released the first client.

When he instated the 1 MB limit, it was unambiguously created as a temporary measure. When Satoshi was active on the forum, there was discussion on options for replacing it, with a clear implication in all of the participants' comments, including Satoshi's, that the 1 MB cap would eventually be removed if the volume of transaction data approached 1 MB:

https://bitcointalksearch.org/topic/patch-increase-block-size-limit-1347
 

That's somewhat better, given the status quo will be described as 'the 1MB limit will be lifted eventually when there is consensus around a viable replacement'.


That's true. The flip side is that this voting method requires support in all major clients to be useful.

Also with regard to this voting concept in general, whether it treats normal transactions as votes or not, it gives e-wallet operators more power over the votes of those who entrust their bitcoins with them than mining pools have now over the votes of those who point their hashes to them.


That's not referring to voting on a protocol change. That's in reference to a protocol change that allows miners to continuously vote on a dynamic block size limit. There's a big difference between miners voting once to change the protocol, and a protocol change that allows miners to actively control the block size limit through regular voting.

All of the protocol changes so far have been voted on through the mining method, so there doesn't appear to be much opposition to this method.

No, I'm not afraid. I just think this idea does not have a chance to succeed, and will list a few points why.

1) Offline wallets will be holding more and more money, so they won't be able to vote in a "simple, automatic process". IMO few years from now most of the money will be kept in cold wallets. Actually, maybe it is already the case - we don't even know it.

2) Assuming that the block size won't blow up soon and so people will use all kind of bitcoin banks, because of the rising on-chain tx costs, this solution will be just anti-democratic.

3) Buying bitcoins is much easier that buying (and deploying) mining equipment. Moreover number of bitcoins (unlike hashing h/w) is limited, so if you have enough money you can just buy half of the coins and become the ever lasting bitcoin dictator.

4) The miners will still be able to overrule whatever the proof-of-stake voters decided and I don't see any solution to prevent it. Client nodes need miners more than miners need client nodes and if the clients decide to go into a forked branch of their choice, but leaving the miners at the other branch - it would be their suicide.

This also applies to your proposal. 51% of miners can reject all "status quo votes" and blocks containing status quo votes. After one year, these status quo votes will get lower and lower weight and eventually the blocksize will be increased.

There was no plan. All we have is some random comments from Satoshi suggesting a possibility.

Note how the proposal is careful to note that not voting is not a vote for a 1MB limit, but a vote for the status quo. In the future that status quo will probably not be 1MB, so your default vote will be for a different, probably higher, number.

Adding the voting feature is simple and easy. There just aren't that many clients out there so I really do not see the issue there.


Unfortunately that just isn't possible because miners fundamentally control what votes get into the blockchain at all. What you are proposing allows miners who wish to raise the blocksize to rig the vote by ignoring transactions voting against an increase, and it just takes a 50% majority of miners to do that. Not exactly a compelling majority of Bitcoin users is it?

Anyway, the point of my proposal is we know that miners can effectively reduce the blocksize by just not creating large blocks and not building upon the work of other miners, but we can coerce them into creating larger blocks by offering them fees. But what we can't do is limit how large blocks can become, which is the limiting factor for how easy it is for someone to become a true miner themselves. (not just someone working on behalf of a miner) Controlling the upper limit to something the whole community can agree on is what is important because we all benefit from a Bitcoin where the resources required to operate a full node are acceptable, for some value of acceptable.


"Very few"?

-http://garzikrants.blogspot.de/2013_02_01_archive.html (emphasis his, not mine)

That's Jeff Garzik, a highly respected core developer. Gregory Maxwell and IIRC Pieter Wuille shared those same concerns on IRC. Gavin is the odd man out in the core-dev team to think that leaving the decision up to miners is OK.

The problem with your proposal is that it counts anyone creating transactions on clients that don't have this voting feature as voting for the permanent 1 MB block size limit, which is a very controversial departure for the original plan to eventually replace what was meant to be a temporary 1 MB block size limit with another solution that allows high bandwidth nodes.

If all votes require a special transaction type, rather than counting normal transactions as a vote for a particular option, that would be more reasonable.


Very few people are complaining about the vote by mining method. Large pool owners aren't the ones making the votes, as miners can point their hashes to any pool they want.

In any case, I don't think proof-of-stake voting is inherently bad. It's just that the implementation has to be unbiased to the options.

Sure, and I think it's possible we'll see a combination of a number of mechanisms: ASIC-unfriendly hashing functions, alternative proof of work schemes, proof of stake, proof of burn.

The collective wisdom of individual ignorance.

The thing is we already have one voting mechanism, mining. But that is a mechanism where the right to vote is dependent on your access to highly specialized hardware and in practice has been held in the hands of a very few in Bitcoin's history due to the natural incentives for miners to mine at large pools.

By adding proof-of-stake voting you counter-balance that vote with one where access is determined by a resource that all Bitcoin users have, Bitcoins themselves. Obviously we can't force miners to make larger blocks, but we can make it clear what maximum size we will accept, so the two voting processes go hand-in-hand.

As you say, it's a dispute resolution mechanism.

Voting has its own risks. After all, democracy is the original 51% attack, as Erik Voorhees puts it so nicely. Before you know it, we might have Bitcoin taxes. Still, it's possible some less drastic dispute resolution mechanism than forking Bitcoin or switching to a rival currency will emerge. It's certainly interesting to speculate about the possibilities.

Voting is a simple, automatic process. Your wallet would have a pop-up when you configure it asking what you want your vote to be and giving a bit of education on what the option actually means. After that the process can happen entirely automatically. Submitting a vote doesn't cost you anything in time or money and unlike leaving the decision 100% up to miners it ensures that entities like the Winklevoss twins with the connections required to get access to mining hardware on a level playing field, BTC to BTC, as you are. (Mike Hearn for example has said he expects for mining hardware to be highly regulated in the future)

Frankly what are you guys worried about? Losing? If Bitcoin users really want a large blocksize they'll vote, and it'll be easy to convince them to vote if they see fees going up and want fees to be lower. Voting is an excellent answer to those suggesting that politically powerful members of the community are pulling strings by taking the issue out of their hands entirely.

Gavin Andresen has said repeatedly that he doesn't want to be "the guy" setting the blocksize. Others, including myself, have said repeatedly we don't want the tiny set of large pool owners setting the blocksize. With voting both parties can be made happy.

Yeah, and I am with you here, so after all I do not quite support the idea of moving the power from he miners to the coin holders.

If you guys, whoever you are, but who are smart enough to make whitepapers that I can hardly read, want to do something really useful, I'd modestly suggest you moving the focus from empowering bitcoin banks to empowering individual miners, from behind the pools' interface.

Could you think of any voting system where a miner can vote individually, using his small 300Mh/s miner?
Something that would still allow him to cast a vote of his choice, yet without a need for him to give up his mining pool?
Why do we even want to involve mining pools into politics? I am sure none of them wants that - they are not like the elite of bitcoin
But anyway, it's the people who mine that should decide - just let them to do it, but without forcing mining pools to choose a camp (which can likely start a war of giants).
That should be doable.

If people think we should change the decision-making process to this, maybe they should start by getting a 51% vote by the method they propose, for the method they propose. I'm sure somebody can come up with a way to mark transactions as being in favour of this change without changing the protocol.

It shouldn't be very hard to get that 51%, since the people who will be most empowered by it will obviously want to support it. Unless it turns out that this is not in fact a serious proposal for making decisions, but instead a ludicrously transparent scheme to create a hurdle against any change, including one that has always been planned, by adding an extra step that has to be cleared in addition to the mining consensus, while counting the vast majority of people who aren't following the particular argument in question as "no" votes...

I guess I should have said "overwhelming approval by those actually doing the work".  Quite frankly, I don't give a fuck what the Winkelvoss twins want, or what Gox wants, or any other entities with big wallets.  The guys paying fees right now and the guys mining blocks right now are what really matter, in my view.  Hashes and fees are consumed.  Stake is not.

I guess our disagreement could come down to one side thinking that neutrality and objectivity can be found, while I'm old and cynical, and do not.  I've seen at least a half dozen proposals involving various ways to calculate "stake" in the system.  Some or all of them may be objective or neutral, but the choice of which one to use certainly is not.

If you include nonces or sequence identifiers in the votes, then you are biased against cold storage.  If you do not include such a mechanism, then you've invented a ratchet that only swings in one direction (also not neutral).  Unless I missed something in physics class, then any weighting system to be used will have been invented rather than discovered, which is to say that it will be subjectively chosen.

It goes on and on...  Stake systems seem to have a lot of promise, but don't actually seem to deliver, as far as I can tell.

The status quo should be that the 1 MB block size limit is lifted, as that was the plan when it was first implemented, and there has been no consensus since then to change the plan.

Also, to count txouts without a vote as a vote for a particular choice is to give that choice a massive advantage, as it's a lot more difficult to create new type of transaction than a normal transaction.

For the record, it's John Dillon's system. I had been thinking about the problem myself, and thinking about various commitment schemes, but he was the one that made the critical realization that vote withholding wasn't an issue in the first place because of the asymmetry involved.

In any case, of course the majority of miners can ignore a vote to increase the blocksize, what they can't do is ignore a vote to keep it steady or decrease it. That is quite unlike recent proposals to just remove the limit and let miners decide. You can always encourage miners to mine larger blocks by paying higher fees.


For sure, and those incentives work differently for different miners. Any large pool, or set of large pools with faster network connections between them, will have a much lower orphan rate for a given blocksize than a smaller pool simply because to get an orphan means someone else has to find a block before yours propagates, so more hashing power reduces that risk, and more hashing power makes it cheaper, relatively speaking, to afford to fast machines and fast network connections to speed up propagation and keep that rate down, while increasing the rate for your competitors and forcing them out of business. (remember that one way to get an orphan is when someone else generates a block, but you don't know about it yet, less of an issue now because you can just mine empty or near empty blocks and collect the large inflation subsidy, but that won't be true for much longer)


Yeah, at least proof-of-stake voting can give us a neutral and objective way of deciding if overwhelming approval actually exists in the community rather than just guessing.

Meh.  I was using the loose definition of honest.

I get it that the no-vote position is to leave things alone, I'm just saying that a majority of miners can overrule the stakeholders in your system.  If the stakeholders want an increase, but the miners don't, the miners can just ignore their votes.  And if a majority of miners wants to ignore their votes, they can also ignore blocks from other miners that include them.

Any system that relies on the block chain will necessarily be vulnerable to the 51% problem.

And in this case, the incentives align in funny ways.  It might be economically rational* to restrict blocks to a limit lower than the stakeholders would prefer, because one presumes that the stakeholders want a bigger block to reduce space competition.

I prefer that we make small increases when there exists overwhelming approval.  I'm willing to accept that a majority of miners can give the appearance of overwhelming support because doing so is like deciding to go first in a nuclear war.  No one is sure how it'll end, but we are all pretty sure that it won't be pretty.

* At least for low order effects.  Money is a matter of trust.  Meddling in the chain reduces that trust, to some extent.  How much trust is lost if you meddle a little?  How much if you meddle a lot?  How big is the effect on the economic value of the bitcoin system overall (and thus, on each coin) per unit of trust lost?  What the hell is a unit of trust?  These relationships seem to be nonlinear, and mostly involve things that we can't measure.  If we need people to estimate them accurately to be safe, we should perhaps have ourselves a little sit down thinking time.

That one is really easy actually: a defacto vote is dated from when a given unspent output was created.

Question: If votes are intended to be weighted by inverse age, how are the non-votes intended to be weighted, since you can't really say how long ago a non-vote was cast?

That's what's so clever about this proposal: they can't.

Miners can already make the max blocksize smaller by just mining smaller blocks, so the default vote is "the status quo". What they can't do is raise the limit without consent, because they have to prove that the community wants an increased limit by including their votes.

edit: The assumption in Bitcoin isn't that half the hashing power is honest, it's that no more than half of the hashing power is controlled by one entity, and that at least half the hashing power is economically rational. That's a much weaker assumption than the hashing power being "honest"

They could also reject votes.  Or do far worse things.  Bitcoin is based on the assumption that at least half of the network is honest.  Most of it falls apart if that assumption is violated.

That's not true; you need 51% of the network to execute the veto because a majority can simply ignore blocks that don't use the full blocksize and thus trigger that rule. If this becomes a "us against the holdout miners destroying Bitcoin for the other miners" that's exactly what will happen.

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