Is this really the direction that we want to take or do we have no other choice? I think I have seen some altcoins proclaim themselves to have solved scaling, but they have implement something similar but probably less comprehensive. They just keep some part of the blockchain history, and only a few archival nodes contain the rest. What are your observations on that, have you seen developers indicating that they would like this future or not?
Well there are two possible approaches:- not keeping anything about the old history, only the UTXO set and a few days or weeks of current blocks. Such as the mini-blockchain scheme or Kaspa.
- keeping a record of the old history, but in a very compressed form. This is how I understand the ZeroSync approach.
The first option indeed isn't what I would like for Bitcoin. And if we advance into systems like Utreexo where the UTXOs are normally kept by the involved parties, some nodes that know about the old history should still exist if the UTXO get lost. While you could argument that you should keep your UTXOs safe like your private keys, it's practically different above all for offline storage, as UTXOs would have to be stored too, alongside seed phrases or raw keys. You would have to print or annotate a lot of data on your paper offline storage.
But what I think I can assure is that there's no "systemic" need for archival storage of data outputs (OP_RETURN and fake public keys). So even the archival nodes that only want to "help Utreexo users who lost their UTXOs" can discard a lot of data, and just the data which may be "risky" if they fear to store any illegal stuff.
However the good thing is that the Bitcoin blockchain grows slowly and thus storage costs even for the whole chain are not high. While we have currently a SSD bubble due to AI demand, I guess in 1-2 years the prices for storage will again go down. Many nodes could opt to sync with ZeroSync but later re-download the whole blockchain, just to stay even safer. And if there's really scarcity of archival nodes eventually, they could take money for the service (i.e. for those Utreexo users who lost the UTXOs) and that would again ensure incentives are there.
I don't think storage is a really big issue, you can find a 2 TB SSD right now for like $200 which would be enough for a long time with the current capacity of Bitcoin. I don't think we need to be maximalists in node costs that is try to make it crazy inexpensive when everything in the world is very expensive these days. Depending on the region just a single Netflix subscription will almost cost the person the same amount as this SSD. I don't think we need to be extreme in this anymore, but a reasonable low cost is good enough. If you look at the other side at things like Solana, the costs to run it are maybe 1000 times higher. It is crazy!However the good thing is that the Bitcoin blockchain grows slowly and thus storage costs even for the whole chain are not high. While we have currently a SSD bubble due to AI demand, I guess in 1-2 years the prices for storage will again go down. Many nodes could opt to sync with ZeroSync but later re-download the whole blockchain, just to stay even safer. And if there's really scarcity of archival nodes eventually, they could take money for the service (i.e. for those Utreexo users who lost the UTXOs) and that would again ensure incentives are there.
I also don't think we should "suffocate" Layer 1 by "ossifying" the 4MB blocks. However, as I wrote in the previous paragraph, it's a blessing that Bitcoin's full storage requirements grow only slowly, so archival nodes would never be too expensive.
I agree with this because I know that in Ethereum and Solana the situation is very bad in requirements. I have never met a single person who holds these coins and runs nodes at all, or a fully synced client. With normal hardware it is not possible at all and these chains are quite younger. It is a blessing what we have here, with good hardware one can sync Bitcoin in a few hours without any tricks of skipping some checks like some shitcoins do.So my take on this is: If we see another congestion phase, increase the block size slowly, but via softforks (witness discount increase). 8 MB or 16 MB could be the target value for 2050 indeed. Bitcoin is 17 years old now and we saw only one block size increase (a x2 in Segwit). In 17 more years we have 2042. Until then, 1-2 similar increases like Segwit could take place. Then we have technologies like Cross-Input signature aggregation which would allow further optimizations, above all for CoinJoins (don't know if I already mentioned this in this thread).
Wait a minute, I thought that the Segwit thing was a one off. I didn't think that there was more room to increase the space using the same method more. Is there a limit to the amount of block space that can be generated this way so to say? Put other scaling limitations aside, I am interested simply in the limits of this method please. Also where do we stand on cross-input signature aggregation? I have seen this mentioned for many years now but I don't hear often of it?I made a Dune query for OP_RETURN. I've currently no data for fake pubkeys and such methods.
A quick look had as a result 940 MB of OP_RETURN data in 2025. That's honestly much less than I thought, as the blockchain grew from 627 GB to 710 GB in the same timeframe (by 83 GB), so it's a little bit over 1%. This is only the size of the outputs, but it doesn't make sense to add the change output and signature because these have to be stored for the blockchain state (the 5-30% I mentioned earlier was based on the size of the whole data transactions in mempool.space including inputs and outputs of OP_RETURN txes, but they included Taproot envelopes and other stuff).
DdmrDdmr had made a similar graph for the Ordinals Taproot envelopes here. I have updated at least the query for the weight (not sizes) by day. I will probably fork that query to have data per day and also data for the real size in MB/GB.
That is pretty low actually. Even if we considered all OP_RETURN to be complete spam which is questionable but lets go with that, then all the spam drama of last year was pointless. It has no real impact on Bitcoin at all at this time. A quick look had as a result 940 MB of OP_RETURN data in 2025. That's honestly much less than I thought, as the blockchain grew from 627 GB to 710 GB in the same timeframe (by 83 GB), so it's a little bit over 1%. This is only the size of the outputs, but it doesn't make sense to add the change output and signature because these have to be stored for the blockchain state (the 5-30% I mentioned earlier was based on the size of the whole data transactions in mempool.space including inputs and outputs of OP_RETURN txes, but they included Taproot envelopes and other stuff).
DdmrDdmr had made a similar graph for the Ordinals Taproot envelopes here. I have updated at least the query for the weight (not sizes) by day. I will probably fork that query to have data per day and also data for the real size in MB/GB.
