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

[Nubarius]

I tend to agree with with dree12 and nevafuse. I think block size limit hasn't played any role whatsoever in Bitcoin's growth until now. As long as block sizes have always been way below the limit, the situation has been essentially the same as if there were no limit. And most miners, as far as I know, currently use software that apply Satoshi's priority rules for minimum transaction fees. I can't see any reason why miners would abandon minimum-fee rules to guard against spammy and DOS minitransactions in the future. Maybe there's something I'm missing, but I find the idea that the protocol must set a limit a very moot one, and I support either removing the limit altogether or making it much higher.

[1715357395]

1715357395

[1715357395]

1715357395

[1715357395]

1715357395

[niko]

Can miners pad the block they mined with useless data to fill it up to the limit?

[Nubarius]

Can miners pad the block they mined with useless data to fill it up to the limit?

No, because they need to calculate a valid hash value for all the data in the block, which would include the useless data plus the reference to a previous block on the chain.

Edit: Well, to phrase it a bit better, it's not that it would be impossible to do that, of course. You could in theory fill the block to the limit with useless data and start incrementing the nonce until a valid hash value is found. But I fail to see how that would be better than actually including transactions.

[niko]

Can miners pad the block they mined with useless data to fill it up to the limit?

No, because they need to calculate a valid hash value for all the data in the block, which would include the useless data plus the reference to a previous block on the chain.

Edit: Well, to phrase it a bit better, it's not that it would be impossible to do that, of course. You could in theory fill the block to the limit with useless data and start incrementing the nonce until a valid hash value is found. But I fail to see how that would be better than actually including transactions.

When there are no enough transactions to max out the block size, padding the block may be an advantage in terms of harming competitors on lower bandwidth connections. 

I am surprised how most of people here seem to have already formed a firm opinion on the issue of block size limit, when obviously the issue is extremely complex, and it involves technological but also economic aspects. Not, economy is not an exact science (if you even call it a science). All in all, it is impossible to predict how a complex system will respond.  Bitcoin is an experiment anyway. We need to decide carefully what the next step will be, but unfortunately there is more rhetorics than dialectics in this forum.

[justusranvier]

Not, economy is not an exact science (if you even call it a science). All in all, it is impossible to predict how a complex system will respond.

That's why it's pointless to try playing central planner.

The correct block size is the size that the miners are willing to mine, and that the nodes are willing to relay. All of the objections which revolve around what miners with faster connections could do to the rest of the network are just variations of the 51% attack, which limiting the block size doesn't solve anyway.

[n8rwJeTt8TrrLKPa55eU]

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 am surprised how most of people here seem to have already formed a firm opinion on the issue of block size limit, when obviously the issue is extremely complex, and it involves technological but also economic aspects. Not, economy is not an exact science (if you even call it a science). All in all, it is impossible to predict how a complex system will respond.  Bitcoin is an experiment anyway. We need to decide carefully what the next step will be, but unfortunately there is more rhetorics than dialectics in this forum.

Glad to see common sense posts advocating an extremely cautious approach.

Waiting first, and then acting based on actual evidence, would seem the best way of avoiding damaging or splitting a $300M (or more) economy.

If/when we get to the point where it's clear we need to go past 1MB, I'd trust Gavin to drive some kind of consensus process around ideas such as misterbigg's, favoring the preservation of a diversified and balanced mining ecosystem with low barriers to entry over unlimited transactional capacity.

[asdf]

The limit is completely pointless. It was put there to stop transaction spam, but this can easily be prevented by simply requiring a fee.

Why is "remove it entirely" not an option?

Ultimately, it's up to the miners, so the debate is moot. If they don't remove it, then Bitcoin was never going to work anyway. Vice versa.

[ShadowOfHarbringer]

I voted "I don't know," but changed my mind after reading - can you edit the poll so we can change our vote (not sure if forum software lets you do that)?

Unfortunately, no.

[Come-from-Beyond]

<sarcasm>
Remove the limit completely, so ppl could spam more useless transactions. Let's make HDD producers to produce disks with 100500 PETABYTES capacity!
</sarcasm>

Less transactions -> Higher fees included coz txs have to compete -> Earlier Bitcoin enters its maturity age

[dree12]

<sarcasm>
Remove the limit completely, so ppl could spam more useless transactions. Let's make HDD producers to produce disks with 100500 PETABYTES capacity!
</sarcasm>

Removing the limit does not imply useless transactions. It simply means the market will decide what is a useless transaction. So long as clients prefer smaller blocks over larger ones, the miners will decide among themselves what a suitable block size is. If it's too high, small-block miners will earn more and blocks will get smaller. If it's too low, large-block miners will earn more and blocks will get larger.

Isn't this what Bitcoin's about? All we need to do is make sure the system cannot be exploited, test it on testnet, and then not need to worry about block sizes ever again.

Appendix:
1. What changes are needed?
A: The "longest chain" code needs to increase the length of shorter blocks and decrease the length of longer ones. Clients also need to set a bandwidth quota so that they download and propagate the best currently-downloaded chain.
2. Couldn't a miner just spam the network with a huge block?
A: No. Like transactions, blocks need "confirmations". If other miners think the block is too big, they will refuse to confirm it and a smaller block will replace it (as they orphan large blocks).
3. Wouldn't blocks be too big?
A: No. Miners will take an unacceptable risk if they mine large blocks, as they are likely to get orphaned. Higher demand and higher transaction fees will make taking that risk more attractive, so block size can scale with usage.
4. Wouldn't miners just mine empty blocks?
A: Eventually, no. This is a concern in the short term, but as soon as transaction fees overtake subsidies empty blocks will no longer be attractive.
5. Wouldn't this allow DOS attacks?
A: Yes. However, DOS attack prevention code can be written to give up downloading a particularly large block if a competing chain is running at not far below network hashrate.
6. Isn't this a hard fork?
A: Done properly, not any more than raising the block limit. The length code only acts as a tiebreaker, which we already have in "first block wins".

[Come-from-Beyond]

<sarcasm>
Everyone will believe you as long as you make statements without proof.
</sarcasm>

Proof? Have u ever heard about common sense? U seem to be kidding if u believe it's possible to prove anything in Bitcoin land.

[niko]

Two thoughts:
1. We should distinguish between "spam" transactions, and any padding miners themselves might decide to add for one reason or another.

2. Trying things out on testnet would not be very informative, due to lack of real-world (dis)incentives and non-existing various groups of stakeholders (merchants, miners, consumers, hoarders...).

[dree12]

...

Proof? Have u ever heard about common sense? U seem to be kidding if u believe it's possible to prove anything in Bitcoin land.

Sorry, that was quite harsh. I removed the statement.

[dree12]

Two thoughts:
1. We should distinguish between "spam" transactions, and any padding miners themselves might decide to add for one reason or another.

2. Trying things out on testnet would not be very informative, due to lack of real-world (dis)incentives and non-existing various groups of stakeholders (merchants, miners, consumers, hoarders...).

1. They work the same way in that the block would be big, and a big block is less likely to earn anything.
2. Removing the limit, in theory, will allow the block limit to float based on demand. This means that even testnet can act as a mini-Bitcoin.

[Mashuri]

<sarcasm>
Remove the limit completely, so ppl could spam more useless transactions. Let's make HDD producers to produce disks with 100500 PETABYTES capacity!
</sarcasm>

Removing the limit does not imply useless transactions. It simply means the market will decide what is a useless transaction. So long as clients prefer smaller blocks over larger ones, the miners will decide among themselves what a suitable block size is. If it's too high, small-block miners will earn more and blocks will get smaller. If it's too low, large-block miners will earn more and blocks will get larger.

Isn't this what Bitcoin's about? All we need to do is make sure the system cannot be exploited, test it on testnet, and then not need to worry about block sizes ever again.

Appendix:
1. What changes are needed?
A: The "longest chain" code needs to increase the length of shorter blocks and decrease the length of longer ones. Clients also need to set a bandwidth quota so that they download and propagate the best currently-downloaded chain.
2. Couldn't a miner just spam the network with a huge block?
A: No. Like transactions, blocks need "confirmations". If other miners think the block is too big, they will refuse to confirm it and a smaller block will replace it (as they orphan large blocks).
3. Wouldn't blocks be too big?
A: No. Miners will take an unacceptable risk if they mine large blocks, as they are likely to get orphaned. Higher demand and higher transaction fees will make taking that risk more attractive, so block size can scale with usage.
4. Wouldn't miners just mine empty blocks?
A: Eventually, no. This is a concern in the short term, but as soon as transaction fees overtake subsidies empty blocks will no longer be attractive.
5. Wouldn't this allow DOS attacks?
A: Yes. However, DOS attack prevention code can be written to give up downloading a particularly large block if a competing chain is running at not far below network hashrate.
6. Isn't this a hard fork?
A: Done properly, not any more than raising the block limit. The length code only acts as a tiebreaker, which we already have in "first block wins".

I have to say Dree12 is making the most logical sense here.

[John Tobey]

<sarcasm>
Remove the limit completely, so ppl could spam more useless transactions. Let's make HDD producers to produce disks with 100500 PETABYTES capacity!
</sarcasm>

Removing the limit does not imply useless transactions. It simply means the market will decide what is a useless transaction. So long as clients prefer smaller blocks over larger ones, the miners will decide among themselves what a suitable block size is. If it's too high, small-block miners will earn more and blocks will get smaller. If it's too low, large-block miners will earn more and blocks will get larger.

Isn't this what Bitcoin's about? All we need to do is make sure the system cannot be exploited, test it on testnet, and then not need to worry about block sizes ever again.

Appendix:
1. What changes are needed?
A: The "longest chain" code needs to increase the length of shorter blocks and decrease the length of longer ones. Clients also need to set a bandwidth quota so that they download and propagate the best currently-downloaded chain.
2. Couldn't a miner just spam the network with a huge block?
A: No. Like transactions, blocks need "confirmations". If other miners think the block is too big, they will refuse to confirm it and a smaller block will replace it (as they orphan large blocks).
3. Wouldn't blocks be too big?
A: No. Miners will take an unacceptable risk if they mine large blocks, as they are likely to get orphaned. Higher demand and higher transaction fees will make taking that risk more attractive, so block size can scale with usage.
4. Wouldn't miners just mine empty blocks?
A: Eventually, no. This is a concern in the short term, but as soon as transaction fees overtake subsidies empty blocks will no longer be attractive.
5. Wouldn't this allow DOS attacks?
A: Yes. However, DOS attack prevention code can be written to give up downloading a particularly large block if a competing chain is running at not far below network hashrate.
6. Isn't this a hard fork?
A: Done properly, not any more than raising the block limit. The length code only acts as a tiebreaker, which we already have in "first block wins".

I have to say Dree12 is making the most logical sense here.

I agree.  If larger blocks start appearing on the network and become part of the longest chain (i.e., what would be the longest chain if the limit were removed), I will take it as a sign that the major pools have raised or abolished the limit and that bitcoin exchanges, merchants, etc., will follow.  I care more about their idea of what a bitcoin is than about what the devs or the average user thinks, or even my own idea of what would be best.  I doubt that the major stakeholders will disagree with each other strongly enough to risk a near-even split.

Therefore, I would like the ability to configure my Bitcoin client to ignore the limit.  (My client does not generate blocks.)  The prospect of my client following the wrong side of a fork because of an oversized block is all risk, no benefit to me.  (If the "wrong" side persists due to user sentiment, it will effectively become an alt chain, though some will argue that it is still the true bitcoin.)

[ShadowOfHarbringer]

It seems that nobody is volting anymore, so it makes sense to lock the poll.

I hope everybody find the results satisfying, I for sure do.

[flower1024]

Can "No limit" be added?  Thanks.

No it cannot.

Without the limit, Bitcoin network can't function.

why?

afaik it would just lead to more centralisation (which is not very good, but it does still work)

[flower1024]

Can "No limit" be added?  Thanks.

No it cannot.

Without the limit, Bitcoin network can't function.

There has been no proof of this.

1. After the last Bitcoin will be minted, there will be no incentive for miners to mine, except for transaction fees. When block can be of any size, then any number of transactions can make it into every block, therefore theoretically no transaction fees need to be paid.

2. How do you protect the network from dust spam & DDoS without block size limit ?

unlimited block size does not mean that every miner is forced to take any transaction in his blocks.

he is still free to make a policy like "i only put transactions with 0.1btc fee in my blocks".

unlimited just means he has an upper limit which he cannot raise.

[ShadowOfHarbringer]

Can "No limit" be added?  Thanks.

No it cannot.

Without the limit, Bitcoin network can't function.

why?

Actually that sentence is outdated.

I am no longer sure if the network can function without the limit.