From: Peter Todd <pete@petertodd.org>
To: Ethan Heilman <eth3rs@gmail.com>
Cc: Lazy Fair <laissez.faire.btc@gmail.com>, bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] A safe way to remove objectionable content from the blockchain
Date: Sat, 29 Nov 2025 09:25:35 +0000 [thread overview]
Message-ID: <aSq8Dya6-lzYB35t@petertodd.org> (raw)
In-Reply-To: <CAEM=y+XFMXHf7SrCy2NfA4U+y-fsjL_b2Xb+1Fc8Y0wCmYr3NA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3487 bytes --]
On Thu, Nov 20, 2025 at 04:21:33PM -0500, Ethan Heilman wrote:
> 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.
Rather than being a solution, the technology behind Zerosync is a potential
threat to Bitcoin. The problem is that Bitcoin fundamentally requires
proof-of-publication to be decentralized and censorship resistant; a related
problem is that HTLCs (and thus Lightning) fundamentally requires
proof-of-publication to work at all.
For Bitcoin mining to remain decentralized, blocks need to be widely propagated
in a form suitable for creating new blocks. ZKP/Zerosync makes it possible to
prove that a block hash and all prior blocks follow the protocol rules and were
thus valid. However, valid block hashes alone are insufficient to mine on top
of because they do not contain the UTXO set data necessary to mine a new block.
Why do miners have an incentive to distribute the blocks they find? Ultimately
because doing so is necessary for the coins they mined to be valuable. But if
full nodes can be convinced of the validity of coins without full block
contents --- thus allowing those coins to be sold --- that weakens the
incentives to distribute block data in a form that allows other miners to mine.
With regard to HTLCs/Lightning, HTLCs rely on a proof-of-publication to be
secure: for the HTLC to be redeemed, the redeemer *must* publish the pre-image
in the Bitcoin chain, allowing the other party relying on the HTLC to recover
the pre-image. Again, ZKP/Zerosync weakens this security, as the validity of
the transaction spending the HTLC can be proven without actually making the
pre-image available.
Rather than presenting ZKP/Zerosync as a solution to the "harmful data"
problem, we should in fact be researching ways to defeat ZKP/Zerosync entirely.
We need a consensus protocol where the only way to fully validate a block is to
actually have the entire block contents.
As for "harmful data", that is a challenge to be solved legally/politically.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
--
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/aSq8Dya6-lzYB35t%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2025-11-29 11:32 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
2025-11-29 9:25 ` Peter Todd [this message]
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=aSq8Dya6-lzYB35t@petertodd.org \
--to=pete@petertodd.org \
--cc=bitcoindev@googlegroups.com \
--cc=eth3rs@gmail.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