SCALING is not a one time "just a little" its not a one time "alot".
 its a long run of progressive steps..
you solve the long run by doing the long run.. one foot infront of the other..

we dont need 1gb blocks today.
today we can fix the issues of the 4mb block bloat, spam, its badly utilised 3mb witness segregation space offset.  to allow more transactions to actually get to potentials of 16k transactions instead of stuck at averages under 4.2k. without adjusting more then 4mb..
then move to 8mb  and at later date progress again. and more later to progress again..
one step infront of the other.. step by step
.. this is literally the meaning of scaling..  the long run

all the other detractors/objectors talking about needing to high jump now to solve the long run later..(facepalm)
all the other detractors/objectors talking about a high jump cant happen now so lets do nothing at all..(facepalm)
all the other detractors/objectors completely ignoring/avoiding/ twist/lie about discussion of SCALING (facepalm)

even though 99% of transactions are relayed/broadcast PRE CONFIRM so the "4mb" block limit is not actually "4mb" sent in one go anymore
but lets say it was.. heck lets say it was 10mb

10mb10min = 1mb/min = 16kb/sec
a 10mb block is less data than dial-up

those in africa who dont live near cabled internet use 4g/5g cellular, which they 'hotspot' to a PC
millions of africans livestream, watch tv and game via 4g/5g..

do you think netflix (data of gigabytes an hour to users) said "lets not start a business because customers cant handle gigabytes an hour"

as for the initial block download.. things can be done about the user interface of things like core to not be a splash screen telling people to wait to sync-up, when people just want to generate an address to get started, many things can be done to make that a better user experience. not just the user interface but also the underlying download process

1. Sidechains: blocks can be big and small at the same time, if you have two-way-peg. Then, you decide, what you want, by making signatures.
2. Cut-through: if you have Alice->Bob->Charlie transaction chain, then you need to store only Alice->Charlie. If you have long unconfirmed transaction chains, you can batch it. If you have to show someone, that Bob was inside, then you can do so through commitments.
3. Scanners: if some data is already pushed on-chain, then you can create a scanner, that would locate it in already existing chain, instead of pushing it again, like some user, who tried to push the whitepaper again, but as an Ordinal this time (ignoring the fact, that it was already pushed long time ago with some multisig).
4. No-fork compression: you can compress things in any way you want, and stay compatible with the existing network, as long as you decompress things before sending to old nodes. If it will be standardized, then new nodes will have better performance, so people will upgrade soon.
5. Commitments: you don't have to push big data on-chain. In many cases, all you need is just proving that a given data existed on a given time, and just use Bitcoin as a timestamping server. Commitments can be used to do that, and it will cost no additional on-chain bytes.

Should I continue? Or maybe there are some questions? Coming up with some new idea is not that hard. The most difficult part is turning all of that into code. And this is what I am trying to do. One of my experimental project assumes that everything is P2PK-only, and is fully commitment-based (I don't have to care about things, that are not OP_CHECKSIG-based, because they can be easily simplified into OP_TRUE; also you cannot use a coin in any real-life scenario, without using any public key). Maybe that could make Initial Blockchain Download faster? We will see, if I will manage to do that; after all, it is also very likely to merge my ideas with someone else, than to release it alone.

It is a matter of time. Note that with each and every halving, the basic block reward is getting smaller and smaller. So, we will eventually reach a point, where those pools would have a choice: convince miners to work for free, or lose them. Because the basic block reward will eventually be zero, and that would force those pools to change their rules.

This is not trustless. If we could do that, then it would be possible to make it a consensus rule. For example: only the last 210,000 blocks are stored, and the rest is automatically marked as valid. Which means, if some bug remain unnoticed for 4 years, it is then set in stone, and cannot be fixed by any chain reorganization.

Which means, in that case, it would allow us to have "const storage client". Then, you could multiply for example 210,000 blocks by 4 MB, and guarantee, that 840 GB is sufficient to run your node. Of course, UTXO set is also important, so it would be potentially bigger than that, but that approach would just mean, that pruning could be set for example to 210,000 blocks, and consensus could enforce it.

Another consequence is that new nodes would start synchronization from 210,000 blocks in the past (or would start from the latest block, and process it backwards), and check only the last N blocks. And then, the whole model should be more UTXO-based, because in your scenario, you have to also somehow remember, which coins were created for example 10 years ago, and were not moved in the last 4 years, (so they are still valid, and should not be dropped).

its not about starting a sync from block 210k(your example) its about all blocks from 0 forward are downloaded still..  but no transaction validation is done they are just treated as valid and put/taken from utxoset depending if sent or spent..  but all blockdata is stored, just less validations done on earlier blockdata
however code is a great thing and many things can be done. such as locking in a UTXOset image of the position of the 420k block where by we hash the utxoset at that position and put the hash into coinbase reward output and when nodes match their own matched-set to not reject block. then after time of having this hash locked in. the utxoset becomes a ball of data of unspent history to not need the TXdata previous due to milestoned depth agreeing the immutable data is soo deep that a re-org of that magnitude would be more of a risk event in of itself

some are calling this a ball and chain 0-420k ball of utxo and chain of 420,001-now
ofcourse the block headers and txid tree of 0-420k still remain to show the tx of the utxoset did exist in said block

code can do many great things

What you're proposing is actually an ingenious solution and reminds me of AMD's x86-64 architecture 20+ years ago.

What did AMD do? They took Intel's i386 proven architecture (despite not being perfect, especially compared to RISC behemoths) and extended it (double register width + double the amount of registers).

You can operate an AMD64 processor in various ways (legacy i386 or 64-bit mode or even 16-bit mode for DOS apps)!

On the other hand, Intel invented Itanium (a brand new, clean slate architecture) and it failed miserably. Eventually they were forced to copy AMD's approach.

What's the lesson here for IT-minded folks?

I'm honestly surprised we have this kind of discussions in the Bitcoin community... I'm really curious to know the professional background of big blockers, if they have any.

Something tells me they have almost zero IT experience, which explains their fallacious arguments...

This is a wrong take, because one-block chain reorganization is something that can happen, no matter how high hashrate the network will reach. However, 210,000 blocks chain reorganization is something that never happened.

Also, there is a reason, why we have coinbase maturity, set to 100 blocks. If you don't agree with protecting the last 210,000 blocks, then what about last 100 blocks?

Another place when there is such assumption, is pruning: you cannot prune the last 288 blocks. So, what about 288, if 100 is not enough? Or maybe 2016, to align it with difficulty adjustments, and compress those four bytes, that are mostly identical during those two weeks?

So, if protecting a single block would be enough, then we wouldn't have coinbase maturity (100 blocks) or minimal pruning level (288 blocks, which means around 2 days).

Note that by doing things in this way, you open a potential gate in the future, to disable SegWit, or other soft-forks. It is up to you to decide, if you want that. But yes, it is possible, and can be easily achieved, for example by just running some old client. And yes, that famous block with almost 4 MB witness, is very small, if you have non-Segwit client.

As far as I know, increasing witness is incompatible with old nodes. You cannot change 4 MB into 32 MB, just by changing a single constant. It is consensus-level change, which means, you need a second witness to make it compatible. Which means, you probably need commitments, that can be used on legacy, witness, or whatever, and can be increased or decreased at will. In other cases, you will end up with more than one witness, and people will complain, that your code is convoluted.

maybe read a lil