[PATCH] increase block size limit

11 messages BitcoinTalk Jeff Garzik, Satoshi Nakamoto, Michael Marquardt, FreeMoney, kiba, appamatto, caveden October 3, 2010 — November 20, 2010
Jeff Garzik October 3, 2010 11:13 UTC Source · · Commentary

We should be able to at least match Paypal’s average transaction rate…

theymos October 3, 2010 20:28 UTC Source ·

Applying this patch will make you incompatible with other Bitcoin clients.

Satoshi Nakamoto October 3, 2010 21:07 UTC Source · · Commentary
Quote from: theymos on October 03, 2010, 11:28:39 AM UTC

Applying this patch will make you incompatible with other Bitcoin clients.

+1 theymos.  Don’t use this patch, it’ll make you incompatible with the network, to your own detriment.

We can phase in a change later if we get closer to needing it.

Jeff Garzik (jgarzik) October 3, 2010 21:38 UTC Source ·
Quote from: satoshi on October 03, 2010, 12:07:28 PM UTC

We can phase in a change later if we get closer to needing it.

IMO it’s a marketing thing. It’s tough to get people to buy into a system, if the network is technically incapable of supporting high transaction rates.

FreeMoney October 4, 2010 07:39 UTC Source ·
Quote from: Jeff Garzik on October 03, 2010, 12:38:46 PM UTC
Quote from: satoshi on October 03, 2010, 12:07:28 PM UTC

We can phase in a change later if we get closer to needing it.

IMO it’s a marketing thing. It’s tough to get people to buy into a system, if the network is technically incapable of supporting high transaction rates.

Satoshi just said it can be changed, so technically the network is capable.

Jeff Garzik (jgarzik) October 4, 2010 08:10 UTC Source · · Commentary
Quote from: FreeMoney on October 03, 2010, 10:39:35 PM UTC
Quote from: Jeff Garzik on October 03, 2010, 12:38:46 PM UTC
Quote from: satoshi on October 03, 2010, 9:07:28 PM UTC

We can phase in a change later if we get closer to needing it.

IMO it’s a marketing thing. It’s tough to get people to buy into a system, if the network is technically incapable of supporting high transaction rates.

Satoshi just said it can be changed, so technically the network is capable.

It is also an incompatible change, as you see…

Jeff Garzik (jgarzik) October 4, 2010 18:33 UTC Source ·

[Deleted] Quote from: martin on October 04, 2010, 11:50:35 AM

No, it’s incompatible if just a few people change their behaviour. To roll out a change to the network you need to get most of the clients understanding both the old and the new protocol, and then when you have a majority you turn on the new protocol.

You just described a whole-network upgrade. I’d call that an incompatible change 😊

The effort to raise the transaction rate limit is the same as the effort to change the fundamental nature of bitcoins: convince the vast majority to upgrade.

Satoshi Nakamoto October 4, 2010 19:48 UTC Source ·

It can be phased in, like:

if (blocknumber > 115000)     maxblocksize = largerlimit

It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don’t have it are already obsolete.

When we’re near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.

kiba October 6, 2010 01:09 UTC Source ·
Quote from: Jeff Garzik on October 04, 2010, 6:33:55 PM UTC
Quote from: martin on October 04, 2010, 11:50:35 AM UTC

No, it’s incompatible if just a few people change their behaviour. To roll out a change to the network you need to get most of the clients understanding both the old and the new protocol, and then when you have a majority you turn on the new protocol.

You just described a whole-network upgrade. I’d call that an incompatible change

The effort to raise the transaction rate limit is the same as the effort to change the fundamental nature of bitcoins: convince the vast majority to upgrade.

If we upgrade now, we don’t have to convince as much people later if the bitcoin economy continues to grow.

appamatto October 20, 2010 19:50 UTC Source ·
Quote from: kiba on October 06, 2010, 1:09:04 AM UTC
Quote from: Jeff Garzik on October 04, 2010, 6:33:55 PM UTC
Quote from: martin on October 04, 2010, 11:50:35 AM UTC

No, it’s incompatible if just a few people change their behaviour. To roll out a change to the network you need to get most of the clients understanding both the old and the new protocol, and then when you have a majority you turn on the new protocol.

You just described a whole-network upgrade. I’d call that an incompatible change

The effort to raise the transaction rate limit is the same as the effort to change the fundamental nature of bitcoins: convince the vast majority to upgrade.

If we upgrade now, we don’t have to convince as much people later if the bitcoin economy continues to grow.

I agree, especially since generators are both the source of blocks and “votes” in the network. Since a block restriction would allow generators to charge higher transaction fees, they might “vote” against an increase in the max size in the future.

It seems unlikely to be a real problem though.

caveden November 20, 2010 13:19 UTC Source ·

Only recently I learned about this block size limit.

I understand not putting any limit might allow flooding. On the other hand, the smaller your block, the faster it will propagate to network (I suppose.. or is there “I’ve got a block!” sort of message sent before the entire content of the block?), so miners do have an interest on not producing large blocks.

I’m very uncomfortable with this block size limit rule. This is a “protocol-rule” (not a “client-rule”), what makes it almost impossible to change once you have enough different softwares running the protocol. Take SMTP as an example… it’s unchangeable.

I think we should schedule a large increase in the block size limit right now while the protocol rules are easier to change. Maybe even schedule an infinite series of increases, as we can’t really predict how many transactions there will be 50 years from now.

Honestly, I’d like to get rid of such rule. I find it dangerous. But I can’t think of an easy way to stop flooding without it, though.