* [bitcoindev] Perhaps the simplest possible quantum-security upgrade
@ 2025-12-17 20:57 Erik Aronesty
2025-12-18 16:11 ` [bitcoindev] " Erik Aronesty
0 siblings, 1 reply; 2+ messages in thread
From: Erik Aronesty @ 2025-12-17 20:57 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 2+ messages in thread
* [bitcoindev] Re: Perhaps the simplest possible quantum-security upgrade
2025-12-17 20:57 [bitcoindev] Perhaps the simplest possible quantum-security upgrade Erik Aronesty
@ 2025-12-18 16:11 ` Erik Aronesty
0 siblings, 0 replies; 2+ messages in thread
From: Erik Aronesty @ 2025-12-18 16:11 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2025-12-19 1:49 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-12-17 20:57 [bitcoindev] Perhaps the simplest possible quantum-security upgrade Erik Aronesty
2025-12-18 16:11 ` [bitcoindev] " Erik Aronesty
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox