It was expected (again, as stated in the whitepaper) that truncating transactions (in order to shrink blocks that are "old enough") would be able to manage block size well enough to stay reasonable.
In my experience (circa ~2011,) this expectation seemed to be generally accepted without much question by anyone talking about bitcoin. If it was acknowledged as a flaw it was usually hand-waved as only likely to be a problem 10+ in the the future.
edit: Or that a new network would learn from the bitcoin experiment and implement a protocol that works better at large scale.
In the original bitcoin software a node would receive every transaction made while it was online twice: once when the transaction was first relayed, once when it was placed into blocks. This was obviously wasteful, so we created and deployed a reconciliation scheme that exploits the fact that normally all, or almost all the included transactions are already known. https://github.com/bitcoin/bips/blob/master/bip-0152.mediawi...
But because Bitcoin developers are not dishonest scammers they didn't run around putting out (no kidding) press releases claiming "98.6% compression"-- though that's what you get if you compare the size of the BIP152 message to the size of the block. In reality, since it depends on the transaction being known in advance the unachievable limit for this class of approaches is a 50% bandwidth reduction for a node compared to the original behaviour. BIP152 achieves 49.3% out of that 50%, as measured on the latest block.
Even before compact blocks was created back in December 2015, we knew even smaller could be achieved. E.g. we published a scheme that requires asymptotically 0 bytes per transaction, only requiring data proportional to size of the difference between the block and the recipients guess at the next block. But what we found is that the simpler scheme actually propagated blocks much faster because once the block is down to just a few thousand bytes other factors (like CPU time) dominate. Expending a lot of additional code and cpu time to take 49.3% closer to 50% isn't a win in actual usage.
[And for considerations other than block propagation, saving a few extra bytes per block is extremely irrelevant.]
It's also the case that some of these dishonestly hyped supposed improvements beyond what Bitcoin has done for years are actually totally brain-damaged and wouldn't work in practice because they're not robust against attack-- but there isn't much reason to dive into technical minutia because what they _claim to achieve_, once you strip off the dishonest marketing, isn't all that interesting.
The only explanation I can think of is that they are relying on a sidechannel to communicate the actual transactions, which makes sense in the miner case (the utxo pool) but not in the general node case.
Beyond that, I run a BTC node occasionally and the bottleneck is validating blocks, not downloading them. Transactions are complicated enough right now that I'm only able to catch up at about 350x real-time (that is, it takes around a full cpu-day to validate a year of blocks/transactions).
Can you provide links to these discussions? I searched around on google and all the results are relating to bitcoin cash. I also searched the usual places that bitcoin (non cash) people congregate and turned up nothing.
Stop with the storage space nonsense. The only people even storing the entire chain are enthusiasts, servers and miners. Saying "what if it gets a thousand times as many transactions" is ridiculous, but it still wouldn't be a problem. A few gigabytes a day? A $300 dollar hard drive would still take a decade to fill up. I think the few that sync the entire chain handle that.
Aside from that, people figured Moore's Law would continue at its historical pace, and Bitcoin could grow indefinitely at the same pace.
