public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Erik Aronesty <erik@q32.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Weak Quantum Bounty Ceremony
Date: Sat, 30 May 2026 07:01:05 -1000	[thread overview]
Message-ID: <CAJowKgJVwmm=h6AsO4zeGTmfdK-RUQiDsMJkMRd6WZSo5FjeZg@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2844 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 3840 bytes --]

             reply	other threads:[~2026-05-30 17:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-30 17:01 Erik Aronesty [this message]
2026-05-30 19:11 ` [bitcoindev] Weak Quantum Bounty Ceremony Nikita Karetnikov
2026-05-30 19:28   ` Erik Aronesty
2026-05-31  5:03     ` Garlo Nicon
2026-05-31  6:22 ` Nagaev Boris
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='CAJowKgJVwmm=h6AsO4zeGTmfdK-RUQiDsMJkMRd6WZSo5FjeZg@mail.gmail.com' \
    --to=erik@q32.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