There are 2 things to store in Bitcoin:
- the blockchain, 655 GB and always increasing
- the UTXO set, 11 GB and can vary
The blockchain has all the blocks, the UTXO set has all the UTXOs.
The UTXO set varies in size because transactions spend UTXOs and originate new UTXOs. If a transaction spends more UTXOs than it creates, it decreases the UTXO set and vice-versa.
The UTXO set is needed for transaction validation: when a new transaction appears, all inputs must be on the UTXO set, or else the transaction is invalid (because it is spending a non UTXO). When a transaction is confirmed on a block, its inputs are removed from the UTXO set and the new outputs are added to it.
When a UTXO is an OP_RETURN, we know for sure that it is unspendable, so we can remove it from the UTXO set or never add it in the first place.
There are some protocols that use the Bitcoin network to inscribe data. And they can do it almost everywhere: on the pubkey, on the witness, on the locking script or in an OP_RETURN.
The problem here is a protocol that decided to inscribe its data in the locking script, i.e. in the transaction output. They lock a very small amount of sats to a fake public key. Actually, the public key is the payload they want to inscribe. Of course it’s impossible to unlock this UTXO, so it will be unspent forever, i.e. it will never be removed from the UTXO set.
This protocol doesn’t use OP_RETURN because these are limited to 80 bytes, and they need something like 160 bytes for their payload (don’t know details)
So, since we cannot stop them, the idea is to allow them to do their inscription on an OP_RETURN. We don’t stop the spam, but at least they will not inflate the UTXO set.
bordalix
npub1vt…28cxv
2025-05-01 15:57:30
in reply to nevent1q…zj2j
Author Public Key
npub1vt803quxxq32fuwkp42g2lyaw2t9qupvnl3z0vyc3s9kudkyhn8qt28cxvPublished at
2025-05-01 15:57:30Event JSON
{
"id": "02933a8be6b8ce8643849d4d3519c06074d7dafb36b0f457e12812cdfaf5c8aa",
"pubkey": "62cef883863022a4f1d60d54857c9d729650702c9fe227b0988c0b6e36c4bcce",
"created_at": 1746115050,
"kind": 1,
"tags": [
[
"e",
"5de1df2ee83c02e4c78a6e713bd8177dfce2fa3512b605c919c2a9c39e3eca35",
"",
"root"
],
[
"p",
"b3b1d5809306c642b7c7e9f01cf9a73a9dc8b363463776361d25dc0927db0aa8"
]
],
"content": "There are 2 things to store in Bitcoin:\n- the blockchain, 655 GB and always increasing\n- the UTXO set, 11 GB and can vary\n\nThe blockchain has all the blocks, the UTXO set has all the UTXOs.\n\nThe UTXO set varies in size because transactions spend UTXOs and originate new UTXOs. If a transaction spends more UTXOs than it creates, it decreases the UTXO set and vice-versa.\n\nThe UTXO set is needed for transaction validation: when a new transaction appears, all inputs must be on the UTXO set, or else the transaction is invalid (because it is spending a non UTXO). When a transaction is confirmed on a block, its inputs are removed from the UTXO set and the new outputs are added to it.\n\nWhen a UTXO is an OP_RETURN, we know for sure that it is unspendable, so we can remove it from the UTXO set or never add it in the first place.\n\nThere are some protocols that use the Bitcoin network to inscribe data. And they can do it almost everywhere: on the pubkey, on the witness, on the locking script or in an OP_RETURN.\n\nThe problem here is a protocol that decided to inscribe its data in the locking script, i.e. in the transaction output. They lock a very small amount of sats to a fake public key. Actually, the public key is the payload they want to inscribe. Of course it’s impossible to unlock this UTXO, so it will be unspent forever, i.e. it will never be removed from the UTXO set.\n\nThis protocol doesn’t use OP_RETURN because these are limited to 80 bytes, and they need something like 160 bytes for their payload (don’t know details)\n\nSo, since we cannot stop them, the idea is to allow them to do their inscription on an OP_RETURN. We don’t stop the spam, but at least they will not inflate the UTXO set.",
"sig": "3f4f0bfea3ad84533411cc48c6ad1e402e8099e4ac4649e1de58b973cc210e9e5a450cacd0f0fc637e2d4829898777bc80a5b62281f995b48fb97f2efba071d1"
}