<blockquote>
<p>Is it possible/feasible for nodes to redact information (for example inappropriate images) in their blockchain and remain part of the network?</p>
</blockquote>
<h3>Sidenote:</h3>
<p>Although <code>OP_RETURN</code> was intended for embedding small amounts of data, I believe almost all cases of embedding of images in the last 12 months use <code>OP_FALSE OP_IF &lt;multiple data pushes&gt; OP_ENDIF</code> inside an otherwise normal script in a witness component. This avoids limitations imposed on <code>OP_RETURN</code> and gains the Segwit discount on transaction fees.</p>
<h3>Censoring transactions:</h3>
<p>Pruning nodes discard blocks that have been validated and whose content is no longer necessary for maintaining UTXO state. It must be feasible to be selective and have specific criteria to discard data that is unwanted. For Bitcoin Core I imagine it might necessitate rewriting large blockfiles or some strategy such as overwriting portions with say zeroes and updating indexes accordingly.</p>
<p>Not relaying <em>unconfirmed</em> transactions of this sort has been suggested. <em>As Michael Folkson commented, large images (e.g. several MB) already can't be relayed by Bitcoin core nodes because of its default policy rules. publishers of large images have to make direct arrangements with miners.</em></p>
<p>However, the above still requires that nodes download and validate new blocks, regardless of content, in order to maintain UTXO state. So the goal cannot be completely achieved.</p>
<p>I believe it is also computationally infeasible for normal nodes to distinguish inappropriate images from acceptable images. Furthermore, People who embed such images can take countermeasures to prevent their detection.</p>

CC BY-SA 4.0
2024-01-08T11:41:00.583Z
I'm pretty sure existing Core default policy (e.g. datacarriersize?) would already prevent the transaction you highlighted being relayed.
Michael Folkson
CC BY-SA 4.0
2024-01-08T11:55:02.067Z
Well this specific transaction wasn't paying a fee either so it definitely wasn't relayed via P2P network default policy rules. But a fee paying equivalent of that transaction.
Michael Folkson
CC BY-SA 4.0
2024-01-08T14:36:55.207Z
I can only speak for my self but downloading and validating all transaction data would be fine - it's being forced to then _knowingly_ store and host particular obnoxious data on my node that I'd be against. I'd be happy for the redaction to be manual as I can't see it being a common occurrence
evo_race
CC BY-SA 4.0
2024-01-08T14:46:15.390Z
@evo_race. I'm not a Bitcoin wallet developer but I believe it would be possible to develop a wallet that does not permanently store images embedded in this specific way. Either a new wallet or a patch to (possibly a fork of) an existing wallet. In my (completely unimportant) opinion, this *might* ameliorate the issue to a limited extent for a while and be acceptable to some as a partial solution.
RedGrittyBrick
CC BY-SA 4.0
2024-01-08T14:55:57.013Z
@Michael, many thanks for pointing that out, answer updated accordingly.
RedGrittyBrick
CC BY-SA 4.0
2024-02-06T10:35:44.970Z
@evo_race: You don't have to do anything. You don't have to verify transactions let alone store parts of them if you don't want. OP_RETURN makes it clearer that a transaction is including data whilst with some other transactions it is less clear what they are doing. If you want to do full verification you have to keep UTXOs around in case they are ever spent. But if you don't want to store OP_RETURNs or say SegWit witnesses post verification you don't have to.
Michael Folkson
CC BY-SA 4.0
2024-01-08T11:11:59.113Z
2024-01-08T15:07:21.080Z
2024-01-08T15:07:21.080Z
RedGrittyBrick
<p>So first of all this has already happened e.g. &quot;Child Abuse Content Found On Bitcoin Blockchain, Users Must Be Protected&quot; (<a href="https://cointelegraph.com/news/german-researchers-child-abuse-content-found-on-bitcoin-blockchain-users-must-be-protected" rel="nofollow noreferrer">reference</a>, Coin Telegraph).</p>
<p>If your aim is to maximize censorship resistance and restrict the ability of state authorities to prevent certain transactions from being mined then you can't prevent any consensus valid, high fee rate transaction from being mined.</p>
<p>However, the OP_RETURN limit of 80 bytes is tiny in comparison to typical image sizes that can get up to 1-2MB for a high quality photograph. So for an image (abhorrent or otherwise) the best one can do is split an image into tiny chunks and spread it across many OP_RETURNs and many transactions. There are many people who dislike Bitcoin for various reasons and would do anything to try to prevent its growth so it is inevitable that bad actors will do this. But no single transaction or even a single block can contain an entire image. It becomes somewhat farcical if you take this concern to extremes by splitting an image into say bytes and storing a single byte on every page of a website. It would be impossible to detect this and visitors to the site or hosts of the site could not be reasonably held liable.</p>
<p><strong>correction:</strong> As RedGrittyBrick points out in the comments since the SegWit soft fork it has been possible to get a &gt;2MB image into a single Bitcoin transaction and an example is this <a href="https://mempool.space/tx/0301e0480b374b32851a9462db29dc19fe830a7f7d7a88b81612b9d42099c0ae" rel="nofollow noreferrer">transaction</a> 0301e0480b....</p>

CC BY-SA 4.0
2024-01-08T10:55:36.243Z
Michael, when you write *"for an image (abhorrent or otherwise) the best one can do is split an image into tiny chunks and spread it across many OP_RETURNs and many transactions. "* were you unaware of  *"the network mined its largest block, nearly 4 MB in size, containing just 63 transactions. **One of the transactions was a 3.94 MB Ordinal inscription featuring an image of a wizard**,"* reported [here](https://news.bitcoin.com/bitcoin-records-largest-mined-block-to-date-4-mb-block-containing-nft-causes-unease-among-small-block-supporters/). Search tx for ASCII "image"
RedGrittyBrick
CC BY-SA 4.0
2024-01-08T11:08:29.213Z
https://mempool.space/tx/0301e0480b374b32851a9462db29dc19fe830a7f7d7a88b81612b9d42099c0ae
Michael Folkson
CC BY-SA 4.0
2024-01-08T11:16:34.893Z
I am having difficulty reconciling this *single* transaction containing a > 3MB image with the assertion that a < 1-2MB image must be split across *many* transactions.
RedGrittyBrick
CC BY-SA 4.0
2024-01-08T11:18:58.180Z
@RedGrittyBrick: Yeah you're right and hence my answer is incorrect. I wasn't aware that was possible. Submitted directly to a miner and not paying a fee. Starting to think that Taproot relaxation was a bad idea now :)
Michael Folkson
CC BY-SA 4.0
2024-01-08T11:29:22.510Z
For what it is worth, my opinion is that most of your answer is right and blockchain polluters will likely fragment and obfuscate objectionable content if nodes start censoring them.
RedGrittyBrick
CC BY-SA 4.0
2024-01-08T15:48:31.153Z
If you ignore policy rules, taproot didn't change anything w.r.t. embedding data. Whatever people do now to include a 2+ MB image in a transaction was perfectly legal before the taproot softfork too (it must be; if it wasn't, it would not be a softfork).
Pieter Wuille
CC BY-SA 4.0
2024-01-08T15:53:30.883Z
Thanks Pieter. Gosh it is hard to follow what relaxed limits are enabling what. I thought (mistakenly) that this transaction was using the BIP342 relaxed script limit.
Michael Folkson
CC BY-SA 4.0
2024-01-08T16:20:10.400Z
@MichaelFolkson The standard ones do, but the non-standard ones obviously aren't subject to any policy limits.
Pieter Wuille
CC BY-SA 4.0
2024-01-08T16:24:34.147Z
https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#cite_note-9 This is consensus rather than policy though right?
Michael Folkson
CC BY-SA 4.0
2024-01-08T18:23:26.680Z
@MichaelFolkson Yes, but it applies to different outputs. P2TR applies to v1 outputs, P2WPKH/P2WSH rules apply to v0 outputs. Before the introduction of P2TR one could just have used a v1 output + spend thereof, which was unemcumbered then. And even today, if one is willing to ignore policy rules, one could use (say) a v13 witness output + spend thereof. It's anyone can spend, but perfectly consensus valid (and must be, to keep it available for future softforks).
Pieter Wuille
CC BY-SA 4.0
2024-01-08T18:27:56.173Z
And even if one wants to stick to existing output types for some reason (but still not care about policy), it has since segwit been possible to create a very close to 4MB transaction (it would need to split it up in 520-byte witness stack items, or 10000-byte scripts, though, but that barely affects the efficiency).
Pieter Wuille
CC BY-SA 4.0
2024-01-08T10:12:44.650Z
2024-01-08T15:50:38.997Z
2024-01-08T15:50:38.997Z
Michael Folkson
<p>With the freedom to run nodes being critical to bitcoin's success, I'm concerned that if someone successfully writes highly inappropriate or abhorrent information/images as a valid transaction then many people will be put off running their own node and acting as a host for this content, thereby creating a threat to bitcoin as a whole.</p>
<p>I believe this issue could be successfully mitigated by allowing nodes to redact (i.e. make unavailable) select parts of the data on their blockchain. Is it possible or at least feasible for a node to do this while otherwise being able to participate fully in the bitcoin network?</p>

<blockchain><raw-data><op-return><censorship-resistance>
Is it possible/feasible for nodes to redact information (for example inappropriate images) in their blockchain and remain part of the network?
evo_race
# Is it possible/feasible for nodes to redact information (for example inappropriate images) in their blockchain and remain part of the network?

(Asked by: username_0 on 2024-01-08)

With the freedom to run nodes being critical to bitcoin's success, I'm concerned that if someone successfully writes highly inappropriate or abhorrent information/images as a valid transaction then many people will be put off running their own node and acting as a host for this content, thereby creating a threat to bitcoin as a whole.

I believe this issue could be successfully mitigated by allowing nodes to redact (i.e. make unavailable) select parts of the data on their blockchain. Is it possible or at least feasible for a node to do this while otherwise being able to participate fully in the bitcoin network?

**Tags:** blockchain, raw-data, op-return, censorship-resistance


---

## 2 answers

### Answer by username_1 on 2024-01-08. Score: 0

> Is it possible/feasible for nodes to redact information (for example inappropriate images) in their blockchain and remain part of the network?

### Sidenote:

Although `OP_RETURN` was intended for embedding small amounts of data, I believe almost all cases of embedding of images in the last 12 months use `OP_FALSE OP_IF <multiple data pushes> OP_ENDIF` inside an otherwise normal script in a witness component. This avoids limitations imposed on `OP_RETURN` and gains the Segwit discount on transaction fees.

### Censoring transactions:

Pruning nodes discard blocks that have been validated and whose content is no longer necessary for maintaining UTXO state. It must be feasible to be selective and have specific criteria to discard data that is unwanted. For Bitcoin Core I imagine it might necessitate rewriting large blockfiles or some strategy such as overwriting portions with say zeroes and updating indexes accordingly.

Not relaying *unconfirmed* transactions of this sort has been suggested. *As username_2 username_2 commented, large images (e.g. several MB) already can't be relayed by Bitcoin core nodes because of its default policy rules. publishers of large images have to make direct arrangements with miners.*

However, the above still requires that nodes download and validate new blocks, regardless of content, in order to maintain UTXO state. So the goal cannot be completely achieved.

I believe it is also computationally infeasible for normal nodes to distinguish inappropriate images from acceptable images. Furthermore, People who embed such images can take countermeasures to prevent their detection.

> **Comments:**
> **username_2**: I'm pretty sure existing Core default policy (e.g. datacarriersize?) would already prevent the transaction you highlighted being relayed.  
> **username_2**: Well this specific transaction wasn't paying a fee either so it definitely wasn't relayed via P2P network default policy rules. But a fee paying equivalent of that transaction.  
> **username_0**: I can only speak for my self but downloading and validating all transaction data would be fine - it's being forced to then _knowingly_ store and host particular obnoxious data on my node that I'd be against. I'd be happy for the redaction to be manual as I can't see it being a common occurrence  
> **username_1**: @username_0. I'm not a Bitcoin wallet developer but I believe it would be possible to develop a wallet that does not permanently store images embedded in this specific way. Either a new wallet or a patch to (possibly a fork of) an existing wallet. In my (completely unimportant) opinion, this *might* ameliorate the issue to a limited extent for a while and be acceptable to some as a partial solution.  
> **username_1**: @username_2, many thanks for pointing that out, answer updated accordingly.  
> **username_2**: @username_0: You don't have to do anything. You don't have to verify transactions let alone store parts of them if you don't want. OP_RETURN makes it clearer that a transaction is including data whilst with some other transactions it is less clear what they are doing. If you want to do full verification you have to keep UTXOs around in case they are ever spent. But if you don't want to store OP_RETURNs or say SegWit witnesses post verification you don't have to.  

---

### Answer by username_2 on 2024-01-08. Score: 0

So first of all this has already happened e.g. "Child Abuse Content Found On Bitcoin Blockchain, Users Must Be Protected" ([reference](https://cointelegraph.com/news/german-researchers-child-abuse-content-found-on-bitcoin-blockchain-users-must-be-protected), Coin Telegraph).

If your aim is to maximize censorship resistance and restrict the ability of state authorities to prevent certain transactions from being mined then you can't prevent any consensus valid, high fee rate transaction from being mined.

However, the OP\_RETURN limit of 80 bytes is tiny in comparison to typical image sizes that can get up to 1-2MB for a high quality photograph. So for an image (abhorrent or otherwise) the best one can do is split an image into tiny chunks and spread it across many OP\_RETURNs and many transactions. There are many people who dislike Bitcoin for various reasons and would do anything to try to prevent its growth so it is inevitable that bad actors will do this. But no single transaction or even a single block can contain an entire image. It becomes somewhat farcical if you take this concern to extremes by splitting an image into say bytes and storing a single byte on every page of a website. It would be impossible to detect this and visitors to the site or hosts of the site could not be reasonably held liable.

**correction:** As username_1 points out in the comments since the SegWit soft fork it has been possible to get a >2MB image into a single Bitcoin transaction and an example is this [transaction](https://mempool.space/tx/0301e0480b374b32851a9462db29dc19fe830a7f7d7a88b81612b9d42099c0ae) 0301e0480b....

> **Comments:**
> **username_1**: username_2, when you write *"for an image (abhorrent or otherwise) the best one can do is split an image into tiny chunks and spread it across many OP_RETURNs and many transactions. "* were you unaware of  *"the network mined its largest block, nearly 4 MB in size, containing just 63 transactions. **One of the transactions was a 3.94 MB Ordinal inscription featuring an image of a wizard**,"* reported [here](https://news.bitcoin.com/bitcoin-records-largest-mined-block-to-date-4-mb-block-containing-nft-causes-unease-among-small-block-supporters/). Search tx for ASCII "image"  
> **username_2**: https://mempool.space/tx/0301e0480b374b32851a9462db29dc19fe830a7f7d7a88b81612b9d42099c0ae  
> **username_1**: I am having difficulty reconciling this *single* transaction containing a > 3MB image with the assertion that a < 1-2MB image must be split across *many* transactions.  
> **username_2**: @username_1: Yeah you're right and hence my answer is incorrect. I wasn't aware that was possible. Submitted directly to a miner and not paying a fee. Starting to think that Taproot relaxation was a bad idea now :)  
> **username_1**: For what it is worth, my opinion is that most of your answer is right and blockchain polluters will likely fragment and obfuscate objectionable content if nodes start censoring them.  
> **username_3**: If you ignore policy rules, taproot didn't change anything w.r.t. embedding data. Whatever people do now to include a 2+ MB image in a transaction was perfectly legal before the taproot softfork too (it must be; if it wasn't, it would not be a softfork).  
> **username_2**: Thanks username_3. Gosh it is hard to follow what relaxed limits are enabling what. I thought (mistakenly) that this transaction was using the BIP342 relaxed script limit.  
> **username_3**: @username_2 The standard ones do, but the non-standard ones obviously aren't subject to any policy limits.  
> **username_2**: https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#cite_note-9 This is consensus rather than policy though right?  
> **username_3**: @username_2 Yes, but it applies to different outputs. P2TR applies to v1 outputs, P2WPKH/P2WSH rules apply to v0 outputs. Before the introduction of P2TR one could just have used a v1 output + spend thereof, which was unemcumbered then. And even today, if one is willing to ignore policy rules, one could use (say) a v13 witness output + spend thereof. It's anyone can spend, but perfectly consensus valid (and must be, to keep it available for future softforks).  
> **username_3**: And even if one wants to stick to existing output types for some reason (but still not care about policy), it has since segwit been possible to create a very close to 4MB transaction (it would need to split it up in 520-byte witness stack items, or 10000-byte scripts, though, but that barely affects the efficiency).  

---

