From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 18 Dec 2025 17:49:51 -0800 Received: from mail-qt1-f190.google.com ([209.85.160.190]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vWPcs-0008Cc-Co for bitcoindev@gnusha.org; Thu, 18 Dec 2025 17:49:50 -0800 Received: by mail-qt1-f190.google.com with SMTP id d75a77b69052e-4ed6ceab125sf29723451cf.1 for ; Thu, 18 Dec 2025 17:49:49 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1766108984; cv=pass; d=google.com; s=arc-20240605; b=V8byUDBkoJNWmHhCmdDtfS4MMfpEmAD2XBMOX44sesfZ0qEqE3hl1PPB1J4M8dHG/A uUUFaWDzJxr6nZgfW43nqsNTO7HoHaHJ3DgxAc6RofEW++i1CNQAbBybqfizbMhLkhZ+ wsGA5jjtKsYcT885oBt8LBK4K+m21xHnlwgT5S+ACrjC6KQdu46QCSzVV1hcJnYNAIOd 2qQ2xqgqY1GvplUn35rtccc635gy9tK4kwnYmLcD/ipowbDYspILhQ+qGbIOXmaJHIfn Upp8MzwS0BPXqFtJ0PiET055NOnPppwnqdyesCm/DQsaP+zfvdN4UfwgBsqUYxMXdVR0 C+bw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature; bh=1Htpgh+SuZuuwWhegRE3pWFhQdtZvfeSCt5lL0AdzMY=; fh=n2klh+v7RXkPicVn1pd/usZIH0iKWzJo/pP/CVSwMuQ=; b=RDWHCjyBl7vmXXpafIOWZQYWgIztVc8vubM2ozhI3KpoTGkgp7tEpMb0zk24TyEEO1 fOZcHFlB7T2Jpe81tuwKpAFFf5MdovMupqLzW4UdTzCF5psixv+0d3hu4X28cpwqw159 nxG5Jzxy4vQlACo88eeIcS/qMFWq/VNgbvtZ+L+nQdwyDLsrsBXjjM2Vhh0HtQMoXzA7 ViLd0ZzNJngibTc+MBFZrXw8tDYfGtPbOJmyJkRqFBrNtzy9I45b4q/jr9ucXALvYiJX Hah43CaMJOBrPTqsjtRoVe/forxO0jwF1BmUOhiVku0a0hyGKyo66bdogLtwuIV7FVlW m3VA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@q32-com.20230601.gappssmtp.com header.s=20230601 header.b=UQZ0BPj+; spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::62e as permitted sender) smtp.mailfrom=earonesty@gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1766108984; x=1766713784; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=1Htpgh+SuZuuwWhegRE3pWFhQdtZvfeSCt5lL0AdzMY=; b=tY8bTJVoVXC9YA8rx/j2J+V65hDh30g3YUMWKD3BUt8aZBlF1vynC/IpWr7QMsSi8A O4Yc3+MrvxGIPmQlATgUYyHQWVB3rAyTEtDo2FKUlAf07hJSJGY+Mg6YsyWJk/GvYA61 rqLWvWP40pZXccEO6/ogDIjBh55PuRjFvMmuujWQBG9yf9VTGqr4fT1ByX/iwDRQQ32u Oayw4RJY4QdsU0v3+JfFBqWQaMFqfHrUNIOEdVmZxqeEOVvPU8VyQNP2GxtQqL3/MH19 /6Trk1NQ9/MYlHT6sqOQRqBVH81tNSuayq2lrr3QkzZ483KZ9rxpTeA1tmSZlwWuOKSg pPEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766108984; x=1766713784; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=1Htpgh+SuZuuwWhegRE3pWFhQdtZvfeSCt5lL0AdzMY=; b=oD7TVxWBI1YQHfqbtB1E0Ii7NGmxLubTNYFtNhZN/cBsX+nwROfBl27jj6jmCdbKtw FeWXXKD1YvbLMvtX72XQ2cu4eN/ANUQJtefukbu0V9+rmsZVfInIqryE5X6cryMzmgN+ c50NrogCzMDCOuh1abfbAetk+TGcYYhmM2XuAk2U52pYP6nvc7BrEl2RNH46UqXAmsR8 +C4rrSGpyfZs5DKDFD1MUXNpmscixhZAeDCAl+k1U2dW8f401I+sKc6shC9izliQOpNT bp6HOZBMzIVptuHSMaJSSJqfgqJ/4FS1D43GaqPp6o0EoDQFYr4iifI50pxW8S1pI4sc 7UVg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCVyxrhzl7EgSJWG0JB2HkOB1LrR5MI2eTFnZyLl6NQ43YoNs742jbrBnFUkqslSOb0AOEGoVZ4Ez7+5@gnusha.org X-Gm-Message-State: AOJu0YwZHIkFCY6ihskWTYzqwQxHkSCQ1+IoM69j7h/dKVgpuSkyt5YG MvmUjpjey1doNKsRRyc+/L6kHLKkAhR9tF7TCfW/FLPh5kg+I2NIgWlT X-Google-Smtp-Source: AGHT+IHYtlnZSq1BnkA9ClhHCGlhB8n/73IrgLkarFfrsZONMAi/p99lQz/YsKr7s5VZf9345G9S/A== X-Received: by 2002:a05:622a:1e94:b0:4ee:209c:be59 with SMTP id d75a77b69052e-4f4abd9541bmr23864331cf.55.1766108983570; Thu, 18 Dec 2025 17:49:43 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWZ4/RzrLpcSvTncPAD5uf6G/RkDrRpWjBRoI28YJpvvkw==" Received: by 2002:a05:622a:1654:b0:4ee:4220:d0b4 with SMTP id d75a77b69052e-4f1ced3ccbbls14629391cf.1.-pod-prod-02-us; Thu, 18 Dec 2025 17:49:36 -0800 (PST) X-Received: by 2002:a05:620a:40d1:b0:8b2:e6b1:a9a6 with SMTP id af79cd13be357-8c08f654cfdmr280837385a.17.1766108976834; Thu, 18 Dec 2025 17:49:36 -0800 (PST) Received: by 2002:a05:600c:c1c8:10b0:471:13aa:415a with SMTP id 5b1f17b1804b1-47bdc5d4420ms5e9; Thu, 18 Dec 2025 08:11:27 -0800 (PST) X-Received: by 2002:a05:600c:444d:b0:475:ddad:c3a9 with SMTP id 5b1f17b1804b1-47d18bdfc61mr1165015e9.13.1766074284845; Thu, 18 Dec 2025 08:11:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1766074284; cv=none; d=google.com; s=arc-20240605; b=AAgnkEuzfoJ7efUHc3auZC4qzkkZI2DWATUdQQxoVNyq81M+JlAhJd/cQ9nJZNnGjc u9Anx2CeijlZUoYnENbr37cTOzxDx8rMidmzGqDUVqtn8C8EPnre2gTKTVUo3sfW1UKD tyVi6ancaKHMtzOdxgkJ6ZzCOrZDgE02HGM+VUabOxEEBONRXWt4qDdjVGKeebO5noj+ BZIIBRP96W1rP9BkuUI5y9YDskLlssnZnpmwnPHntNJfuhmoDXj/tXuwW1bGgIDV3PdD n/hxk++2+GfrnUvBPbCEKy/Ujh9Rl0zl7si76nw1oU1VyxWNzkAdR3B70gfE6+J66BlC dLcA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=Idcd/4+hIyB1tGWrhgtobiy5WwqmhovxZePBbQiXC7M=; fh=DMP0F9ULS1guKiqimntQRCN8ZraraesEgQuVcn7F0Z0=; b=IhzJbqVXF15qjc54AeEuj+ghZ8FsqCBkxFscHbydoGS5Mom8FztDQtY8NZgPm84feE WkbfEt5zE6mPeEzuinGNPiQaAZaEE90Gi24P/ysDmEKOttzPmskt3yLnWWf+5R9cKe0T Xz+1rE1wBt8Na1ceXY0Qk+G8BDXI3CIcAj0vu4rOtRHOI0iO+aO4q4Hw/7iqumemqkSS XT685kFTB9EGc0pw3mDZmR3uA2uOmaCeGcKCf4pNTLaSKT/nKNUVk6rrsZ9xxmzzs50l rKqaOziYgxeA+BtzlOEG01aPR4PW9LkKIjyVrPRIH7Tq0KUujQZuvDxyBkS6c0/NWxBb v1gQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@q32-com.20230601.gappssmtp.com header.s=20230601 header.b=UQZ0BPj+; spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::62e as permitted sender) smtp.mailfrom=earonesty@gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com. [2a00:1450:4864:20::62e]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-47be3a0f840si290835e9.1.2025.12.18.08.11.24 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 Dec 2025 08:11:24 -0800 (PST) Received-SPF: pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::62e as permitted sender) client-ip=2a00:1450:4864:20::62e; Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-b727f452fffso305190066b.1 for ; Thu, 18 Dec 2025 08:11:24 -0800 (PST) X-Gm-Gg: AY/fxX6KtJb+6mcBdLBfn/chr+1q5sKVi4rEJBUd3z0FN12j7Fp8WqSziK3YQnHFpkE ig2Ig1iZ9PesxW8g7lyIOVXer8UXTT8Z/PCf/nH9d9cPHBeRj6Fc1WqvCSkQ74HCkAinafMWIYD 4tKwJd1JYmKRIeO6LW3CZI6XpWDjRbAoRzJFafmpVvDrzgsCrp819asDx96yNcD6+6n3Rr5GnVH 7hyfUB2bqdUSWHhWczTcMJU9cbGpsl0PYDknP6bvdrGrK7hnbHytvnYkA4+GZsjf4yLU9uB7yMM YcxP/wXP9/13/OMReO0t+849nol7+j+Kdv4maU48YQVI X-Received: by 2002:a17:907:fdc1:b0:b7d:266a:772c with SMTP id a640c23a62f3a-b803574c34fmr10566466b.21.1766074283496; Thu, 18 Dec 2025 08:11:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Erik Aronesty Date: Thu, 18 Dec 2025 08:11:13 -0800 X-Gm-Features: AQt7F2qOz8cf6mqS2fwTLAfjy_niLqbDk-OJqoCo1I1rzEyzoOR8obVHrMhvZfM Message-ID: Subject: [bitcoindev] Re: Perhaps the simplest possible quantum-security upgrade To: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="00000000000050a3ec06463c36be" X-Original-Sender: erik@q32.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@q32-com.20230601.gappssmtp.com header.s=20230601 header.b=UQZ0BPj+; spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::62e as permitted sender) smtp.mailfrom=earonesty@gmail.com; dara=pass header.i=@googlegroups.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.7 (/) --00000000000050a3ec06463c36be Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM Erik Aronesty 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 th= at > 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 ha= sh > 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=E2=80=93challenge=E2=80=93response (=CE=A3-protocol=E2=80= =93derived) 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=E2=80=99s sec= urity > 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 schem= e > 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 t= he > 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 incremental= ly. > > If anyone is interested in a BIP or further development of this security > construct, please let me know. > > - Erik > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= CAJowKgKcRN6QOKFdvMDdrZVcFGu%2BhrrCMiB%2BB9HVdM2RXphQAQ%40mail.gmail.com. --00000000000050a3ec06463c36be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I wrote the python code for this.=C2=A0 It was a little tr= ickier to get it right:

https://gist.github.com/earonesty/ea086a= a995be1a860af093f93bd45bf2

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=C2=A0tx 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.

=C2=A0
On Wed, Dec 17, 2025 at 12:57=E2=80=AFPM Erik Aronesty <= erik@q32.com> wrote:

Was thinkin= g about this and I realized that a quantum-resistance scheme doesn't te= chnically need a new "signature" - because those constraints (gen= erality) are far harder than needed for Bitcoin's "proof of utxo o= wnership".

Instead of new signatures, I propose a chain-native a= uthorization primitive whose security is bounded by the same economic assum= ptions as transaction finality itself. The objective is a quantum migration= path that can be deployed immediately, does not require large witnesses, r= emains cheap to validate, and does not rely on assumptions stronger than th= ose 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-derive= d challenge tied to the spent output, defined as the block hash at a select= able offset from the block in which the UTXO was created. The offset is fix= ed by the locking script and can be chosen to reflect the value at risk. La= rger offsets correspond to deeper confirmation depth and higher economic re= sistance to manipulation (an enforced confirmation wait). Existing timelock= opcodes already enforce the required delay; the only missing element is ac= cess to this chain-defined value.

This is commit=E2=80=93cha= llenge=E2=80=93response (=CE=A3-protocol=E2=80=93derived) authentication, but the challenge is provided by the future chain.=C2=A0 =C2= =A0This is a well known scheme.=C2=A0=C2=A0

Authorization is conjunct= ive, not alternative. A valid spend must satisfy both a traditional signatu= re check and a delayed, chain-conditioned hash-based proof. The traditional= signature preserves today=E2=80=99s security assumptions and compatibility= , while the chain-conditioned proof adds a quantum-resistant requirement th= at cannot be bypassed by a quantum adversary. Either condition alone is ins= ufficient. This ensures the scheme is strictly at least as secure as curren= t authorization and strictly stronger against quantum-capable attackers.

The delayed component commits to randomness in advance and later reveal= s it combined with a hash of the chain-provided challenge. Verification con= sists only of checking the timelock, evaluating a hash operation, and verif= ying the traditional signature. There is no large witness, no algebraic str= ucture, and no expensive validation path. Failure requires the ability to b= ias 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 forma= ts, inflating transaction sizes, or introducing fragile cryptographic assum= ptions. It aligns authorization with the economic security model the system= already relies on and provides an enforceable, compact, and conservative q= uantum-resistance mechanism that can be adopted incrementally.

If an= yone is interested in a BIP or further=C2=A0development of this security co= nstruct, please let me know.

- Erik

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/= d/msgid/bitcoindev/CAJowKgKcRN6QOKFdvMDdrZVcFGu%2BhrrCMiB%2BB9HVdM2RXphQAQ%= 40mail.gmail.com.
--00000000000050a3ec06463c36be--