Proposal: We should vote on the blocksize limit with proof-of-stake voting

[mmeijeri]

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

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.

[1715426570]

1715426570

[amincd]

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)

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.

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.

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.

[jdillon]

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.

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.

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.

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

"Very few"?

My off-the-cuff guess (may be wrong) for a solution was:  if (todays_date > SOME_FUTURE_DATE) { MAX_BLOCK_SIZE *= 2, every 1 years }  [Other devs comment: too fast!]  That might be too fast, but the point is, not feedback based nor directly miner controlled.

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

[jl2012]

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?

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.

[piotr_n]

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.

[amincd]

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

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://bitcointalk.org/index.php?topic=1347.0
 

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.

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

Unfortunately that just isn't possible because miners fundamentally control what votes get into the blockchain at all.

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.

"Very few"?

My off-the-cuff guess (may be wrong) for a solution was:  if (todays_date > SOME_FUTURE_DATE) { MAX_BLOCK_SIZE *= 2, every 1 years }  [Other devs comment: too fast!]  That might be too fast, but the point is, not feedback based nor directly miner controlled.

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

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.

[jdillon]

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.

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.

[n8rwJeTt8TrrLKPa55eU]

Great idea, let the rich decide what to do. It's not like giving rich people MORE power causes problems, or anything... 

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.

[Peter Todd]

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.

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.

[jl2012]

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

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

We can and should further strengthen this protection by having all nodes only relay votes for outputs of confirmed transactions, never unconfirmed ones.

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

[piotr_n]

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.

[jl2012]

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 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 of democracy a proper way to go.

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

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.

[piotr_n]

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

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.

[piotr_n]

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.

[Peter Todd]

Bitcoin is hopeless if majority of miners are evil.

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

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.

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.

[piotr_n]

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

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?

[jdillon]

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

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

[piotr_n]

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.

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?

[Peter Todd]

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?

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.

[jdillon]

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.

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