Bitcoin 20MB Fork

[hdbuck]

Blocks have already reached the  1 MB limit.  The block size limit is already affecting delay for confirmations. This happened to a real purchase of physical goods I made the other day, with multiple large blocks following a one hour plus block. (This was a high priority transaction.)

The real issue isn't block size, it's whether we want to cripple the transaction processing capability of Bitcoin, thereby guaranteeing that Bitcoin remains a curiosity and never becomes mainstream.

Right, i get it, if not done now, it probably never will.

But define mainstream. I thought 'masses would use bitcoin without knowing it'

[Puppet]

I wonder/worry about is miners deliberately mining small blocks when the pile of unconfirmed transactions is waiting.

Small blocks propagate faster, so there is less chance of orphaning them.

[inBitweTrust]

But define mainstream. I thought 'masses would use bitcoin without knowing it'

Whether or not they realize they are using the bitcoin blockchain will not matter as much as if the blockchain will be able to scale to handle the transaction load and be able to pay for security in the future. If everything is handles off the chain because of Bitcoin is still in its training wheels than we have defeated one of the main benefits of bitcoin altogether.

Small blocks propagate faster, so there is less chance of orphaning them.

This will incentivize miners to have fast and reliable uplinks and thus in turn benefit propagation. Some miners will have to make calculated decisions to either accept the smaller blocks with less tx fee reward and less likely to orphan vs other miners which accept the larger blocks to cash in on the larger reward.  A Half filled 20MB block could get an extra ~1600 usd fiat reward which is starting to provide decent change to fund future network security ontop of the block reward.

[randy8777]

1mb size is enough for current transactions but not if you imagine one day we will have mass adoption.

[a fool and his money ...]

[...] all the big boys need to just agree on the hardfork and do this, the sheep will follow the lions.

[unamis76]

I voted pro. Why not?

It's not needed right now, but one day it might be, and I think when that day reaches everyone will be ready for it.

[funtotry]

Voted for it, we will probably reach that limit some day so why not change it now when theres no pressure

[inBitweTrust]

I voted pro. Why not?

It's not needed right now, but one day it might be, and I think when that day reaches everyone will be ready for it.

Yes , but in reality the 1MB limit is already effecting us now:

[inBitweTrust]

Currently we have 7 transactions per second, so how many transactions can be included in 20mb blocks?
Is 20mb enough? Why was 20 chosen and not 100mb?

We may have to do another fork in the future raising it above 20MB , or perhaps we won't need to raise it past 20MB because transactions will occur mainly offchain and on sidechains, or perhaps we will decide to increase TPS by other methods(decreasing block time to ~2.5min instead of ~10min and adjusting the algo to insure we are on target for same 21 million distribution).

20MB looks as if it will but us at least 5 years though.

[pawel7777]

OK, I haven't been following the subject lately. Can anyone please help me with quick summary and answer the below?

1 - Has the 'general agreement' on the proposed changes been reached, or is it still an open-subject?

2 - Is the 461mb block size (shown in the doc) by 4 June 2024 the final size (hard-cap) or will it be ever-growing?
https://docs.google.com/spreadsheets/d/1CuOEM9uwO5w-RwWGCCZpVGVFwhHHHegxJZqTP5KyapI/edit?usp=sharing

3 - Are the proposed changes entirely dependent on belief that bandwidth and storage capacities will expand continuously for ever?

4 - Are there plans to implement the reduction of the blockchain size along with the max-block size fork?

[smoothie]

It will have to scale...not a matter of if...but when....and how that all goes down.

[hdbuck]

It will have to scale...not a matter of if...but when....and how that all goes down.

exactly my thoughts, still, the 'how' should not be taken lightly imho.
i just want to be sure every options has been investigated accordingly instead of rushing things.
rushing has never brought anything good smart for all i know throughout history.

[inBitweTrust]

OK, I haven't been following the subject lately. Can anyone please help me with quick summary and answer the below?

1 - Has the 'general agreement' on the proposed changes been reached, or is it still an open-subject?

Looks like the 20MB limit will go through and the details are being worked out but with any open source decentralized project the real vote lies with the nodes and not Gavin or other devs. A group of anti-20MB blockheads are testing a speciatly made node and may attempt to deploy up to 10k of them in an attempt to outbid the current supporters of the hardfork: https://bitcointalk.org/index.php?topic=919629.460

2 - Is the 461mb block size (shown in the doc) by 4 June 2024 the final size (hard-cap) or will it be ever-growing?
https://docs.google.com/spreadsheets/d/1CuOEM9uwO5w-RwWGCCZpVGVFwhHHHegxJZqTP5KyapI/edit?usp=sharing

Those are just tests to check hypothetical limits of scalability.

3 - Are the proposed changes entirely dependent on belief that bandwidth and storage capacities will expand continuously for ever?

No, but these trends within computing are widely expected and we are only discussing one step here and have no obligation to continue future hardforks to increase block size

4 - Are there plans to implement the reduction of the blockchain size along with the max-block size fork?

Yes, there are several plans be worked on and some of the changes have already started to be rolled out like headers first. There needs to have more testing done with merkle tree pruning before rolling out the changes ... additionally we may want to fully test sidechains before implementing this change.

[Eamorr]

It's like trying to replace the wheels on an old steam engine that's still running.

This is gonna be some ride for the folks back in 3rd class.

[acoindr]

It will have to scale...not a matter of if...but when....and how that all goes down.

exactly my thoughts, still, the 'how' should not be taken lightly imho.
i just want to be sure every options has been investigated accordingly instead of rushing things.
rushing has never brought anything good smart for all i know throughout history.

Everything has been investigated, debated and re-debated for years now. I appreciate that everyone has an opinion, but not everyone has been involved since nearly the beginning, nor understands everything involved at the same level. It's definitely the right thing to do. Otherwise Bitcoin might fall by the wayside while some alt-coin with a more sensible community of supporters steals its thunder by incorporating higher limits and thus a more global user base.

[Eamorr]

I know, let's have a vote! The man on the street knows best.

[Anillos2]

I've voted "anti" because it could increase the HDD usage. At this moment the Blockchain is very large, and this fork could made it even bigger. Maybe it could grow faster than HDD storage.

[inBitweTrust]

I know, let's have a vote! The man on the street knows best.

The real vote will be done by the miners and full nodes. Mircea Popescu and a few of his friends may try and prevent the hardfork with thousands of nodes. I don't expect his plan to materialize though and seems to me as more chest thumping and hot air but there certainly will be some drama in the coming months.

I thought 2 was a proposed method to allow the blocksize to grow with adoption?

Yes, you are probably correct... I was blocked access to the doc and made an assumption there.

[BitUsher]

Looks like Gavin and other developers are being really careful and implementing the right changes to make Bitcoin grow. I vote yes, and so will my nodes.

[BitUsher]

Is the rising limit still a possibility? If so maybe needs a new poll including it?

I believe the reason why Gavin was against the dynamic algorithm which automatically adjusted block size was because certain spikes in transactions could create unforeseen increases and consequences.

Still would be good to have that as an option to consider.