Quote from: vjudeu on Today at 12:16:18 PM

I already did

That's my definition of scaling as well, but I was more concerned about the linear growth. What's your opinion about growing linearly?

Responding to your mail:

Quote from: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019988.html

Since Taproot was activated, we no longer need separate OP_RETURN outputs to be pushed on-chain. If we want to attach any data to a transaction, we can create "OP_RETURN <anything>" as a branch in the TapScript. In this way, we can store that data off-chain and we can always prove that they are connected with some taproot address, that was pushed on-chain. Also, we can store more than 80 bytes for "free", because no such taproot branch will be ever pushed on-chain and used as an input. That means we can use "OP_RETURN <1.5 GB of data>", create some address having that taproot branch, and later prove to anyone that such "1.5 GB of data" is connected with our taproot address.

The problem with this is that OP_RETURN is often viewed as a way to store the message indefinitely. But, I agree that it can work, if your purpose is not to store arbitrary data on-chain.

Quote from: stompix on Today at 12:49:27 PM

Stompix himself, in his great wisdom wanted the block doubling since before the last having, and when I said doubling I meant that it would have been already doubled by now and we would be looking in the future for another one, so 4MB or a maximum theoretically size of 16.

Alright. In the present epoch, it's 16. In the subsequent epoch, it's 32, then 64, then 128, and so on. Do you understand that the on-chain volume doesn't escalate at the same pace, ensuring the system's sustainability? What's your plan for 25 years ahead, when the block size surpasses 1 GB, there's no competition in the fee market, and Bitcoin will inevitably come to an end?