[POLL] Is bigger block capacity still a taboo?

[alani123]

Why didn't you calculate this for 10 MB blocks? After all, we are talking about this increase now.

For increase to 10 MB, I'll right as well vote in favor, and maybe a little higher than that. I have clarified before that I'm not strictly against anything beyond 4 MB, I'm just not of the opinion that it's going to solve the problem; it's only delaying it.

Can somebody show me some data or a paper to support this?

It's simple. When a miner mines a block, they are the first to have verified that block; it happens during mining to check for the validity of the transactions. When they broadcast their block, the rest of the miners must firstly verify it before mining on top. The bigger the block size, the more time it takes to verify the block, and hence, the more the time the lucky miner gains to continuing mining alone.

And it's not just verification, it's propagation as well. If you we had 1 GB of blocks, as in BSV, you could perhaps imagine this better. During the time that gigabyte is traveling across the network and is in the process of verification, the lucky miner gains invaluable time advantage.

Nobody said we should straight up go to 1GB blocks. Indeed this would introduce issues like affecting the fee market very negatively and also inviting a lot of spam to be on chain, let alone that nodes would be hard to host.

And yes, with 1 GB blocks propagation would be hard. My upload speed with an ADSL connection that's still very common in my country, would have me taking longer than 10 minutes to download a block.
But honestly for bitcoin nobody talks about blocks that large. Even back in the day of the "blocksize wars" the proposed solutions were much more conservative.

These were the main proposals back then, circa 2015:

source: https://en.bitcoin.it/wiki/Block_size_limit_controversy

Given that so many years have passed, today there would be even less issues in terms of networking infrastructure or hardware to support these changes.

[1714260797]

1714260797

[1714260797]

1714260797

[1714260797]

1714260797

[franky1]

Why didn't you calculate this for 10 MB blocks? After all, we are talking about this increase now.

For increase to 10 MB, I'll right as well vote in favor, and maybe a little higher than that. I have clarified before that I'm not strictly against anything beyond 4 MB, I'm just not of the opinion that it's going to solve the problem; it's only delaying it.

math:    doing nothing= delaying * (avoiding problem * causing more problems)

Can somebody show me some data or a paper to support this?

It's simple. When a miner mines a block, they are the first to have verified that block; it happens during mining to check for the validity of the transactions. When they broadcast their block, the rest of the miners must firstly verify it before mining on top. The bigger the block size, the more time it takes to verify the block, and hence, the more the time the lucky miner gains to continuing mining alone.

a. miners(asics) dont verify transactions/blocks... you mean POOLS
b. POOLS verify transactions pre-confirm. and you as a LN nutcase know nodes can validate "millions of payments a second"
c. POOLS verify a hash matches header.. header has transaction merkle root. root matches leafs.. and leafs are known/checked TXID
at point C competing pools and nodes are not again validating all transactions..
d. at most if a merkle leaf does not correspond to a TXID in a nodes mempool of unconfirms, they ask their peer for that TX.
e. the amount of tx they need to call and validate due to not already having in mempool is a small % of a block

the whole "verification time" is not as big of an assault on nodes as you think it is

And it's not just verification, it's propagation as well. If you we had 1 GB of blocks, as in BSV, you could perhaps imagine this better. During the time that gigabyte is traveling across the network and is in the process of verification, the lucky miner gains invaluable time advantage.

mempools are already validating 300mb-500mb of transactions all the time right now.. stop pretending that nodes cant handle 100mb-500mb+ when all evidence shows the opposite

funny part is you are part of the crew that doesnt want to stop !ONE! transaction being 4mb yet you then say nodes cant handle a few dozen mb of transactions.. even when mempool and subnetwork "state" validtion prove nodes can handle ALOT more then your imaginary barriers

You persist in presenting this as the ultimate argument, despite my repeated assertions that the storage requirement is not our foremost concern.

but your crew is happy that fee's are(time of posting)
341.23 sat/vB ≤ 20 min. (LEAN 226sat tx = 77,066sat = $28.23)

but you want to say a 2012 $150 hard drive for the historic and next 5 years (17 years = $10 a year) is a problem

if paying $10 a year is a concern.. then the tx fee means you want people to only use bitcoin once every 3 years??

sorry but the reality is its the tx fee thats the concern. not the hardware cost..
tx fee is making people not want to transact/run nodes daily..

[stompix]

First, please don't do this, nobody said 100MB, let's not make a mockery out of it!

What's the ideal block size according to you?

You asked me a few times:

Dynamical or why not implement the opposite of halving for the block size, we have a halving in the reward a doubling in the block size. If we look at disk price and internet speed we're already 12 years behind compared to 2009, so we would have at least 2 decades to see if it works or no!

So right now it would be either 4 or 8MB (not vMB)
And before you say something:

Seems like verifying and broadcasting 8 blocks in 20 minutes is not problematic at all, a fact, proven numerous times!
Do you want me to go a bit further in time and give you even more extreme examples? cause you know there are!

You persist in presenting this as the ultimate argument, despite my repeated assertions that the storage requirement is not our foremost concern.

You keep bringing it up!

I mean, yeah, if you dedicate a modern PC to running a full node,

I compared a now 100$ ebay cpu with the 3 year old computer at the time of the first block, same thing, hardly modern or unaffordable.
On what were people running their nodes in 2012? cause...>>>next quote

If you use a Raspberry Pi 4,

There was no Raspberry at the time Bitcoin was launched, the first one came in 2012 and was hardly node material itself!
Why not cut the blocks then to 10kb so every nokia 3330 could host a node? That would do a ton for decentralization since there are millions of them and they cost 10-20$, way cheaper than a raspberry pi!

Now that I've done a lot of explaining, let me ask you something, do you have a solution for the math of everyone getting no more than two transactions till 2040? Or do you think that's not a problem for mass adoption or that mass adoption shouldn't even happen because, fuck the rest of the world, it's just about us who already have filled our stashes?

[apogio]

You asked me a few times:

Dynamical or why not implement the opposite of halving for the block size, we have a halving in the reward a doubling in the block size. If we look at disk price and internet speed we're already 12 years behind compared to 2009, so we would have at least 2 decades to see if it works or no!

Like in Monero. I agree on that, it could be a good option, but we still need a hard cap. I also believe that Bitcoin will mostly be full no matter the variable block size.

[cryptosize]

Like in Monero. I agree on that, it could be a good option, but we still need a hard cap. I also believe that Bitcoin will mostly be full no matter the variable block size.

Satoshi should have done that back in 2010, now I think it's a bit too late for a hard fork.

There were even some serious bugs back then that would be detrimental in 2023.

BTC is ossified and there's a lot of money at stake.

Yeah, I know some people hate the hodl/investing aspect, but BTC has become too valuable, for better or worse. Nobody is gonna risk it right before BlackRock's BTC ETF.

These changes are easier when the network is smaller and each BTC costs a few cents at most...

Now you risk splitting the network in half. You need to provide some sort of guarantee that we won't have another altcoin fiasco (BCH/BSV). Who can do that? BTC Core devs? They don't control the network (miners).

It's roughly the same with IPv4: nobody could have envisioned back in the early 80s that we will have more than 4 billion devices connected online, otherwise we would have gone with 128 bits from the get-go or 64 bits at least.

[BlackHatCoiner]

Let me do a summary:

- Nearly a third of the users votes against, while another third votes in favor (at least in this topic).
- Of those voting in favor, there is complete lack of consensus regarding which block size policy fits better.
- From the history, we have observed similar quarrel on that particular topic, and every single attempt of raising the block size limit has resulted in a crypto-failure. And all these attempts made in a time where Bitcoin was valuated at a small fraction of what it is now.

Hasn't anyone noticed why bigger blocks haven't been adopted yet? To me, it is crystal clear that the risk of splitting the network and breaking backwards compatibility is not worth it. People are willing to pay extra for retaining this invaluable property.

Seriously, my question remains unanswered: why haven't you moved to BSV? Or more reasonably, to BCH? Nobody answers this. These particular coins aren't alts in the traditional sense, they were Bitcoin until someone realized they are capable of enforcing their own policy, forming a network in respect to their perspective. How different is your proposal comparably to Roger Ver's?

[franky1]

Let me do a summary:

- Nearly a third of the users votes against, while another third votes in favor (at least in this topic).
- Of those voting in favor, there is complete lack of consensus regarding which block size policy fits better.
- From the history, we have observed similar quarrel on that particular topic, and every single attempt of raising the block size limit has resulted in a crypto-failure. And all these attempts made in a time where Bitcoin was valuated at a small fraction of what it is now.

not a accurate vote of community
the "against" are obvious alligned to ass kissery without actually using real data, statistics and reasoning. instead full of narratives that have been debunked but stil repeated.

the 'neither' are just too scared to form an opinion or use real data, logic to decide

the "for" actually use better rationale. but we are still fighting the whole core is god crowd so any discussion will just remain discussion, the best we can hope for is to educate the exaggerators and scripters to realise how their objections are foolish, maybe then as friends to core devs can be the soldiers that plot to get core to act from the inside
here is the thing..
the amount of topics promoting subnetworks as solutions is a smaller community of promoters(mostly trolls repeating the same publicity promises and utopia narratives).. but the ample examples of topics about scaling bitcoin shows that more people from a wider variety of mindsets want bitcoin scaling. not sold some 6yo unmet promise

[panganib999]

I remained impartial about this blocksize war, despite it being one of the most pivotal events in the history of cryptocurrencies, and I will remain impartial about it even until now. On one hand, bitcoin remaining to be in this 1 mb size limit ensures that decentralization is taken care of and that no one has to pay so much fees in the future. But at the same time, the benefits of a larger and more advanced network is something not to scoff at either. I say, if we ever feel the need to have a better and more reliable form of bitcoin for transactions and all that stuff, a fork is the only solution that would satisfy everyone's needs and it's something that I personally would be willing to follow through if need be. No more overhauling of the system, cause we don't need to fix what's not broken in the first place.

[HmmMAA]

Just voted against blocksize increase , btc community made it's choice in the past to have a fee market on L1 and scale on L2 rather than scale on L1 . I think that this should never change and each user fight by all means anyone that brings any suggestion against that . UASF can be used at any time , every non miner should send those evil miners a message that in btc there's no PoW consensus but proof of most nodes . Their decision to accept more profitable transactions is insane and they should be pay the price . I think that other SHA256 will welcome them (miners/pools) with open arms , but their hashpower is insignificant compared to the number of rapspi's according to the spirit of btc community .

What most defenders of the position that blocksize should not increase is that there is no transaction volume yet to do so . There are thousands of projects other than btc that have tremendous amounts of transactions . These people transact there because it's easier than transacting in LN . Btc maxis don't want bitcoin to work the way it was supposed to . If they open their eyes they will see that millions of people actually use crypto because the most famous doesn't work . If bitcoin scaled back then no other projects would have a reason for existence .

What you have achieved is to provide free profit to pools . Pools love that they don't have to spend a single penny for their infrastructure . Entities that earn tens of millions don't pay a single cent and users pay insane fees . This is the best way to maximise their profits , no one else wins . Of course , there are some users that love validating their transactions ( i wonder how many transactions these users do on L1 ) and they keep the network hostage to their nerdy needs . And these users are the new legendary legion that every newbie admires when entering this space .

No time to write more , i will respond to vjudeu at a later time .

Closing my message i would like to make it an open call to UASF . No more time should be spend .

PS. I don't use btc network for years , but i think i should remind the community what decision took some years back . Prove that you were right all the time and stick to your position .

[franky1]

"backward compatibility" means there is no way for a USER assisted fork.. users have become crippled
the 2017 was never a UASF

the process would actually be to use what actually happened in 2017 but mirror-reversed
ECONOMIC NODE operators to instigate/lobby NYA mandated threat to set their services to reject/not see mining pool rewards(blocks) that did not concede to show alignment to the NEW core roadmap that will fix their exploit..

where core would need to code the ruleset..  because any other brand would get REKT

i do laugh how HmmMAA formed an opinion based on the same debunked crapscripts that the other objectors have been falsely spouting
yet fo 6 years the blockdata of flag events, code and evidence of the economic node strategy has been available in just a few minutes of research
just requires looking at the data, not the social aligned blogs

[pooya87]

There were even some serious bugs back then that would be detrimental in 2023.

Any kind of bug in a major implementation like core is harmful but not the way you'd think. In 2010 there was only one implementation running and that had a bug so the whole network went on an invalid chain. Today there are more than one implementation of Bitcoin running and if one had a bug, it would be on the wrong chain and the correct chain can still grow with valid blocks with other clients.
This also highlights necessity of having multiple implementations.

Now you risk splitting the network in half. You need to provide some sort of guarantee that we won't have another altcoin fiasco (BCH/BSV). Who can do that? BTC Core devs? They don't control the network (miners).

That's a wrong comparison. The bcash fiasco was a minority trying to split off. The problem with those two shitcoins is not even with their bigger blocks, it is all about the fact that they did NOT fork by reaching majority consensus.
The guarantee is as it has always been with any fork: to vote and only lock in after we reach more than 90-95% support.

[ABCbits]

Can somebody show me some data or a paper to support this?

It's simple. When a miner mines a block, they are the first to have verified that block; it happens during mining to check for the validity of the transactions. When they broadcast their block, the rest of the miners must firstly verify it before mining on top. The bigger the block size, the more time it takes to verify the block, and hence, the more the time the lucky miner gains to continuing mining alone.

And it's not just verification, it's propagation as well.

FYI, Compact Blocks (https://bitcoincore.org/en/2016/06/07/compact-blocks-faq/) partially mitigate this problem as you don't have to propagate whole block and the TX already verified when it arrive on your node.

On one hand, bitcoin remaining to be in this 1 mb size limit ensures that decentralization is taken care of

Actual block size limit isn't 1MB, but rather 4 kWU (4 million weight unit) or 1 vMB (1 virtual mega byte) where actual size of block can reach up to 4MB.

and that no one has to pay so much fees in the future.

How can you be sure when in this week you need to spend few dollars to ensure your TX included in next few blocks?

[Wind_FURY]

I believe some of you might start going deeper into the argument for bigger blocks that you might also start to think Roger Ver and Bitcoin Cash made the right decision, and you might also start debating for Satoshi's original vision.

They have their thesis, and the product of that thesis is BCash 32MB Blocks. It's probably a good network to test NFTs in the blockchain, no? Their miners might be very worried because their block rewards will be halved next year.

[DooMAD]

Now you risk splitting the network in half. You need to provide some sort of guarantee that we won't have another altcoin fiasco (BCH/BSV). Who can do that? BTC Core devs? They don't control the network (miners).

That's a wrong comparison. The bcash fiasco was a minority trying to split off. The problem with those two shitcoins is not even with their bigger blocks, it is all about the fact that they did NOT fork by reaching majority consensus.

The question effectively becomes:  "What does it take to get everyone on the same page?"  

Even under the pressure of Ordinals, we can't find agreement within a tiny sample of network participants.  It seems unlikely we'd find network-wide consensus, so cryptozize isn't wrong to point out the inevitable outcome if people try to rush this.

For the record (and before obnoxiousgasbag1 tries to put more words in my mouth), I'm not fully opposed to throughput increases.  I'd just rather any proposals are appropriately timed, measured, reasoned and that all the consequences are fully considered.

[Synchronice]

I have said many times that I feel satoshi’s biggest mistake with Bitcoin was not putting in a block size adjustment feature similar to the way difficulty is adjusted. I believe the blocksize limit was put in place as a knee jerk reaction to the chain being spammed and if satoshi had more time on this earth a method to adjust the blocksize limit would have been put in place.

We can't blame him, he couldn't really keep absolutely everything in mind. Sometimes, you discover new problems as time goes by but you are right, it would be the best solution to increase block size two times as reward splits.

What makes BCH and BSV shitcoins is a plethora of reasons other than just having bigger blocks.

People call BCH and BSV shitcoins because they read someone posted shit on them. Actually, they don't know the real reason why these coins are shitcoins. They have probably never heard about Craig Wright, Roger Ver, Jihan vu and others.

I read many posts and to be honest I can't understand how increased block size can make bitcoin less secure. Is 1MB any standard for security?
Also, I want to say that it's not a problem today to store bitcoin blockchain on hard drive. SSDs and HDDs are way cheaper than they were years ago, we have far more speed and capacity today for a cheap price. Please, don't call a problem something that is not a problem. Space and price is not a problem today! Increased block size won't be a problem today! If block size was a problem, someone would come up with an idea to decrease block size in 2015-2016 but no one came up with that idea because that's not true!

But to be honest, after thinking for a while, I think we have another problem besides block size and they are miners. Mining is becoming way centralized, pools are collecting all the transaction fees and people are willing to join pools that don't share transaction fees. These pools are one of the biggest pools who can flood mempool with their resources and gain more profit. They can flood it easily because they confirm the blocks and fees go back to their pockets but increased block size should make it a little bit hard for them to do.

[franky1]

The question effectively becomes:  "What does it take to get everyone on the same page?"  

For the record (and before obnoxiousgasbag1 tries to put more words in my mouth), I'm not fully opposed to throughput increases.  I'd just rather any proposals are appropriately timed, measured, reasoned and that all the consequences are fully considered.

but you REKT proposals by you scripting to your flock silly exagerations.. not real technical reasons

Even under the pressure of Ordinals, we can't find agreement within a tiny sample of network participants.  It seems unlikely we'd find network-wide consensus, so cryptozize isn't wrong to point out the inevitable outcome if people try to rush this.

but you dont beleive in the PEOPLE. you dont like consensus, you beleive there should be no consent of the people, you love the "backward compatibility" that bypasses the requirement of a consensus vote. you hate anyone not core adoring/affiliated. you love only core having the decision and development power.. so why pretend that its "people" trying to rush it.. rather than admit its core avoiding for unreasonable reasons

[CreepyUncleJoe]

The present average Bitcoin fee at 123 sat/vB, amounting to $6.29, renders it useless for everyday transactions.

[BlackHatCoiner]

I believe some of you might start going deeper into the argument for bigger blocks that you might also start to think Roger Ver and Bitcoin Cash made the right decision, and you might also start debating for Satoshi's original vision.

It really depends on what classifies as "right". Opinions fundamentally differ on block size policy.

I read many posts and to be honest I can't understand how increased block size can make bitcoin less secure. Is 1MB any standard for security?

I have explained in this post.

Also, I want to say that it's not a problem today to store bitcoin blockchain on hard drive.

Not on 4 MB blocks. Maybe neither on 10 MB or 20 MB, but if you arbitrarily increase it to something like 100, then that will also be a problem at some point.

[alani123]

Seriously, my question remains unanswered: why haven't you moved to BSV? Or more reasonably, to BCH? Nobody answers this. These particular coins aren't alts in the traditional sense, they were Bitcoin until someone realized they are capable of enforcing their own policy, forming a network in respect to their perspective. How different is your proposal comparably to Roger Ver's?

The thing is, BCH is alive only because Roger Ver was rich before he created it.
He turned blockchain.com, satoshidice, bitcoin.com and some other ventures of his into hubs for BCH. If these are gone, its questionable if BCH will also survive.
Roger Ver is bitcoin cash's strength due to his support to it, but also its biggest detriment. I think no sane bitcoiner would lend his support to a coin that's so centered around the support of a single person.

The ideal solution would be for the main bitcoin code base to implement a solution that would accommodate on-chain scaling, while keeping all its merits in decentralization, talented devs and community. Bigger blocks might address the issue of scaling but as many have rightly pointed out, it's not the single most important issue for bitcoin, and especially in 2015, it wasn't a good time to split from core over this issue. A more scalable solution for transactions is needed now more than ever. In 2017, when BCH split from core, it failed to demonstrate the need for bigger blocks, and was just seen by a greedy move. Years later and BCH is still Ver's cash cow while he has altogether stopped interacting with the bitcoin community.

So just my two cents, but saying to people that they might as well go support BCH if they want bigger blocks, isn't really something productive.
Increasing block capacity has some merits and these should be examined individually. Goal here is to improve the bitcoin we love, not shoot each other in the foot.

[franky1]

I read many posts and to be honest I can't understand how increased block size can make bitcoin less secure. Is 1MB any standard for security?

I have explained in this post.

you did not explain anything
you instead
a. thought that ASICS validate transaction data.. they dont .
ill quote you

It's simple. When a miner mines a block, they are the first to have verified that block; it happens during mining to check for the validity of the transactions.  

you are wrong about what miners do and wrong about when transaction validation happens, heck your even wrong about the term miner
asics(miners) just hash a header.. a length of header/hash doesnt change no matter the "blocksize"
pools(transaction validator, collator and blocktemplate creators) are separate things

b. then went and exaggerated a 1gb scenario of extreme irrationalness