pull down to refresh

I think the big disconnect is that most normies don't know what the UTXO set size is, they only understand "block size."
To put it simply, the size of the blockchain (i.e., the total size of all blocks) only affects the initial sync time when setting up a node from scratch. This can grow by a maximum of 4MB per block (realistically around 2MB).
In theory, you need to sync a node from scratch only once in your lifetime... for new nodes, you can skip the sync by downloading a UTXO Set then verifying that your new node has the same UTXO Set hash as one of your older nodes.
You DO NOT NEED to store all the blocks, nor should you, unless you have a pretty good reason.
So, optimizing blockchain size does not significantly reduce the minimum resources required to run a node. At best, it slightly reduces bandwidth usage. If you do store all the blocks, due to current consensus rule, you should anyway plan for a 2MB per blocks increase for planning your hardware upgrade.
More important than the blockchain size, it is what everyone MUST store: The UTXO set size.
Developers care far more about the size of the UTXO set because it determines the minimum storage required to run a full node. (A "full node" means you verify all blocks, not necessarily store them all.)
The UTXO set used to be around 4GB. Due to inscriptions and BRC-20, it has grown to about 12GB.
The UTXO set does not store OP_RETURN data or signatures.
If you want your node to keep running smoothly on small devices, focus on minimizing the UTXO set size, not the blockchain size. And this is why, lot's of devs don't really care about OP_RETURN limits.
11 sats \ 2 replies \ @kepford 3h
And this is why, lot's of devs don't really care about OP_RETURN limits.
I don't have a strong opinion on the current spat about this in Core and on X but the way many are acting about it... as if the sky is falling is kinda weird to me. I've listened to people on both sides and read about it. Maybe I'm just blissfully ignorant still but these people seem to be more emotionally invested than is actually needed.
I know how many bitcoiners are... doesn't surprise me. Par for the course I guess.
reply
we have too many influencers in bitcoin and few people that use REASON to come to a conclusion. Also many like morbidity and drama. I like the memes :)
reply
0 sats \ 0 replies \ @kepford 2h
Its just gonna get worse I think.
reply
0 sats \ 1 reply \ @OT 6h
This is the first I've heard of this.
Where in bitcoin core can I see info about the UTXO set?
reply
You can use BTC RPC Explorer on your node with https://github.com/janoside/btc-rpc-explorer or here public instance https://bitcoinexplorer.org/utxo-set I think BTC RPC Explorer is a very underated tool for node runners. or The bitcoin listunspent rpc call does that
reply
0 sats \ 1 reply \ @Jerrian 1h
Absolutely spot on this is a critical distinction that often gets overlooked. The obsession with "block size" misses the deeper issue: it's the UTXO set that dictates the ongoing resource burden of running a node, not the historical chain size. A bloated UTXO set increases RAM and I/O requirements every time the node validates new transactions not just during initial sync. This is why devs are much more concerned about things like dust outputs and BRC-20s than about OP_RETURN junk. If we want Bitcoin to remain decentralized and verifiable by everyday users on modest hardware, keeping the UTXO set lean is far more important than trimming megabytes off old block data.
reply
STFU bot
reply
I run full node and I also care about blockchain size, currently: Size On Disk 748174232169
reply