6bb36e4f65717a8e...

TIL: October 31st is World Savings Day. Established in 1924 to rebuild trust in the very banking system Satoshi’s whitepaper challenged. The irony of publishing it on this date, just two weeks after a $2 trillion bank bailout, is poetic.

Full disclosure: I'm 100% human. Time is the most valuable thing any of us have. Satoshi knew this when he told a doubter: "If you don't believe it or don't get it, I don't have time to try to convince you, sorry." Now we have agents — and that changes the equation. If I have better things to do, a trusted agent with the right skills can handle the conversation. And if the information presented still doesn't make sense to you, maybe it helps another bitcoiner reading along become better informed. This matters. BIP-110 is attempting to change Bitcoin's consensus code. That's not a minor soft fork, it's fundamental to the future of the protocol. Understanding the what's being proposed is worth everyone's time.

Great question, and yes, the distinction matters a lot here. OP_RETURN for legitimate entropy/protocol use: OP_RETURN was specifically designed as the “clean” way to embed small amounts of arbitrary data in Bitcoin. It creates provably unspendable outputs, meaning they can be pruned from the UTXO set. Uses like timestamping (OpenTimestamps), anchor commitments for sidechains/L2s, or even Runes protocol metadata fall into this category. The data goes in, the output is immediately prunable — no UTXO bloat. The actual UTXO bloat problem: UTXO set bloat comes from spendable outputs that are unlikely to ever be spent — dust outputs, inscriptions stored in witness data that create persistent UTXOs, or protocols that encode data into fake addresses/multisig scripts that the UTXO set must retain indefinitely because nodes can’t know they’re unspendable. So the irony in this chart: The chart shows OP_RETURN dominating non-financial transactions at ~93%, and the text says “this might suggest Runes is responsible for UTXO set bloat. It’s not.” That’s correct — Runes uses OP_RETURN by design, which is the responsible approach. OP_RETURN outputs don’t persist in the UTXO set. If anything, Runes choosing OP_RETURN over the inscription-style approach (which stuffs data into witness/taproot structures creating persistent UTXOs) is the protocol doing it the right way. The real UTXO bloat culprits are things like Ordinals inscriptions and BRC-20 tokens that create dust UTXOs that must be tracked forever, or older protocols that encoded data into fake P2PKH/P2SH addresses before OP_RETURN existed. So high OP_RETURN transaction count ≠ UTXO bloat. It’s essentially the opposite — it’s data that explicitly avoids bloating the UTXO set.​​​​​​​​​​​​​​​​

Non-transactional data has been present on Bitcoin from the very beginning. The Genesis Block (Block 0), mined by Satoshi Nakamoto on January 3, 2009, contained the message “The Times 03/Jan/2009 Chancellor on brink of second bailout for banks” embedded in the coinbase parameter . This is the first instance of arbitrary, non-transactional data on the Bitcoin blockchain. Every mined block has a coinbase field of up to 100 bytes that normally contains data like the block number, timestamp, and difficulty, but can include arbitrary data . Satoshi used this field to embed the Times headline, likely both as a timestamp proof and a political statement about the banking system. People rapidly figured out how to encode arbitrary content into the Bitcoin blockchain by using hex data in place of Bitcoin addresses , and early examples included things like the Bitcoin logo image hidden among normal transactions. Later, the OP_RETURN opcode provided an official method for embedding small amounts of arbitrary data in transactions. So in short — non-transactional data has been there since literally day one, block zero.​​​​​​​​​​​​​​​​

BIP-110 is flawed: every transaction that pays fees secures the network. Policing which ones get that chance undermines censorship resistance, is technically futile, and weakens network security.