Quote from: cypherdoc on August 13, 2015, 09:41:21 PM

Quote from: notme on August 13, 2015, 09:33:07 PM

Quote from: Peter R on August 13, 2015, 06:36:52 PM

Quote from: notme on August 13, 2015, 05:02:43 PM

What about lying? If enough miners claim to support larger blocks but actually don't, then part of the network will waste time producing blocks that won't be built on. IMO, if we want to put the power directly in miners hands it would be better to raise the limit entirely. However, to do so we would need to test the crap out of everything to be reasonably sure that there aren't bugs that are only uncovered by larger blocks like what happened when the soft limit was raised to 1MB.

I don't think it would be a problem. Like Erdogan said, the miners will use the "tip-toe" method of increasing the block size. Worst case, a large block gets orphaned and nobody tries again for a while. But if the larger block doesn't get orphaned, then the network will assume that that size is now supported (thereby setting a new effective upper limit).

Quote from: notme on August 13, 2015, 05:02:43 PM

IMO, if we want to put the power directly in miners hands it would be better to raise the limit entirely.

This doesn't put the power directly in the miners' hands. It keeps the power where it already is: in everybody's hands! It just makes it much easier for people to exercise the power they already possess.

Quote

However, to do so we would need to test the crap out of everything to be reasonably sure that there aren't bugs that are only uncovered by larger blocks like what happened when the soft limit was raised to 1MB.

I disagree. For example, I would not set my node's limit to anything greater than 32 MB until I understood the 33.5 MB message size limitation better. I expect many people would do the same thing. Rational miners won't dare to randomly publish a 100 MB block, because they'd be worried that it would be orphaned.

Furthermore, since miners would likely use the "tip-toe" method, the effective block size limit will grow only in very small increments, helping to reveal any potential limitations before they become problems.

Okay... I'm going to have to agree with that.

But what if, when everyone is voting, an attacker sees that 50% is advertising < X MB and 50% is advertising > X MB with X obviously been larger than any block seen before. By publishing a block of size X + 1 byte, the attacker effectively splits the network in half. If he was previously 25+% of the network, he is now 50% of the two new forks and can either cause further bifurcation or anything else you can do with half the network. Even if the attacker only has small hashpower, it will still cause a hash war between the two forks.

I suppose this could be mitigated if most nodes refuse to build on a block that is larger than what a supermajority votes for.

awemany might have answered your question here:

https://www.reddit.com/r/Bitcoin/comments/3eaxyk/idea_on_bitcoin_mailing_list_blocksize_freely/cu1tzuh

IOW, as a full node operator wanting to stay on the longest chain at all times, set your maximum block size high enough so as not to be exceeded.

Ensuring you are part of the supermajority by looking at votes should give you a safe least upper bound. Ensuring you have the largest size possible is a bit excessive and will raise your costs too much compared to someone who only upgrades when they are coming close to falling out of the supermajority (however they define that).

If miners don't take the supermajority into account, it could be a risk to the network. Including a risk to the nodes with the highest limits as they suddenly become part of a chain with half as much hash power.