Pages:
Author

Topic: [POLL FINISHED] The block size limit controversy: a proper poll (30 days) - page 3. (Read 4842 times)

hero member
Activity: 501
Merit: 500
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).

Well, I think there are other attributes that give value to Bitcoin. Such as scarcity and fungibility (which are not affected by block size) and liquidity (which is).

High fees make Bitcoin less liquid, and thus, less valuable. And, as a consequence, smaller block size limit does not necessarily mean more real income to miners.

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

This is assuming mining is always primarily bandwith-constrained (as opposed to energy price constrained).

I think mining ops will in any case tend to either grow bigger or die. Economies of scale.
legendary
Activity: 1246
Merit: 1077
Can "No limit" be added?  Thanks.

No it cannot.

Without the limit, Bitcoin network can't function.

There has been no proof of this. A possible system is one where the client limits the download speed for any particular block, but not the actual block size. If there is a tie between two blocks, the smaller one wins. Miners will not intentionally create small blocks because there is no income when the subsidy falls, and they will not intentionally create large blocks because they waste their own bandwidth and the block will never get in.

So far, nobody has refuted this system.
full member
Activity: 168
Merit: 100
In time, the block size may need to change. But there's absolutely no rush.

Let the block size stay at the current size until the limit is hit; then let us run with that for a while. Let us see how easy or hard people find it to work within the limit; let us see what effect it has on transaction fees and confirmation times.

Eventually, a strong consensus might form around an appropriate change. Then, only then, is it worth working out how to implement the change. Equally, we may find that some other solution arises which negates the need for any hard change.

i agree, perhaps a clever solution will make itself known in the meantime

a hack that defies the elegance of Bitcoin would not help my confidence in the developers, to be honest.  i'm cynical by nature so maybe this is out of line, but i wonder if being funded by the btc foundation creates some weird new incentive.  "guys guys, we're worth all these bitcoins, we're doing stuff and stuff"

call me crazy, but an interface to be proud of would be the top priority, not causing drama about protocol changes for problems that might be imaginary

of course, if this idea wasn't even floated by the developers to begin with, i recant.
legendary
Activity: 1470
Merit: 1006
Bringing Legendary Har® to you since 1952
Can "No limit" be added?  Thanks.

No it cannot.

Without the limit, Bitcoin network can't function.
sr. member
Activity: 247
Merit: 250
Can "No limit" be added?  Thanks.
legendary
Activity: 1106
Merit: 1001
Where is the option: /24 ban the two mofos (or one and his socky buddies) that keep posting these stupid useless threads about a non issue.

It isn't a non-issue. It's an issue that will become somewhat important in about 6 months, a bit more important in about a year, and truly critical in about two years. But, as Joel Katz will often say, you don't turn the steering wheel when you're 5 miles away from a bend in the road. You just know the bend is there, and you make a plan for when you'll turn the wheel.
legendary
Activity: 1512
Merit: 1036
Where is the option: /24 ban the two mofos (or one and his socky buddies) that keep posting these stupid useless threads about a non issue.
full member
Activity: 166
Merit: 101
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.

Strongly agree.  This means stating the invariant you want to keep the equilibrium around.  My favourite invariant is "long term, the amount paid by transactors to those securing the transaction log should work out out at 3% of the total monetary base per annum".  This boils down to: a recent mean of over 12 BTC tx fee per block raises the max size a little; a recent mean of under 12 BTC tx fee per block lowers the max size a little (with 1 MB remaining a floor).  This equates to a mean of 0.0029 BTC per transaction to get off the 1 MB floor.  It seems pretty scalable while still being self-regulating.
legendary
Activity: 938
Merit: 1001
bitcoin - the aerogel of money
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.

Technically, it's feasible. This is how it could be done: Create a non-standard "vote transaction" that sends 0 bitcoins and stores a vote in the script.  Every X blocks, the protocol mandates that the block size changes according to all vote transactions since the last change, ignoring duplicates.  Votes are weighed according to how many bitcoins are stored in the vote transactions' inputs.

If the majority of users, including large bitcoin businesses, use a hard-forked client with above rules, the miners would be forced to accept them.  Yes, what is included in a block is up to miners, but whether that block gets rejected by the users' clients is NOT up to them.  So politically, it's feasible too.
legendary
Activity: 1232
Merit: 1001
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?

Well not necessarily. Pools will always have to run full nodes. The decision which way to support could be made with on which pool you mine.

Also a calibration could be applied to the max Blocksize.

Like:

All 2048 Blocks, new max. Blocksize.

Target: Average Blocksize of the largest 1024 Blocks = 80% of max Blocksize. Max Blocksize increases or decreases by max 20%.

Therefore over 50% of all miners would need to produce constant Blocks at least at 80% the max Blocksize for it to increase. Ensuring Transaction space is always scarce and not enough for all transactions during peak times.

This is only a quick Idea. Please don't pick on the details.
legendary
Activity: 1050
Merit: 1002
Any polls should also be re-done at a later date since opinions can change. It can take time for people to digest information.
legendary
Activity: 1232
Merit: 1001
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.
legendary
Activity: 1106
Merit: 1001
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).

Quote
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.
legendary
Activity: 1064
Merit: 1001
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).

Quote
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.
hero member
Activity: 501
Merit: 500
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.
legendary
Activity: 1064
Merit: 1001
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.
legendary
Activity: 938
Merit: 1001
bitcoin - the aerogel of money
I support misterbigg's idea of miner-voted limit changes [...]

Why miner-voted as opposed to stakeholder-voted?
hero member
Activity: 501
Merit: 500
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?)
legendary
Activity: 2128
Merit: 1073
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.
legendary
Activity: 938
Merit: 1001
bitcoin - the aerogel of money
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.
Pages:
Jump to: