From: Saint Wenhao <saintwenhao@gmail.com>
To: Nagaev Boris <bnagaev@gmail.com>
Cc: Erik Aronesty <erik@q32.com>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Weak Quantum Bounty Ceremony
Date: Sun, 31 May 2026 10:14:50 +0200 [thread overview]
Message-ID: <CACgYNO+LNdfHhfsA0uek2frXO46Zc6SV8S7rO_XZLbqS1A5j6A@mail.gmail.com> (raw)
In-Reply-To: <CAFC_Vt7DLZEytF72Q0EVPeg6iED3qztMXs7aX6zBNBQ5+-ceXA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 8200 bytes --]
> Those not motivated by funds could publish a zero knowledge proof instead
of moving the funds.
I think at least some financial incentive is needed. It could be something
like 10k satoshis, or more, just to have a non-dust anchor for the puzzle,
where other people could attach more coins. For example: if you have a
puzzle, where the creator cannot move the coins, without solving the
puzzle, then it is still possible to increase the reward later, as long as
coins are signed with proper sighashes. See:
https://mempool.space/tx/8349df0753e80cce322322f1b76789e1d0fd6693aed2f4de4e49576423081ae7
In this case, the puzzle from
bc1qts0jh2d2nesmketmw3thedwrx939k2tqu04gy90x9hd4049g4uhs83ltjx uses
SIGHASH_ANYONECANPAY, and is grinded by the solver. And
bc1q9nw84cph4dn2pw78pnaec68c82h7pxvv55cla8 is someone, who bumped the
reward, by signing it with SIGHASH_NONE, so the signature is valid only in
the context of the puzzle.
> Or the whole scheme can be deployed to testnet or signet not to waste (or
burn?) real coins.
We also did it:
mainnet:
https://mempool.space/tx/aba3c2ae442aa20150996ee68f9aa4da83b57a4312891078be0c2e68c50b2801
testnet4:
https://mempool.space/testnet4/tx/cc159432ffb7a166abeccc79800e9616a09ea9ac6937080c2ca37b38671970e5
signet:
https://mempool.space/signet/tx/5aa27f3639c2218ee710fee9830924a129098dca94446661f37cae79c4e76712
However, if you think, that test coins are not traded, then you are wrong.
For example: https://altquick.com/exchange/market/BitcoinSignet
I think, sooner or later, all test coins will be traded, and just handled
like all other altcoins. To some extent, it can be prevented, by making
next chains, and dropping previous ones, like it was between testnet3 and
testnet4, but still: exchanges will list new coins faster, than Bitcoin
Core will release a new version, where the support for some old test
network will be dropped.
Which means, that creating the puzzle will always have a cost. Because even
if initially some test chain will be worth exactly zero, then it will gain
non-zero value over time. And because even signet uses Proof of Work, then
creating any puzzle will always require at least some computing power, even
if it will be negligible, and doable on CPUs.
> plausible deniable for the publisher
It can be done, by using SIGHASH_ANYONECANPAY, which we also did in our
mainnet puzzle. In this way, an unconfirmed transaction with low fees can
be made, and published anywhere, using any channel. And then, other people
can add more inputs, or bump the fees, by solving some low hanging fruits,
and claiming the easiest puzzles. In this way, the creator has to only
prepare a single input, and all outputs, and then, it can be extended by
the rest of the community, and pushed on-chain by the first solver (which
would also set the challenge in stone, and prove, that at least some
outputs are solvable, and people know, how to claim them).
niedz., 31 maj 2026 o 09:40 Nagaev Boris <bnagaev@gmail.com> napisał(a):
> 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 <erik@q32.com> 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 bitcoindev+unsubscribe@googlegroups.com.
> > 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 bitcoindev+unsubscribe@googlegroups.com.
> 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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CACgYNO%2BLNdfHhfsA0uek2frXO46Zc6SV8S7rO_XZLbqS1A5j6A%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 10033 bytes --]
next prev parent reply other threads:[~2026-06-13 16:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-30 17:01 [bitcoindev] Weak Quantum Bounty Ceremony Erik Aronesty
2026-05-30 19:11 ` Nikita Karetnikov
2026-05-30 19:28 ` Erik Aronesty
2026-05-31 5:03 ` Garlo Nicon
2026-05-31 6:22 ` Nagaev Boris
2026-05-31 8:14 ` Saint Wenhao [this message]
2026-06-05 23:46 ` 'conduition' via Bitcoin Development Mailing List
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=CACgYNO+LNdfHhfsA0uek2frXO46Zc6SV8S7rO_XZLbqS1A5j6A@mail.gmail.com \
--to=saintwenhao@gmail.com \
--cc=bitcoindev@googlegroups.com \
--cc=bnagaev@gmail.com \
--cc=erik@q32.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