From: Erik Aronesty <erik@q32.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Perhaps the simplest possible quantum-security upgrade
Date: Wed, 17 Dec 2025 12:57:42 -0800 [thread overview]
Message-ID: <CAJowKgLR+vjYrUXuJ-k3FZ9=ZnOj3f3w2qB==M7-yrbQYx_h2A@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 3408 bytes --]
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/CAJowKgLR%2BvjYrUXuJ-k3FZ9%3DZnOj3f3w2qB%3D%3DM7-yrbQYx_h2A%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 3779 bytes --]
next 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 Erik Aronesty [this message]
2025-12-18 16:11 ` [bitcoindev] " Erik Aronesty
2026-01-18 23:11 ` '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='CAJowKgLR+vjYrUXuJ-k3FZ9=ZnOj3f3w2qB==M7-yrbQYx_h2A@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