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?

2 Answers 2


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


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

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.

  • I'm pretty sure existing Core default policy (e.g. datacarriersize?) would already prevent the transaction you highlighted being relayed. Jan 8 at 11:41
  • 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. Jan 8 at 11:55
  • 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
    Jan 8 at 14:36
  • @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. Jan 8 at 14:46
  • @Michael, many thanks for pointing that out, answer updated accordingly. Jan 8 at 14:55

So first of all this has already happened e.g. "Child Abuse Content Found On Bitcoin Blockchain, Users Must Be Protected" (reference, 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 RedGrittyBrick 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 0301e0480b....

  • 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. Search tx for ASCII "image" Jan 8 at 10:55
  • 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. Jan 8 at 11:16
  • 2
    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). Jan 8 at 15:48
  • 1
    @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). Jan 8 at 18:23
  • 1
    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). Jan 8 at 18:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.