From: "'conduition' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Erik Aronesty <erik@q32.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Perhaps the simplest possible quantum-security upgrade
Date: Sun, 18 Jan 2026 23:11:18 +0000 [thread overview]
Message-ID: <6AzufPg5x941QjBsaCZIFaboRU_x1KVcs2Xn7gzmHVvZ7mlja6ldAs_-9skg521Nq6kAKjpvBQ6v4yD-bp599Z7qQYOYeT6XhywxtFuRBFY=@proton.me> (raw)
In-Reply-To: <CAJowKgKcRN6QOKFdvMDdrZVcFGu+hrrCMiB+B9HVdM2RXphQAQ@mail.gmail.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 5404 bytes --]
Hey Erik, thanks for writing on this subject. While I don't think your solution will work, commit/reveal protocols like this are a great backup plan in case we can't make the larger sizes of real post-quantum signing schemes work at scale.
The main issue I see with your protocol as described is that unlike other commit/reveal protocols, the "anchor tx" as you call it doesn't commit to the reveal TX at all. Once the reveal TX appears in the mempool, a quantum adversary could just copy the secret, invert the public key, and attempt to RBF the reveal TX.
Forgive me if the answer lies somewhere in your code, I don't fully understand what it's supposed to be doing.
regards,
conduition
On Thursday, December 18th, 2025 at 8:49 PM, Erik Aronesty <erik@q32.com> wrote:
> 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.
--
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/6AzufPg5x941QjBsaCZIFaboRU_x1KVcs2Xn7gzmHVvZ7mlja6ldAs_-9skg521Nq6kAKjpvBQ6v4yD-bp599Z7qQYOYeT6XhywxtFuRBFY%3D%40proton.me.
[-- Attachment #1.1.2.1: Type: text/html, Size: 7653 bytes --]
[-- Attachment #1.2: publickey - conduition@proton.me - 0x474891AD.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 343 bytes --]
prev parent reply other threads:[~2026-01-18 23:33 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 ` [bitcoindev] " Erik Aronesty
2026-01-18 23:11 ` 'conduition' via Bitcoin Development Mailing List [this message]
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='6AzufPg5x941QjBsaCZIFaboRU_x1KVcs2Xn7gzmHVvZ7mlja6ldAs_-9skg521Nq6kAKjpvBQ6v4yD-bp599Z7qQYOYeT6XhywxtFuRBFY=@proton.me' \
--to=bitcoindev@googlegroups.com \
--cc=conduition@proton.me \
--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