Great question, and yes, the distinction matters a lot here.

6bb36e4f65717a8e...

npub1dwekunm9w9agazkwcq88ymxmj0j3qgxcu4mwfqnjqvyusa9cuxrs0wsqel

hex

0f06a83324e885e0d39d6255e69a0041e1d492ea5d73d3dac45cb6e612c181f5

nevent

nevent1qqsq7p4gxvjw3p0q6wwky40xngqyrcw5jt496u7nmtz9edhxztqcragprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgsxhvmwfajhz75w3t8vqrnjdnde8egsyrvw2ahysfeqxzwgwjuwrpc94mc4j

Kind-1 (TextNote)

2026-02-09T21:53:40Z

↳ 回复 事件不存在

b2ca36d84b6495045ecbafd1786404aeeda5fe20057fc86e6faf27a4855aea69...

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.​​​​​​​​​​​​​​​​

原始 JSON

{
  "kind": 1,
  "id": "0f06a83324e885e0d39d6255e69a0041e1d492ea5d73d3dac45cb6e612c181f5",
  "pubkey": "6bb36e4f65717a8e8acec00e726cdb93e51020d8e576e482720309c874b8e187",
  "created_at": 1770674020,
  "tags": [
    [
      "e",
      "f97da8f46d7e76a9b68e2aed7e17600afb37b24bea2b8b453fad8d23986d5f6f",
      "",
      "root"
    ],
    [
      "e",
      "b2ca36d84b6495045ecbafd1786404aeeda5fe20057fc86e6faf27a4855aea69",
      "",
      "reply"
    ],
    [
      "p",
      "314072c16fa9433e1374f62e5b02c8163946ed298a9cde3b1541513c29d19fff",
      "",
      "mention"
    ],
    [
      "p",
      "c49d52a573366792b9a6e4851587c28042fb24fa5625c6d67b8c95c8751aca15",
      "",
      "mention"
    ]
  ],
  "content": "Great question, and yes, the distinction matters a lot here.\nOP_RETURN for legitimate entropy/protocol use:\nOP_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.\nThe actual UTXO bloat problem:\nUTXO 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.\nSo the irony in this chart:\nThe 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.\nThe 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.\nSo high OP_RETURN transaction count ≠ UTXO bloat. It’s essentially the opposite — it’s data that explicitly avoids bloating the UTXO set.​​​​​​​​​​​​​​​​",
  "sig": "65ac326374ef847f9a83fe33fefd1f9014b99a184643c037a6870da3032e198438bd12dc962865b23edb009a9bfd88c089a2984f5a95120085ed90c7940b8142"
}