Hey guys, > Those not motivated by funds could publish a zero knowledge proof instead of > moving the funds. This means real funds are not even needed in this case.
Why stop there? If the quantum adversary is willing to cooperate in convincing people of their capabilities, just ask them to find the discrete log of a NUMS point on some curve. Then we don't even need ZK machinery. Informally: Given scalar k and preimage x, the verifier checks K = k*G = HashToCurve(x). As stated this would permit a classical prover who finds a collision over all (x, k) pairs, which would be feasible for a 160-bit curve. To rule out collision attacks, we fix x as a constant as a part of the proof system. This would all be off-chain, no BIPs or UTXOs needed. If the quantum adversary demands payment to provide this proof, then one can use ZKCPs [1] [2]. But personally I think this would be an implausible scenario. A self-interested QC would bide their time and steal coins once they can factor secp256k1 keys. regards, conduition [1]: https://en.bitcoin.it/wiki/Zero_Knowledge_Contingent_Payment [2]: https://conduition.io/bitcoin/zkpreimage/ On Sunday, May 31st, 2026 at 3:40 AM, Nagaev Boris <[email protected]> wrote: > Hey Erik, > > The scheme is interesting! I want to add my two cents. > > Those not motivated by funds could publish a zero knowledge proof > instead of moving the funds. This means real funds are not even needed > in this case. Or the whole scheme can be deployed to testnet or signet > not to waste (or burn?) real coins. > > Also I would like to propose some properties which the publishing > scheme should have to maximize the effect: > > - anonymous for the publisher > - plausible deniable for the publisher > - uncensorable > > For the plausible deniability thing, imagine a researcher who has > access to a particular signature made by quantum computer and can > prove it, but then it will be clear who leaked it, because the > signature has a unique nonce. This is where ZK can help. But how to do > ZK onchain to get censorship resistance? Maybe some BitVM construction > may help. > > Using mainnet provides better censorship resistance than testnet or > signet - that is actually a good reason to use mainnet unless we come > up with a better approach. > > Best, > Boris > > On Sat, May 30, 2026 at 12:58 PM Erik Aronesty <[email protected]> wrote: > > > > I have been thinking about a way to create publicly verifiable Bitcoin > > outputs whose recovery is intentionally tied to breaking a weaker > > cryptographic system. > > > > The goal is to create a "quantum bounty." The output would be spendable by > > a valid secp256k1 private key, but the key would be generated in a public > > ceremony and intentionally limited to 160 bits of entropy. Recovery would > > additionally be facilitated by publishing an encryption of the same secret > > under a weaker elliptic curve system. > > > > The basic idea is that a group of independent participants runs a > > distributed key generation ceremony. Each participant contributes a secret > > share. The shares are combined into a single 160-bit scalar x. At no point > > is x reconstructed on any machine or revealed to any participant. > > > > From the same distributed shares, participants jointly derive: > > > > 1. A Bitcoin public key P = xG on secp256k1. > > 2. An encryption of x under a separate 160-bit elliptic curve system. > > > > The transcript contains all commitments, public contributions, ciphertext > > contributions, and equality-of-discrete-log proofs needed to verify that > > both constructions are derived from the same hidden scalar. > > > > The construction does not require SNARKs or any trusted setup. It appears > > sufficient to use Pedersen-style commitments, ElGamal-style encryption, and > > Chaum-Pedersen proofs showing consistency between participant contributions > > across the two groups. > > > > After the transcript is finalized, participants destroy their secret shares > > and temporary randomness. Assuming at least one participant behaves > > honestly and destroys their material, the scalar x is no longer known to > > anyone. > > > > The final artifact consists of: > > > > * A Bitcoin public key P. > > * A weak-curve ciphertext C. > > * A complete public transcript proving that P and C were derived from the > > same hidden scalar. > > > > Bitcoin can then be sent to the address corresponding to P. > > > > Anyone who can recover x from the weak cryptosystem can spend the output. > > The effective security of the bounty is therefore determined by the weaker > > curve rather than by the full secp256k1 discrete logarithm problem. > > > > The intended purpose is to create a publicly auditable cryptographic canary > > target. > > > > One question I have not fully resolved is whether there are cleaner > > constructions for the recoverable encryption component than ElGamal-style > > encryption, while still preserving simple transcript verification and > > avoiding general-purpose zero-knowledge systems. > > > > -- > > 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 [email protected]. > > To view this discussion visit > > https://groups.google.com/d/msgid/bitcoindev/CAJowKgJVwmm%3Dh6AsO4zeGTmfdK-RUQiDsMJkMRd6WZSo5FjeZg%40mail.gmail.com. > > > > -- > Best regards, > Boris Nagaev > > -- > 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 [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/CAFC_Vt7DLZEytF72Q0EVPeg6iED3qztMXs7aX6zBNBQ5%2B-ceXA%40mail.gmail.com. > -- 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/zG-JBFlHqnB2ZXTgBqIPn75VUiXkjrvBrO1CMN78gccfE4BqP3LmWnxB0cu2FQItr_cLoDcMFzlWaXkv3xeUDTOZrJgEGDRvWbpvADCBAZo%3D%40proton.me.
publickey - [email protected] - 0x474891AD.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
