You're running a full node on modest hardware and one morning the chainstate database ticks past 3 GB. Not the blockchain. Not the transaction history. Just the live balance sheet, every unspent output Bitcoin has ever produced that nobody has claimed yet. It keeps growing. You didn't do anything wrong. That's just what the network looks like from the inside.

That growth is not uniform. It is shaped, very specifically, by which kind of output scripts people use. Script types are the tires of the network, not the engine. Nobody discusses them until something wears unevenly.

What a UTXO Actually Costs the Network

Every unspent transaction output lives in every full node's chainstate until someone spends it. That's not a blockchain storage problem. It's a RAM-adjacent problem. Bitcoin Core loads the chainstate into a memory-mapped LevelDB database, and the more UTXOs exist, the more resources every node on earth expends just to validate new transactions.

Two dimensions matter: the byte size of storing the entry, and the likelihood it ever gets spent. A tiny output sent to a legacy address and forgotten is cheap to create and permanently expensive to carry, like a parking ticket that the whole city pays to file.

Current estimates put the UTXO set north of 80 million entries. That number moves with user behavior, fee pressure, and, critically, script type adoption.

P2PKH, P2SH, and Why Legacy Scripts Breed Dust

Pay-to-Public-Key-Hash, the format behind addresses starting with `1`, stores 25 bytes in the scriptPubKey and requires a 107-byte input to spend. Manageable. But P2PKH became dominant during a period when fees were negligible, which meant outputs of 546 satoshis or less were economically rational to create and irrational to spend.

Dust is the right word for these. Outputs whose value is less than the fee required to include them in a spending transaction. Bitcoin Core's dust threshold for P2PKH sits at 546 satoshis; below that, the protocol won't relay a transaction that creates one. Above it, millions exist that will never be economically worth sweeping. They just sit there. Forever.

P2SH, addresses starting with `3`, introduced a different problem. Because the redeem script is only revealed at spend time, you can hide arbitrarily complex multisig logic inside what looks like a compact 23-byte output. That sounds efficient. In practice, P2SH enabled large-scale exchange hot wallets to produce enormous numbers of change outputs, many small, many consolidating only when fee pressure forced it.

Here's a concrete example of what that looks like. Two wallet operators, Maya and Tariq, ran exchange hot wallets with similar volumes over the same period. Maya's team batched outgoing payments into single transactions with multiple outputs and swept change during low-fee windows. Tariq's team sent payments individually and let change accumulate. After eighteen months, Maya's wallet held roughly 800 UTXOs. Tariq's held over 14,000. Same business volume, different UTXO hygiene. The network carried Tariq's mess for free, and that cost was distributed across every full node globally. I find that arrangement genuinely unfair, and I think the protocol should eventually price it that way.

SegWit's Partial Fix and the Witness Discount

SegWit introduced a discount on witness data. Spending a P2WPKH output, the native SegWit `bc1q` format, costs roughly 68 virtual bytes in witness data versus the full 107 bytes for P2PKH. That discount makes consolidation cheaper, which nudges rational actors toward spending small outputs rather than abandoning them.

The discount applies to spending, not to creation. Creating a P2WPKH output costs 31 bytes in the scriptPubKey, slightly more than P2PKH's 25. So SegWit marginally increased creation cost while reducing spending cost. The net effect on UTXO growth depends entirely on whether users actually consolidate. When fee markets are quiet and people do consolidate, SegWit helps. When fees spike and consolidation stalls, the UTXO set grows regardless.

P2WSH, the SegWit multisig equivalent, has a 34-byte scriptPubKey. Larger at creation, but the witness discount on spending is substantial for complex scripts. For a 2-of-3 multisig, spending via P2WSH saves roughly 100 virtual bytes versus P2SH. Over millions of transactions, that number is real money.

Taproot Changes the Long-Run Arithmetic

P2TR does something structurally different from everything before it. Its scriptPubKey is a flat 34 bytes containing an x-only public key. Slightly larger than P2WPKH at creation. But the key insight is key-path spending: if all parties in a multisig or contract agree, the spending transaction looks identical to a single-signature spend. A 2-of-2 Lightning channel close, a 3-of-5 institutional wallet, and a simple personal payment all produce the same 57.5-vbyte input on-chain when using key-path.

That uniformity matters across time horizons in two ways. First, it makes consolidation cheap enough that there's less economic incentive to strand small outputs. Second, complex contracts don't leave exotic, hard-to-identify UTXOs in the set. Every key-path spend is clean and compact.

The honest caveat, and I think this gets underplayed in Taproot advocacy: script-path spends, when key-path isn't available, can be more expensive than equivalent P2WSH transactions. A complicated fallback script revealed on-chain costs real vbytes. Taproot is cheaper in the common case and potentially more expensive in the adversarial case. Protocols that anticipate spending the script path should benchmark both routes before committing.

The Part That Compounds Quietly

The UTXO set doesn't shrink automatically during bull markets. It tends to grow then, because high prices bring new users who receive outputs without yet having reason to consolidate, and because high fees paradoxically strand small outputs that become too expensive to move.

Script type adoption shifts this dynamic only at the margins in the short term. Over a decade, though, the difference between an ecosystem that defaults to P2TR key-path and one that defaults to P2PKH is potentially tens of millions of UTXO entries. Tens of millions of database rows every full node carries indefinitely.

So: have you checked your own wallet's UTXO count lately? Under 50 entries after years of receiving payments means you're in decent shape. Over 500 from unconsolidated change means you're the Tariq in this story, quietly inflating overhead for every node operator on earth, not just yourself.

Script types are a collective action problem wearing a technical costume. The choice any single wallet makes looks trivial. The aggregate of those choices is the size of the ledger the entire network has to maintain, not for a year, but for as long as Bitcoin runs. That's not a scaling debate. That's a hygiene one.