[POLL FINISHED] The block size limit controversy: a proper poll (30 days)

[ShadowOfHarbringer]

Because the previous poll sucked hard, i made a new, proper one.

Choose wisely, your future may depend on it.

[1715027100]

1715027100

[1715027100]

1715027100

[ShadowOfHarbringer]

2012-03-11:
It seems that nobody is voting anymore, so it makes sense to lock the poll.
I hope everybody find the results satisfying, I for sure do.

[Akka]

Self adjusting algorithm like difficult. We don't know what the future brings (hardware and demand wise) changing it again might be even harder, so a solution that possibly fixed this once and for all.

[cypherdoc]

what do you mean?  change it right now or eventually long term if it becomes clear we need to?

[Jutarul]

Self adjusting algorithm like difficult. We don't know what the future brings (hardware and demand wise) changing it again might be even harder, so a solution that possibly fixed this once and for all.

Difficulty adjustment is to make hashing competitive. If you allow for bandwidth adjustment you make that competitive as well. All adjustment methods are exploitable. Do you want people to compete on bandwidth?

[ShadowOfHarbringer]

Self adjusting algorithm like difficult. We don't know what the future brings (hardware and demand wise) changing it again might be even harder, so a solution that possibly fixed this once and for all.

+1

[Timo Y]

If it's dynamic, it must depend on total transaction fees paid, or difficulty, or both. 

It must not depend on number of transactions or size of transactions.

[Jutarul]

If it's dynamic, it must depend on total transaction fees paid, or difficulty, or both. 

It must not depend on number of transactions or size of transactions.

transaction fees paid and difficulty based is exploitable by large mining cartels. You don't want cartels right?

[SimonL]

I've actually suggested (in two different threads already) a very rough metric that could be used in conjunction with difficulty to regulate the max block size based on how efficiently blocks propagate across the network. It is hardly the best metric, but I think the tying in with difficulty is feasible.

https://bitcointalk.org/index.php?topic=144895.msg1538386#msg1538386

[mccorvic]

It's a tough call for sure and it will be nigh impossible to really know if we've struck the right balance or not until it's to late.  It's very clear that we need to have more transactions per second possible than we have right now if we want BTC to become what we all want it to become.  The concerns about giving too much power to only those with infinite storage space/super computers are legitimate as well.

[Timo Y]

If it's dynamic, it must depend on total transaction fees paid, or difficulty, or both.  

It must not depend on number of transactions or size of transactions.

transaction fees paid and difficulty based is exploitable by large mining cartels. You don't want cartels right?

Ideally there should be something like a storage fee in addition to the transaction fee. The storage fee should not go to the miners.  Ideally, it should be paid out to people who donate bandwidth, CPU and hard disk space by running a full node.  However this might not be practicable since there is no simple, objective proof-of-propagation and proof-of-storage like there is proof-of-work.  Alternatively, the storage fee could be paid to the stakeholders according to proof-of-stake, which is objective. For this to work, the only important thing is that the fee doesn't go to the miners.

This would require major changes to the protocol, so it's not going to happen fast.  In the short and medium term, we need a stopgap solution.

[2112]

Please update the poll to include one more option:

x) redefine "block" to mean only header, Merkle tree & coninbase transaction. All normal transactions need to be propagated before the block in which they are included.

This proposal has been floating around at least since the Microsoft's "red balloons" paper. Currently "block" is pretty much an artefact of the weak architecture of the original implementation. The various "UTXO" proposals are in effect proposing the same change, just a different implementation of the transaction storage.

Thanks.

Edit1: Changed "fix" to "update". I forgot that in English "fix" could mean "conspire to preselect the winner".

Edit2: This "block size" discussion should really decouple the "bandwidth & time to verify" from the "storage size" discussion. They aren't really coupled, the coupling is just an artefact of implementation.

[mp420]

I support misterbigg's idea of miner-voted limit changes, calculated at each difficulty adjustment, preferably with the options "decrease" and "disregard my vote" in addition to "increase" and "keep". I chose "other" since this is a specific proposal.

If this is somehow less feasible than other options, I need someone to explain me why it's so. Maybe 90% is too high a threshold though. With "decrease" option available, a simple majority might be sufficient. Although this would make the fork less smooth, or require an additional forking condition (90% for the first change and simple majority for the rest?)

[Timo Y]

I support misterbigg's idea of miner-voted limit changes [...]

Why miner-voted as opposed to stakeholder-voted?

[misterbigg]

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:

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:

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:

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:

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.

[mp420]

I support misterbigg's idea of miner-voted limit changes [...]

Why miner-voted as opposed to stakeholder-voted?

Because "stakeholder-voted" is not technically or politically feasible. After all, what is included in a block is up to miners. Also, I think in the long term what's good for miners is good for the network, and good for anyone with Bitcoins.

When the hard limit starts to constrain Bitcoin's usefulness, this will tend to cause a decrease in Bitcoin's value, and thus, a decrease in miners' real profit. So, eventually, miners are going to want to increase the limit.

[misterbigg]

When the hard limit starts to constrain Bitcoin's usefulness

The hard limit on block size is what gives Bitcoin its most important attribute: The blockchain with the largest amount of hashing power. Increasing the block size reduces total hashing power (because it drives fees down).

this will tend to cause a decrease in Bitcoin's value, and thus, a decrease in miners' real profit. So, eventually, miners are going to want to increase the limit.

Wrong on all counts. Its in the miners' best interests to NOT raise the limit since the limit is what drives fees. The only miners who benefit from an increase in the block size are the ones with the most bandwidth, since a limit increase will kill off the smallest competitors.

[Piper67]

When the hard limit starts to constrain Bitcoin's usefulness

The hard limit on block size is what gives Bitcoin its most important attribute: The blockchain with the largest amount of hashing power. Increasing the block size reduces total hashing power (because it drives fees down).

this will tend to cause a decrease in Bitcoin's value, and thus, a decrease in miners' real profit. So, eventually, miners are going to want to increase the limit.

Wrong on all counts. Its in the miners' best interests to NOT raise the limit since the limit is what drives fees. The only miners who benefit from an increase in the block size are the ones with the most bandwidth, since a limit increase will kill off the smallest competitors.

Yeah, well, it is also in miners' best interest to maintain the reward at 50. Or to keep the difficulty at 1000. But they can't have that, can they? Why? Because that's not how it works.

If the block size can adapt variably and in a self-regulating way, similar to how difficulty works, then it will just be part of how the business of bitcoin is done. It will also have a certain elegance and symmetry, which is very appealing.

[Akka]

Wrong on all counts. Its in the miners' best interests to NOT raise the limit since the limit is what drives fees.

That's only true to a certain point. Every BTC User has a point where he isn't willing to pay even more fees to get a transaction processed. Once this point is reached it will be more providable to allow more transactions.

Also mining will at some point (very soon) become a zero sum game. As long as mining is profitable additional Hash power will be added until it equals out. The total amount of money made with each Block only specifies how much money will be spend to secure the network.

That's just how a free marked works.

[acoindr]

Any polls should also be re-done at a later date since opinions can change. It can take time for people to digest information.