From: waxwing/ AdamISZ <ekaggata@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] A safe way to remove objectionable content from the blockchain
Date: Sat, 29 Nov 2025 10:52:52 -0800 (PST) [thread overview]
Message-ID: <03f19c1a-ef1b-40c9-9864-ce84e6b5ddbdn@googlegroups.com> (raw)
In-Reply-To: <CAAS2fgQfmSsvFwm5n2v7XjV3cc4KUxqpSwCoa30YXPDVEqj1Fg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 14809 bytes --]
Erik,
> In practice, the system fixes a BLS12-381 public key `PK_root` and a
one-time BLS signature `σ = Sign_root(S)`. Any allowed secp256k1 key is
then defined as `P_i = HashToCurve_secp256k1(σ || i)`, where `i` is an
arbitrary index and the hash-to-curve map is a standard indifferentiable
encoding (e.g., IETF RFC 9380). Verifiers check the pairing equation `e(σ,
g) = e(H(S), PK_root)` once, and thereafter reject any public key whose
curve point does not equal the canonical hash-to-curve output for some
disclosed index `i`. Because the signer never chooses curve points—and
because hash-to-curve eliminates degrees of freedom—no entropy remains to
smuggle bits into the key, satisfying the same non-malleability criteria
used in anti-steganographic constructions.
Oh, I confess when you said "BLS" I didn't read the details and then just
went off on the assumption you were talking about a replacement of secp
with a BLS curve and then outputs being (BLS pubkey, BLS sig) i.e. an
attached PoK of the key. But now I do actually read what you specifically
meant, I realize I don't understand it: if the secp key is
Hash-to-curve(sigma, i) then you don't have the private key of that pubkey.
How could that be used? I don't get it. Maybe it's because I don't know
what S is, in this scheme, or maybe not.
Lloyd and I rejected the idea of still using secp but attaching a BLS sig
to it. That feels unworkable (mapping keys across groups or w/e), you'd
need to just switch to a BLS curve entirely, I think.
AdamISZ/waxwing
On Saturday, November 29, 2025 at 3:16:34 PM UTC-3 Greg Maxwell wrote:
> You cannot perform pairing on secp256k1 as the DDH is hard in that group,
> so no BLS signature. You may find that you make fewer technical errors if
> you refrain from misrepresenting other people's ideas as your own original
> work.
>
>
> On Sat, Nov 29, 2025 at 5:17 PM Erik Aronesty <er...@q32.com> wrote:
>
>> there is no fundamental change to the cryptography. The beacon proofs
>> are only used for "proof of not spam". The proven Bitcoin key is the same
>> secp256k1 key and spending is unchanged. uxto proofs are not terribly
>> unreasonable given the cost of UTXOs
>>
>> On Sat, Nov 29, 2025, 8:15 AM waxwing/ AdamISZ <ekag...@gmail.com> wrote:
>>
>>> Hi Erik,
>>>
>>> > You can stop arbitrary data encoding in public keys by requiring every
>>> key to be the **unique hash-to-curve output** of a publicly verifiable BLS
>>> root signature, rather than a user-chosen point on secp256k1.
>>>
>>> Indeed, absolutely correct (afaik!), I had recently been discussing this
>>> a bit with Lloyd Fournier on nostr. I think at a theoretical level this is
>>> a very important observation, but at a practical level not so much. It's
>>> also worth noting that something like RSA FDH or hash based signatures,
>>> since they're deterministic (think "no nonce" and no technical ZK property)
>>> could technically do the same thing, but BLS is far and away better than
>>> those.
>>>
>>> Theoretical not practical: I think there's no way such a thing would
>>> happen on bitcoin (IMO! could be wrong!) because it's an absolutely huge
>>> change to the crypto without improving quantum resistance (performance
>>> issues are I guess an open question, considering batching properties vs raw
>>> performance of a single pairing being bad). And the other reason: no point
>>> going this far without attempting to patch *every* hole that allows data
>>> that is not trivial. You could argue these holes are trivial: amount data,
>>> locktimes (both nLockTime and nSequence), in/out sequencing not being
>>> deterministic, and grinding curve points. The obviously much more relevant
>>> and non-trivial issue is Script, generally, and sort of peripheral to
>>> script stuff like control block in taproot etc. Since you'd have to
>>> "address" (that is to say, gut) Bitcoin's scripting before these other
>>> things like deterministic signatures become relevant, it does seem all very
>>> theoretical, if interesting.
>>>
>>> I guess this would have been better in the "On (in)ability to embed data
>>> in Schnorr" thread but w/e it's all kind of connected I guess!
>>>
>>> Cheers,
>>> AdamISZ/waxwing
>>>
>>> On Saturday, November 29, 2025 at 12:43:56 PM UTC-3 Erik Aronesty wrote:
>>>
>>>> You can stop arbitrary data encoding in public keys by requiring every
>>>> key to be the **unique hash-to-curve output** of a publicly verifiable BLS
>>>> root signature, rather than a user-chosen point on secp256k1.
>>>>
>>>> Because a BLS signature is checkable via a pairing equation, verifiers
>>>> can confirm that each public key was deterministically forced by the root
>>>> certificate and not selected to embed arbitrary bits. Under this
>>>> construction, public keys become outputs of a constrained randomness beacon
>>>> rather than an open steganographic channel.
>>>>
>>>> In practice, the system fixes a BLS12-381 public key `PK_root` and a
>>>> one-time BLS signature `σ = Sign_root(S)`. Any allowed secp256k1 key is
>>>> then defined as `P_i = HashToCurve_secp256k1(σ || i)`, where `i` is an
>>>> arbitrary index and the hash-to-curve map is a standard indifferentiable
>>>> encoding (e.g., IETF RFC 9380). Verifiers check the pairing equation `e(σ,
>>>> g) = e(H(S), PK_root)` once, and thereafter reject any public key whose
>>>> curve point does not equal the canonical hash-to-curve output for some
>>>> disclosed index `i`. Because the signer never chooses curve points—and
>>>> because hash-to-curve eliminates degrees of freedom—no entropy remains to
>>>> smuggle bits into the key, satisfying the same non-malleability criteria
>>>> used in anti-steganographic constructions.
>>>>
>>>> This “forced randomness” model parallels techniques in the literature
>>>> on steganographic resistance and extractable commitments, particularly
>>>> Hopper–Langford–von Ahn’s work on *provably secure steganography* and
>>>> Bellare–Ristenpart–Tessaro’s analyses of *channel indistinguishability* in
>>>> public-key spaces.
>>>>
>>>> The underlying idea is identical: eliminate sender choice over
>>>> high-entropy objects so the objects cannot become covert storage.
>>>>
>>>>
>>>> On Sat, Nov 29, 2025, 5:57 AM waxwing/ AdamISZ <ekag...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Peter, list,
>>>>>
>>>>> Interesting!
>>>>>
>>>>> One thought that springs to mind: attempts to ameliorate IBD with ZKP
>>>>> should not forget one thing: what we actually want here is succinctness,
>>>>> and not so much ZK. Think SNARK instead of ZkSNARK.
>>>>> Which is important; without the requirement for an actual ZK property
>>>>> for the protocol, you can have it have attached witness that is not secret.
>>>>>
>>>>> Then a counter-thought strikes, that any version of these protocols
>>>>> that requires more data/bandwidth probably loses out to versions that have
>>>>> less data/bandwidth. Hmm.
>>>>>
>>>>> It seems to demonstrate, to me, that some kind of "data carrying" is
>>>>> required in the "state" (cf the "history"). Ironically recent discussion
>>>>> (see 'On (in)ability to embed data into Schnorr' but yeah a googolplex of
>>>>> "discussions" on the internet about filtering and spam...) has just
>>>>> re-emphasized that the utxo set can inevitably carry data (I guess that's
>>>>> obvious).
>>>>>
>>>>> I do think, long term that ZKP over history is correct, and that (see
>>>>> typical rollup design) data carrying in state can do the job that you are
>>>>> (correctly) insisting, must be done.
>>>>> (And the corollary: "harmful data on the blockchain" is a wrong mental
>>>>> model and should be abandoned, irrespective of architecture.)
>>>>>
>>>>> Aside from your *main* concept here, I think the idea that HTLCs
>>>>> require *proof* of publication is wrong. What they require is publication.
>>>>> A wronged channel party needs to read the preimage, not have proof that it
>>>>> can be read. Take as contrast the opentimestamps model, where having proof
>>>>> that something was published, is the main functionality offered/required. I
>>>>> suppose there is another way to say it: the channel counterparty needs
>>>>> "proof of future publication" in contract setup. That's fair enough but
>>>>> it's a very different thing than getting a proof that something *was*
>>>>> published.
>>>>>
>>>>> Cheers,
>>>>> AdamISZ/waxwing
>>>>>
>>>>> On Saturday, November 29, 2025 at 8:32:21 AM UTC-3 Peter Todd wrote:
>>>>>
>>>>>> 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+...@googlegroups.com.
>>>>>
>>>> To view this discussion visit
>>>>> https://groups.google.com/d/msgid/bitcoindev/f5cf7fb8-61ce-437b-b26b-241d47b3fcb5n%40googlegroups.com
>>>>> <https://groups.google.com/d/msgid/bitcoindev/f5cf7fb8-61ce-437b-b26b-241d47b3fcb5n%40googlegroups.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+...@googlegroups.com.
>>> To view this discussion visit
>>> https://groups.google.com/d/msgid/bitcoindev/1d1c5d9c-9b36-4e4b-930c-d23b2f562052n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/bitcoindev/1d1c5d9c-9b36-4e4b-930c-d23b2f562052n%40googlegroups.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+...@googlegroups.com.
>>
> To view this discussion visit
>> https://groups.google.com/d/msgid/bitcoindev/CAJowKg%2BNuZcowZhKvTH9Dij-8eiM0pueX8Ym8RbqUHOfE5Nbjg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/bitcoindev/CAJowKg%2BNuZcowZhKvTH9Dij-8eiM0pueX8Ym8RbqUHOfE5Nbjg%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/03f19c1a-ef1b-40c9-9864-ce84e6b5ddbdn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 18605 bytes --]
next prev parent reply other threads:[~2025-11-29 18:56 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
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 [this message]
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=03f19c1a-ef1b-40c9-9864-ce84e6b5ddbdn@googlegroups.com \
--to=ekaggata@gmail.com \
--cc=bitcoindev@googlegroups.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