the scaling issue, is a disk issue, we use to host bitcoin nodes and 40gigabytes was fine but when it goes over 100gb and up to 150gb then its a hosting
problem , meaning the network will be smaller cuz less stuff running on raspberry pi'es and other cheap hardware, what u need is a good way to verify transactions without saving them
It's problem for initial sync, not on-chain scaling as old/cheap hardware can run full nodes smoothly (assumed they have big HDD capacity)
what u need is a good way to verify transactions without saving them
How can we verify that you truly own the bitcoin if we don't have a history of past transactions?
I think he's talking about pruning, but this still require you download all blockchain, verify all block/transaction, record UTXO on chainstate and remove older blocks. But this isn't real solution against increasing blockchain size problem.
Those two are related imo. If we increase block size & time, the size of blockchain will definitely get bigger and probably cause some kind of centralization too in terms of who store the blockchain. We need to find a way where we can verify more transactions without increasing the block size too much, which Segwit did. CMIIW.
I have to agree that both are related, there are many solutions to the scalability issue and one of them (but not the best) is increasing block size. Now, the blockchain size issue is not that urgent especially with the fast growth of the technology industry (high Internet bandwith/ storage devices) or we can simply refer to Satoshi recommendation since all of this is his idea in first place:
as the network grows beyond a certain point, it would be left more and more to specialists with server farms of specialized hardware. A server farm would only need to have one node on the network and the rest of the LAN connects with that one node.
https://satoshi.nakamotoinstitute.org/emails/cryptography/2/There are better solution such as :
1. Move transaction to off-chain/side-chain (such as LN and Plasma)
2. Reduce transaction size (such as MuSig:Schnorr and MAST)
3. Reduce bandwidth used when propagate transaction/block (such as Minisketch)
Increasing block size is needed, but IMO we shouldn't use it as 1st option.