| Method | Description | Pros | Cons | Pruning Ease | |-------------------------|--------------------------------------------------------------------------|----------------------------------------------------------------------|----------------------------------------------------------------------|----------------------------------| | `OP_RETURN` | Stores data in unspendable output, up to 80 bytes. | Standard, no UTXO set bloat, designed for pruning | Limited to 80 bytes, fees, may not persist in pruned nodes | High: Prunable post-validation | | Dust Transactions | Small, unspent outputs with embedded data, often left unspent. | More data than OP_RETURN, persistent until spent | Bloats UTXO set, higher fees, seen as spam | Low: Stays in UTXO set until spent | | Address Encoding | Encodes data into Bitcoin addresses, ~17 bytes. | No BTC spent, specific use cases | Very limited size, non-standard, custom handling | Medium: Prunable if unspent | | Storing Hashes | Stores hash (e.g., 32 bytes) on-chain, often via OP_RETURN, data off-chain. | Efficient, low cost, no UTXO set bloat | Off-chain data risks, accessibility issues | High: Prunable like OP_RETURN | | Non-standard Transactions | Non-standard transaction types to embed data, not widely supported. | Flexible storage | Unsupported by many nodes, seen as spam, may be removed | Variable: Depends on UTXO set impact | **Citations:** - [Bitcoin Stack Exchange: How to store data on the blockchain](https://bitcoin.stackexchange.com/questions/39347/how-to-store-data-on-the-blockchain) - [GeeksforGeeks: How to store data in blockchain](https://www.geeksforgeeks.org/how-to-store-data-in-blockchain/) - [Merehead: How to use blockchain to store data](https://merehead.com/blog/how-to-use-blockchain-to-store-data/) - [jSign: Storing documents with blockchain](https://www.jsign.com/blog/storing-documents-with-blockchain) - [malcoded.com: Storing data on the blockchain](https://malcoded.com/posts/storing-data-blockchain/)