* [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; 3+ 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] 3+ 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 2026-01-18 23:11 ` 'conduition' via Bitcoin Development Mailing List 0 siblings, 1 reply; 3+ 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] 3+ messages in thread
* Re: [bitcoindev] Re: Perhaps the simplest possible quantum-security upgrade 2025-12-18 16:11 ` [bitcoindev] " Erik Aronesty @ 2026-01-18 23:11 ` 'conduition' via Bitcoin Development Mailing List 0 siblings, 0 replies; 3+ messages in thread From: 'conduition' via Bitcoin Development Mailing List @ 2026-01-18 23:11 UTC (permalink / raw) To: Erik Aronesty; +Cc: Bitcoin Development Mailing List [-- 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 --] ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-01-18 23:33 UTC | newest] Thread overview: 3+ 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 2026-01-18 23:11 ` 'conduition' via Bitcoin Development Mailing List
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox