From: Erik Aronesty <erik@q32.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Re: Perhaps the simplest possible quantum-security upgrade
Date: Thu, 18 Dec 2025 08:11:13 -0800 [thread overview]
Message-ID: <CAJowKgKcRN6QOKFdvMDdrZVcFGu+hrrCMiB+B9HVdM2RXphQAQ@mail.gmail.com> (raw)
In-Reply-To: <CAJowKgLR+vjYrUXuJ-k3FZ9=ZnOj3f3w2qB==M7-yrbQYx_h2A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4185 bytes --]
I wrote the python code for this. It was a little trickier to get it right:
https://gist.github.com/earonesty/ea086aa995be1a860af093f93bd45bf2
Spender publishes an ephemeral anchor tx committing to a future secret
without revealing the secret in one block.
Spender publishes the revealed secret and spend in a future block.
New opcode needs to verify that the anchor tx was published at least N
blocks prior to the spend block.
This creates the necessary information asymmetry without being a true
signature, relying on asymmetry-over-time to protect against quantum
threats.
On Wed, Dec 17, 2025 at 12:57 PM Erik Aronesty <erik@q32.com> wrote:
> Was thinking about this and I realized that a quantum-resistance scheme
> doesn't technically need a new "signature" - because those constraints
> (generality) are far harder than needed for Bitcoin's "proof of utxo
> ownership".
>
> Instead of new signatures, I propose a chain-native authorization
> primitive whose security is bounded by the same economic assumptions as
> transaction finality itself. The objective is a quantum migration path that
> can be deployed immediately, does not require large witnesses, remains
> cheap to validate, and does not rely on assumptions stronger than those
> already required to trust confirmed spends.
>
> The construction relies on a minimal new introspection primitive rather
> than a wholesale redesign of Script. A single opcode exposes a
> chain-derived challenge tied to the spent output, defined as the block hash
> at a selectable offset from the block in which the UTXO was created. The
> offset is fixed by the locking script and can be chosen to reflect the
> value at risk. Larger offsets correspond to deeper confirmation depth and
> higher economic resistance to manipulation (an enforced confirmation wait).
> Existing timelock opcodes already enforce the required delay; the only
> missing element is access to this chain-defined value.
>
> *This is commit–challenge–response (Σ-protocol–derived) authentication*,
> but the challenge is provided by *the future chain*. This is a well
> known scheme.
>
> Authorization is conjunctive, not alternative. A valid spend must satisfy
> both a traditional signature check and a delayed, chain-conditioned
> hash-based proof. The traditional signature preserves today’s security
> assumptions and compatibility, while the chain-conditioned proof adds a
> quantum-resistant requirement that cannot be bypassed by a quantum
> adversary. Either condition alone is insufficient. This ensures the scheme
> is strictly at least as secure as current authorization and strictly
> stronger against quantum-capable attackers.
>
> The delayed component commits to randomness in advance and later reveals
> it combined with a hash of the chain-provided challenge. Verification
> consists only of checking the timelock, evaluating a hash operation, and
> verifying the traditional signature. There is no large witness, no
> algebraic structure, and no expensive validation path. Failure requires the
> ability to bias or reorganize the chain across the selected confirmation
> window, which is the *same failure mode already implicit in transaction
> finality*.
>
> This design enables quantum migration without changing address formats,
> inflating transaction sizes, or introducing fragile cryptographic
> assumptions. It aligns authorization with the economic security model the
> system already relies on and provides an enforceable, compact, and
> conservative quantum-resistance mechanism that can be adopted incrementally.
>
> If anyone is interested in a BIP or further development of this security
> construct, please let me know.
>
> - Erik
>
--
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/CAJowKgKcRN6QOKFdvMDdrZVcFGu%2BhrrCMiB%2BB9HVdM2RXphQAQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 4850 bytes --]
next prev parent reply other threads:[~2025-12-19 1:49 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-17 20:57 [bitcoindev] " Erik Aronesty
2025-12-18 16:11 ` Erik Aronesty [this message]
2026-01-18 23:11 ` [bitcoindev] " '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=CAJowKgKcRN6QOKFdvMDdrZVcFGu+hrrCMiB+B9HVdM2RXphQAQ@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