From: Ethan Heilman <eth3rs@gmail.com>
To: Lazy Fair <laissez.faire.btc@gmail.com>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] A safe way to remove objectionable content from the blockchain
Date: Thu, 20 Nov 2025 16:21:33 -0500 [thread overview]
Message-ID: <CAEM=y+XFMXHf7SrCy2NfA4U+y-fsjL_b2Xb+1Fc8Y0wCmYr3NA@mail.gmail.com> (raw)
In-Reply-To: <CABHzxrgbxG1qy3geyNHshA-q6tv0uNNwx5uiswUmAGDDxQjoHg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7974 bytes --]
I'm not convinced your hash function approach fully does what you want it
to, although it does seem doable with some additional constraints.
There is a solution that does everything you want it and more, ZKPs.
ZKP (Zero Knowledge Proofs) can prove that some data X hashes to some hash
output Y while keeping the actual value X secret. Thus, everyone can be
convinced that H(X) = Y even if X is deleted and no one knows what the
value X was.
Even more exciting, ZKPs can prove the correctness and validity of the
entire Bitcoin blockchain. Thus storing old transactions is
no longer needed to convince others that the chain is correct. This would
remove any harmful data. Zerosync in 2017 compressed Bitcoin's blockchain
into a 800 KB proof [0] which is constant size regardless of the number of
transactions or bytes compressed. This approach does not require any
changes to Bitcoin and you could implement a Bitcoin full node today that
supports this.
We have a solution to solve the problem of harmful data on the blockchain
since 2017. It just requires time, money and motivated people to work on it.
[0]: Robin Linus and Lukas George, ZeroSync: Introducing Validity Proofs
to Bitcoin, 2017, https://zerosync.com/zerosync.pdf
On Thu, Nov 20, 2025 at 4:49 AM Lazy Fair <laissez.faire.btc@gmail.com>
wrote:
> I propose two changes to Bitcoin, one at the consensus level, and one at
> the client level. The purpose of this is to support filtering of
> objectionable content after the content has been mined, allowing each node
> operator to maintain only that data they find agreeable. In so doing, my
> hope is that we can satisfy all users, and deal with their greatest
> concerns.
>
> I do however acknowledge those people that want to stop miners from mining
> non-monetary transactions, because of the data storage and processing cost,
> and I recognised that this proposal does nothing to address those concerns.
>
> *** Motivation ***
>
> You can't just change or delete some data from the blockchain, because a
> hash of everything in a block is included in the next block. If you change
> the data, you change the hash. The design presented here is an attempt to
> achieve a compromise, where a person can have all of the benefits of
> running a full node, including the integrity of the ledger, yet without
> storing the objectionable content - and importantly without even being able
> to recreate that objectionable content from what data they still have.
>
> *** Preliminary ***
>
> Objectionable content is defined here as whatever you want it to be, and
> two users don't have to share the same views. One person might object to
> copyrighted material used without permission, another a negative depiction
> of the prophet Muhammad, and another video of the sexual abuse of children.
> The design presented below lets each person decide what to remove for
> themself (if anything), while those who want everything can still have it
> all.
>
> The design lets a user remove any data, and deals with the impact on the
> matching of block hashes, data integrity and malleability.
>
> In the case of OP_RETURN data, the result should be no functional effect
> at all. Whether that's also possible for other data elements will depend on
> the semantics of that data.
>
> *** Solution ***
>
> This solution is based on two ideas, both aimed at maintaining data
> integrity through hashing, while removing some of the hash's input data
> stream.
>
> *** First Idea ***
>
> When performing a hash of some data (D), each chunk of data that's
> processed updates an internal state (S) of the hashing algorithm. If you
> know what the internal state is at point A and then at point B, then you
> can compute the final hash of D even without the data between A and B. This
> is the first idea. First you need to know what S(A) and S(B) are, and once
> you do, you can compute the hash of D, without the data between A and B.
> You run the hashing algorithm normally up to A, then you update the
> internal state from S(A) to S(B), then you continue hashing from B to the
> end of D.
>
> The hash still works as an integrity check for the data before A, and the
> data after B: change any of this, and the final hash will change. Now you
> can safely change or delete the data in between, without breaking the
> integrity of the blockchain and proof of work - but only if you can
> securely obtain S(A) and S(B), and only if you don't need the data between
> A and B for anything else.
>
> The easiest way to obtain S(A) and S(B) is to calculate them yourself, but
> that requires that you hold the objectionable data, at least for a time.
> That also requires finding someone else that holds the objectionable data.
> But what if instead, we could share S(A) and S(B) across the network, do it
> securely, and in a way where up to 100% of nodes could choose to drop the
> data in between, permanently, without breaking anything?
>
> *** Second idea ***
>
> It may seem like there is no one you can trust to tell you what S(A) and
> S(B) are. There is only one source of data that a Bitcoin node can trust,
> and that is the blockchain, as mined by miners, with the most proof of
> work, and verified locally. Therefore, the second idea is that S(A) and
> S(B) are trusted if (and only if) they are written into the blockchain, and
> verified by the network.
>
> For example, we write data to the semantic effect of "In Transaction X: at
> byte offset A, the internal state of the hash function is S1; at byte
> offset B, the internal state of the hash function is S2." Miners then mine
> this statement into a block, and verifiers confirm that it is
> cryptographically accurate with respect to the data in Transaction X as
> described - or else they drop the new block as invalid.
>
> At this point, any node can choose to delete the data between S1 and S2.
> This can now be done with confidence because they can double check the
> accuracy, and the impact on the ledger, before they delete the data. After
> that they may also be able to share (with the agreement of the receiving
> node) this modified transaction as part of initial block downloads, along
> with S1 and S2 - to any other nodes that don't want this objectionable
> content. The receiving nodes wouldn't immediately and necessarily be able
> to trust S1 and S2, but they would eventually, once they have the full
> blockchain.
>
> *** Conclusion ***
>
> This isn't a concrete proposal - it's not even close - but perhaps it
> might be the start of a fruitful conversation. I have more to say, but this
> email is long enough already. Email me if you're interested in discussing
> or developing these ideas together. I have a private Discord server, but
> I'm open to other suggestions, or just further discussion here.
>
> Laissez faire, laissez passer.
>
> Let it be, let it go.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/CABHzxrgbxG1qy3geyNHshA-q6tv0uNNwx5uiswUmAGDDxQjoHg%40mail.gmail.com
> <https://groups.google.com/d/msgid/bitcoindev/CABHzxrgbxG1qy3geyNHshA-q6tv0uNNwx5uiswUmAGDDxQjoHg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BXFMXHf7SrCy2NfA4U%2By-fsjL_b2Xb%2B1Fc8Y0wCmYr3NA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 9531 bytes --]
next prev parent reply other threads:[~2025-11-21 23:25 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-20 1:57 Lazy Fair
2025-11-20 18:45 ` Greg Maxwell
2025-11-23 6:37 ` Saint Wenhao
2025-11-20 21:21 ` Ethan Heilman [this message]
2025-11-29 9:25 ` Peter Todd
2025-11-29 13:54 ` waxwing/ AdamISZ
2025-11-29 15:41 ` Erik Aronesty
2025-11-29 15:56 ` waxwing/ AdamISZ
2025-11-29 17:03 ` Erik Aronesty
2025-11-29 18:15 ` Greg Maxwell
2025-11-29 18:52 ` waxwing/ AdamISZ
2025-11-30 14:39 ` Peter Todd
2025-12-02 12:33 ` waxwing/ AdamISZ
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAEM=y+XFMXHf7SrCy2NfA4U+y-fsjL_b2Xb+1Fc8Y0wCmYr3NA@mail.gmail.com' \
--to=eth3rs@gmail.com \
--cc=bitcoindev@googlegroups.com \
--cc=laissez.faire.btc@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox