[PATCH] increase block size limit

[Technomage]

The current upgrading tendencies are not really an accurate prediction of how it will be with the fork. The fork, when and if it's decided, is a super high profile thing. It would also likely be something that's already felt by the users (higher fees perhaps?), so they would most likely upgrade significantly faster than with regular patches. That being said, they would likely not upgrade super fast regardless, so months are needed at least.

[1715369225]

1715369225

[1715369225]

1715369225

[1715369225]

1715369225

[1715369225]

1715369225

[1715369225]

1715369225

[1715369225]

1715369225

[theymos]

When Satoshi introduced the backward-incompatible checksum change, he set it to activate after two years. That seems like a reasonable amount of time.

[caveden]

This comment concerns me very much. Dust spam may not have economic value when denominated in bitcoin, but such "spam" can be representative of much larger transactions if the dust is representative (such as with "colored" bitcoins).

A tiny fraction of a bitcoin might represent an ounce of gold (for instance), and so it should NOT be assumed useless or disallowed by the protocol!

I think prioritizing transactions by fees is better than trying to rule out transactions which don't have an immediately obvious purpose.

Of course they shouldn't be "disallowed", but regardless of what they represent elsewhere, these dust transactions may be a "nuisance" to Bitcoin if they are not majorly composed of fees.

I don't understand why using Bitcoin for this inherently centralized use cases (like asset issuing), when there are better suited protocols like Open Transactions, for instance.

[Akka]

The current upgrading tendencies are not really an accurate prediction of how it will be with the fork. The fork, when and if it's decided, is a super high profile thing. It would also likely be something that's already felt by the users (higher fees perhaps?), so they would most likely upgrade significantly faster than with regular patches. That being said, they would likely not upgrade super fast regardless, so months are needed at least.

Could it not be simply introduced, that miners with the patch "mark" their blocks somehow and as soon as say at least 80% of all blocks are "marked" a countdown activates (maybe 20,000 Blocks) to give the remaining 20% some time.

[poly]

The current upgrading tendencies are not really an accurate prediction of how it will be with the fork. The fork, when and if it's decided, is a super high profile thing. It would also likely be something that's already felt by the users (higher fees perhaps?), so they would most likely upgrade significantly faster than with regular patches. That being said, they would likely not upgrade super fast regardless, so months are needed at least.

Could it not be simply introduced, that miners with the patch "mark" their blocks somehow and as soon as say at least 80% of all blocks are "marked" a countdown activates (maybe 20,000 Blocks) to give the remaining 20% some time.

That is pretty much what is happening already with block versions now.

There's block version 1 and block version 2. When 950 of the last 1,000 blocks are version 2 or greater, all version 1 blocks will be rejected by those who updated, and will therefore be orphaned.

[solex]

Which is why I started this thread, but have had no useful feedback:

https://bitcointalk.org/index.php?topic=145224.0

[Syke]

Blaming S.DICE is useless. That service alone currently pays more fees to the network than all other Bitcoin usage combined. As S.DICE grows, it will pay more and more fees. More with each and every new user. That is how it's supposed to be of course. The problem here is nothing else than a setting that is slowly but surely becoming a problem for overall Bitcoin usage.

If services such as S.DICE become even more commonplace, obviously we can't just raise the blocksize on their account alone. We can let the fees rise a bit and control it that way. This problem is not about S.DICE though, it's about overall Bitcoin adoption. Without S.DICE it would just take a bit longer, that however would change nothing.

S.Dice is essentially micro-transactions. Increasing the block size to support micro-transactions is absolutely the wrong idea. Bitcoin cannot be built around micro-transactions.

[Rogue Star]

S.Dice is essentially micro-transactions. Increasing the block size to support micro-transactions is absolutely the wrong idea. Bitcoin cannot be built around micro-transactions.

what you are really saying here is:

S.Dice are transactions. Increasing the block size to support transactions is absolutely the wrong idea. Bitcoin cannot be built around transactions.

Most people around here are thinking about transactions incorrectly. I'm going to single out Jeff in passing because he is a core-dev that has only gone from one extreme to another. Bitcoin is not built to support micro-transactions and this is evident from the way transactions must propagate and all the economic incentives that support the auditing of transactions. What is not evident is what a "micro" transaction really is in the context of Bitcoin.

I think fundamentally a micro transaction in Bitcoin is a transaction or perhaps a tx out that is not worth propagating or auditing. Technically it is very hard to argue S.Dice is a micro transaction otherwise it would be impossible to propagate or audit. Economically it is not so clear cut, but there is a market for auditing S.Dice transactions, so I would say economically it is not a micro transaction. You can say that S.Dice is subsidized by the block reward, but take the reward away and it almost the only incentive to audit other transactions. Thus, S. Dice will not truly be a micro transaction in the context of Bitcoin until it is impossible to transact on the Bitcoin network. When that will happen will be determined entirely on network management.

Bitcoin never promises to support micro transactions as I've outlined it nor is it built for that. Bitcoin is a payment network. From a network management point of view S.Dice is a problem because of the spammy messaging, but otherwise the transactions are just as valid as any other on the network.

My network management suggestion to S.Dice would be to include the messaging component as part of the bet so the messaging output would be limited to the size of the minimum bet, which should follow whatever the network can support. Integrations with wallets such as blockchain.info could just hide the messaging component of the bet to make it user friendly, done correctly it could even be used to collect any dust it has already created. Perhaps it is also worth considering not using a messaging component for most S.Dice bets as it has already established a reputation and messaging could be implemented as an optional value-added service rather than a default operating mode.

[ArticMine]

Time to revive this thread again. Gavin is now taking action on the 1MB limit. https://bitcointalk.org/index.php?topic=1074701.0;all

Edit: I doubt Bitcoin will remain viable in two years time if the 1 MB limit is not addressed, so I will not be able to revive this thread a third time. 

[solex]

Time to revive this thread again. Gavin is now taking action on the 1MB limit. https://bitcointalk.org/index.php?topic=1074701.0;all

Edit: I doubt Bitcoin will remain viable in two years time if the 1 MB limit is not addressed, so I will not be able to revive this thread a third time.  

Yep, and I would really like to see Jeff Garzik explain what his solution is now since he has had 4.5 YEARS to consider it further.

A solution other than do nothing, lets crash into the limit (which he never liked in the first place), and see what happens.

More like this maybe:

We should be able to at least match Paypal's average transaction rate...

Code:

-static const unsigned int MAX_BLOCK_SIZE = 1000000;
+static const unsigned int TX_PER_MINUTE = 1400;
+static const unsigned int TX_AVG_SIZE_GUESS = 256;
+static const unsigned int MAX_BLOCK_SIZE =
+	TX_PER_MINUTE * TX_AVG_SIZE_GUESS * 10 * 2;

[samson]

I don't see what the big deal is with changing the maximum block size.

Why all the fuss ? It's not like blocks which are currently on average about half the current maximum size will suddenly and inexplicably jump in size overnight just because it's possible.

[HCLivess]

I don't see what the big deal is with changing the maximum block size.

Why all the fuss ? It's not like blocks which are currently on average about half the current maximum size will suddenly and inexplicably jump in size overnight just because it's possible.

hard fork

[_biO_]

I don't see what the big deal is with changing the maximum block size.

Why all the fuss ? It's not like blocks which are currently on average about half the current maximum size will suddenly and inexplicably jump in size overnight just because it's possible.

The problem is that you can't react to a large increase immediately, you need at least 6-12 months lead time or you risk a fork. Also, the default blocksize soft-limit is actually 750k, which most miners adhere to. So were are at ~66% of the preconfigured capacity, on average. If usage increases, as it historically does during winter, we might have serious capacity problems next year, and we maybe even see the signs this year. Especially during peak times we might see an substantial increase in confirmation times that may drive users away from bitcoin.

[bitcreditscc]

Fanboys spouting shit should read this thread. The change to larger blocks has been in the works for a long time so buck up and lets do this.

[Morecoin Freeman]

I have read through this thread (good read!) and I have a question:
Do all of the bitcoin core developers agree on increasing the block size limit?
And if not, what are their arguments against the increase?

[Pecunia non olet]

I have read through this thread (good read!) and I have a question:
Do all of the bitcoin core developers agree on increasing the block size limit?
And if not, what are their arguments against the increase?

That can be read on various places. Please search the web before asking questions that have been answered 100 times already.

[Morecoin Freeman]

Ah excuse me, I guess you are right. I did read something about it just now.
In case someone else has the same question, what I found:

That it could lead to centralization within the mining community, which would favor bigger and richer mining operations.
And that there are too many unknowns about the consequences of increasing the block size to 20 megabytes.

[bitcreditscc]

That is all moot. Just think, your phone can get a 128GB memory card. Your HDD can be up to 4 TB right now. Where does it seem like the average user cannot keep up?

just because we say teh max block size is 20 MB does not mean we will immediatley fill them. likely the'll remain around the same size for a bit longer before they regularly pass the 1 Mb size, they likely wont touch 2 Mb average for another two years.

In terms of storage within a year 10 TB, 20 TB and 50 TB hard drives will be commercially available, so i see no reason to hold back progress over baseless fears.

[bitcreditscc]

People have no problem downloading GTAV or MKX yet they cant spare 50Gb for their money. Let's be serious people.

[Morecoin Freeman]

I am somewhat uneducated on the matter, but I would also opt for the change in block size limit.