Quote from: Timo Y on February 21, 2013, 05:46:32 PM

Why miner-voted as opposed to stakeholder-voted?

Two reasons. First, it is very easy to modify Bitcoin to allow miners to vote (since they produce the blocks). Allowing stake holders to vote is much more difficult. Second, it is the miners that are the most affected by the change in the block size. Increasing the block size results in less transaction fees. It also makes mining less profitable for nodes with the least amount of bandwidth. Some miners will become unable to participate. That's why the miners should be the ones to vote.

Here is my proposal for adjusting the block size:

Quote from: misterbigg on February 21, 2013, 07:15:12 AM

1) A boolean flag is added to each block. The flag represents the block solver's yes or no vote for increasing the block size. The independent miner or mining pool sets this flag according to their preference for an increase.

2) Every time the difficulty is adjusted, the number of yes votes is counted from the last adjustment. If the number of yes votes is greater than 90%, then the block size is increased by 1%. Both percentages are baked-in constants, requiring a hard fork to change.

If this was implemented, most likely the vote would be an automated function of bandwidth measurements performed by mining software. A miner would vote yes if their time to transfer a block is below some threshold.

Here's Nagato's explanation of how increasing the block limit also increases the minimum bandwidth requirements:

Quote from: Nagato on February 21, 2013, 07:03:11 AM

If we want to cap the time of downloading overhead the latest block to say 1%, we need to be able to download the MAX_BLOCKSIZE within 6 seconds on average so that we can spend 99% time hashing.

At 1MB, you would need a ~1.7Mbps connection to keep downloading time to 6s.
At 10MB, 17Mbps
At 100MB, 170Mbps

and you start to see why even 100MB block size would render 90% of the world population unable to participate in mining.
Even at 10MB, it requires investing in a relatively high speed connection.

Here are my proposed guidelines for making block size adjustments:

Quote from: misterbigg on February 21, 2013, 12:22:48 AM

Any change in maximum block size should
1) React to scarcity, to preserve fees
2) Not force out small miners

Here is my answer to Gavin's question about predicting the soft limit's future effects:

Quote from: misterbigg on February 20, 2013, 08:09:15 PM

Quote from: Gavin Andresen on February 20, 2013, 07:38:16 PM

we should see what happens as we run into the soft blocksize limits...what do you predict will happen?

In this order:

1. Most blocks are at or near the 250 kilobyte soft limit.
2. The memory pool of transactions grows due to insufficient space in blocks.
3. Users notice trend of transactions taking longer to confirm, or not confirming at all.
4. Fees increase as users pay more to improve confirmation times.
5. Miners (or mining pools) modify code to select transactions with the highest fees per kilobyte to fit into blocks. They remote the 250 kilobyte soft limit. Some miners disallow free transactions entirely.
6. Transactions clear much more quickly now, but fees decrease.
7. Blocks increase in size until they are at or near the one megabyte hard limit.
8. Fees start increasing. Free transactions rarely confirm at all now.
9. Small transactions are eliminated since they are not economically feasible. SatoshiDice increases betting minimums along with fees. The volume of SatoshiDice transactions decrease.
10. Users at the margins of transaction profitability with respect to fees are pushed off the network.
11. Many people, most non-technical, clamor for the block size limit to be lifted.
12. Fees reach an equilibrium where they remain stable.
13. Spurred by the profitability of Bitcoin transactions, alternate chains appear to capture the users that Bitcoin lost.
14. Pleased with their profitability, miners refuse to accept any hard fork to block size.