Quote from: Peter R on August 14, 2015, 04:31:13 PM

Quote from: smoothie on August 14, 2015, 07:46:49 AM

Quote from: Peter R on August 13, 2015, 03:56:30 PM

Quote from: cypherdoc on August 13, 2015, 03:34:02 PM

Quote from: Peter R on August 13, 2015, 03:17:41 PM

Quote from: Zangelbert Bingledack on August 13, 2015, 03:02:26 PM

At this point I'd say just find a way to put the forks on the market and let's arbitrage it out. I will submit if a fork cannot gain the market cap advantage, and I suspect the small-blockers will likewise if Core loses it. Money talks.

I had a strange idea recently: what if we don't even bother with BIP100, BIP101, etc., or trying to come to "consensus" in some formal way. What if, instead, we just make it very easy for node operators to adjust their block size limit. Imagine a drop down menu where you can select "1 MB, 2 MB, 4 MB, 8 MB, ." What would happen?

Personally, I'd just select some big block size limit, like 32 MB. This way, I'd be guaranteed to follow the longest proof of work chain, regardless of what the effective block size limit becomes. I'd expect many people to do the same thing. Eventually, it becomes obvious that the economic majority is supporting a larger limit, and a brave miner publishes a block that is 1.1 MB is size. We all witness that indeed that block got included into the longest proof of work chain, and then suddenly all miners are confident producing 1.1 MB blocks. Thus, the effective block size limit slowly creeps upwards, as this process is repeated over and over as demand for block space grows.

TL/DR: maybe we don't need a strict definition for the max block size limit.

that's just a re-write of what i've been advocating; lift the limit entirely.

but yeah, your idea is great b/c it would give full node operators a sense of being in charge via a pull down menu. i like it.

don't forget that mining pools are just huge hashing overlays of full nodes which they operate and could use to do the same type of voting.

Yes, you have been essentially advocating the same thing.

We could take this idea further: in addition to the drop-down menu where node operators and miners select the max block size they'll accept, we could add two new features to improve communication of their decisions:

1. The max block size selected by a node would be written into the header of any blocks the node mines.

2. The P2P protocol would be extended so that nodes could poll other nodes to find out their block size limit.

This would be a highly decentralized way of coming to consensus in a very flexible and dynamic manner.

It would be a recognition that the block size limit is not part of the consensus layer, but rather part of the transport layer, as sickpig suggested:

Quote from: sickpig on August 13, 2015, 06:26:05 AM

you know what I can't stop thinking that the max block size is a transport layer constraint that have crept in consensus layer.

The network would dynamically determine the max block size as the network evolves by expressing the size of the blocks they will accept with the drop-down menu on their client.

Sois this a good idea? If there are no obvious "gotchas" then perhaps we should write up a BIP.

So would this essentially be a voting mechanism on current block size (of course it can change dynamically on the next block)?

What % would determine that a block size has "consensus"?

Interesting idea...

I would look at this as a signalling mechanism rather than as a voting mechanism.

Here's the difference:

In BIP100, the result of voting affects the behaviour of the software in a pre-defined way.

In this new proposal, the signalling doesn't have any effect on the software. Instead, it is used as a way to communicate the maximum block size the network will accept to people (albeit in a fuzzy way).

It is sort of like NewLiberty's idea of a feedback-loop based block size limit, but the feedback is achieved by the actions of people rather than by the behaviour of code.

the more you talk about this the more i like it, Peter.