Actually it's the opposite.

If 4GB blocks become the norm (because that's what BSV folks envision), then FTTH would become mandatory. ADSL is still the most common (baseline) connection worldwide, hence why 1MB block size makes sense as a "baseline".

Hell, I would argue that the few remaining, hyper-competitive pools would be concentrated into a single geographical spot (maybe USA?) and they wouldn't even use FTTH.

They would just use LAN/Ethernet connections (1 Gbps symmetric) to sync with each other! Kinda like a LAN party if you will. BTC would turn from a permissionless network to permissioned (some pools already demand KYC).

You really like this scenario? This is not very different compared to fiat/central banking (i.e. ECB TARGET2 ledger).

I really wonder if big block fanatics are sincere good guys/idealists or government trojan horses/feds trying to hijack BTC, even though they pretend to preach "global adoption".

I sincerely hope we won't have to find out...

BSV, BCH etc are all irrelevant, talking about GB blocks is also irrelevant to Bitcoin block size discussions, no one is stupid enough to actually think about anything above 100MB by 2030. So I think bringing GB is bad, it makes mining centralized etc is a fallacy.
I don't know who you are but it seems you have a few pockets filled by recent spam attacks and you are trying to deviate from the actual concern, which is ; Bitcoin has to scale. I would say if we had 8MB blocks, we could hit the walls of $80,000 by now, but that's just speculation right?

Right Mr. Sherlock, you've exposed the grand conspiracy behind the cryptosize alias!

Gosh, this forum never ceases to amaze me...

Not only it's speculation (that's fine), but it's totally unfounded.

We won't hit a new ATH by Dec 2024/Jan 2025 at the earliest, so 80k ain't happening any time soon, regardless of block size. Feel free to bookmark/screenshot my post.

BTC never reaches a new ATH, until at least 6 months have passed after the latest halving. Study the charts/patterns.

Do the node owners ever ask this question: Why would I run a node and store irrelevant data, then when I want to send a transaction, I'd need to pay $10?  Imagine you want to send 1 TX per day, it would be $300 per month, mining pools better start running the nodes, right? Because they are so fond of these dust spams.

I wonder why we have to keep conflating the discussion with BSV and BCH.
Already I've seen some BSV fans here (to clarify, I'm not one of them) that voiced their opinion saying that they're against a block capacity increase for BTC.
Obviously their reasoning is that they believe they can do it bigger and better... But why should that concern us?
Is the goal to improve BTC or not? Because obviously BSV as a ton of faults, and just because CSW is acting the way he does, it doesn't mean that bitcoin would have to fall in the same traps when implementing an improvement.

At this point I find these arguments quite counterproductive to be honest.
Bitcoin's development is supported by many scientists, if we all agreed that a slight block capacity increase is warranted, they'd find a way to implement it well enough so there are no fundamental issues.

A slight capacity increase is not going to solve scaling issues (assuming mass adoption is the endgame) and still risks splitting the network in half.

People need to find more ingenious solutions (soft forks like SegWit).

Who knows, maybe if AI advances enough, it could do BTC R&D by itself (assuming people won't find a good enough solution).

It won't be easy to reach a consensus regarding the "ideal" block size. Who determines what's ideal? For what purpose?

Some people want BTC to be the be-all and end-all cryptocurrency and no alts to exist (such as LTC, DOGE, XMR).

I get it, it sounds noble, but I'm afraid this is not going to happen. It hasn't happened to Linux distros AFAIK (tons of debates about the ideal distro, libraries etc.)

There's a reason so many Linux distros exist. Same with cryptocurrencies.

ps: A BTC hard fork will happen only when a real threat arises (such as mainstream quantum computing).

Yes, it doesn't solve the problem but it's clear that current block size is not enough and it's not just a temporary case. What if bitcoin becomes popular and millions of people want to make transaction each day? They'll move on altcoins and this is a very serious threat.

I missed that post, sorry.
I like your question: what's the ideal block size? Ideal size doesn't exist but size has to be chosen. Something flexible would be great, like, block size adapts to number of transactions, i.e. one block gets mined every 10 minutes and includes 5% of all transactions. If number of transactions increase, block takes more transactions and block size increases and if number of transactions decrease, so does the block size. But that's probably not possible.

10MB is not a problem today but it was a problem years ago, right? 100MB is a problem today but it won't be a problem years later. I'm afraid, we may have to gradually increase block size but it's not the best solution to the problem. This problem is not easy to deal with. After all, block size increase really looks like delaying the problem but that doesn't mean we should stop on current limit even if it means delay.

This reeks of potential technical debt.  It's something you've proposed on numerous occasions for the last few years now, but have never fleshed out.  How, exactly, do you propose enacting this?  Don't just give us the wishlist, tell us step by step what this option actually entails.

---

I'd also rather see something adaptive and dynamic.  In the past I've advocated for such an approach.  It likely is possible, but the primary challenge is that it has to stand up to game theory.  If there are ways to manipulate or rig the system to an outcome which suits an attackers goals, then it's no good.  We can't inadvertently introduce that kind of weakness.

the technical debt already exists.. its the cludge they already put in it to get segwit working

the code sipa added when rewriting bitcoin core to make segwit work (the cludge) reeks of technical debt because it is.. however not having the cludge and getting back to simpler straight forward block sizes, proper coding, proper byte counting, proper validation.. lessens/undoes the technical debt

if you dont thing core screwed up and introduced a open door to let junk in.. explain the ordinal inscription junk that abuses cores unconditioned opcodes due to segwit/taproot

as for the cludge,
yes there are many lines of code in different sections that deal with the legacy*witness and serialised witness.. and all the other cludge of vb and weight unit manipulations of byte counting..  but thats cores own fault for creating the cludgy way of trying to slide segwit in..

getting back to clean code where its a unified 4mb where both legacy and segwit can be side by side under a unified single merkle to allow more transactions in the full 4mb space will require undoing the cludge (technical debt)

---

for instance in 2016 when core was a simple blocksize=1000000
it was much easier to move to blocksize=2000000 blocksize=4000000 blocksize=8000000 without affecting other area's of code much

but the way they patched segwit together with the max block weight = 40000000 witness scale factor = 4
(1mb base 3mb witness=4mb)
its not simple to go to: max block weight = 80000000 witness scale factor = 4
(2mb base 6mb witness=8mb)
because the cludge of the other parts of the code then has to be changed too, in many places..

however undoing the cludge to have a unified, simplified blocksize=4000000 which yes will take rewriting lots of area's.. will later make it easier to go to blocksize=8000000.. but before even going to 8mb will help more transactions utilise the 4mb space in the unified blocksize=4000000

and yes while they are at it cleaning the code up. they can put conditions on the opcodes to not allow full blocksize wastage per script(witness)

LN subnetwork is too flawed and even proven and admitted so by LN devs themselves..
im sure for the niche that want microtransactions should start afresh and build a subnetwork that can meet its promises and learn from LN mistakes.. but users wanting microtransactions should not be looking towards LN as their saviour.. its not the solution that was promised. not matter how much they utopian dream advertise it is

millions of users have looked at LN seen its failures and decided to use other subnetwork bridges for microtransactions.. its time LN devs go back to the drawing board and learn from the mistakes

just look at DCG who was a big sponsor of blockstream(core+LN devs) to do what they did(segwit as gateway key to LN) to push to create LN. but now 6 years later if you look at DCG portfolio of sister companies and look at how LITTLE of them actually advocate and use LN. just shows even they dont see it as a ready to use product they paid for. EG  if you need to ask why coinbase(dcg sister) doesnt use LN.. you already know the answer