From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 18 Dec 2025 17:49:51 -0800 Received: from mail-qv1-f58.google.com ([209.85.219.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vWPct-0008Ce-4d for bitcoindev@gnusha.org; Thu, 18 Dec 2025 17:49:51 -0800 Received: by mail-qv1-f58.google.com with SMTP id 6a1803df08f44-88887611049sf36546196d6.3 for ; Thu, 18 Dec 2025 17:49:50 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1766108985; cv=pass; d=google.com; s=arc-20240605; b=cEskwiKzduQn8fUzZ8EeXlM5uQ73UWJ0eKH/M0figRI/zxOAqrcfcJTsHPFEjzJ4xL DZ+dxQ0Uy3AlPwl14qmQQAy6P5E26kt7791z8F2Eq0rPsXCZXZlwWH8WmDtOJcTMW/Vh JWwXuRBz9knrEz0xIjn8tAF4S1+nxckCKkOXkBYRrAf4CEJ43lAZCyUh6+N4p20lmMfX dzeT6etm8T+W8kqgsummQKEuUNMNJ4pz6F3Sp8bqhkpdLOd3gmIWhZ3oTqURU2HS8YRo ukDPaAQP710DbPePjodSBRp0a19/Ww71leUxyYHbOV3ArfUBsNnawsgmVhN05R+8dKLW mJfA== 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 :mime-version:sender:dkim-signature; bh=IV2QFbeLXBwxleIQOJMCLqPfnGK20jYEH5RD9EmmQtY=; fh=FArtSWSfwczqqiWwymHwz0r+Ar81tGbtsCAVoljkBbM=; b=SKqYW052a2s1WLgMMXsIDzF9dFgY8E1FHXMJ3Hhy/UDV/MFjkhdgwJfsPObFF2DKtM D3bZL/pHVucW/2oOfJJwQ0kzl1Gr3aKDtM5Cykqt1d7VZf6rrApcemrKhowTmnkSnOlt GkSSbSUHESItofUo7gppe0N16vlED8a8EKjAqcpZpt5IByHjaXzPtlO7hKP9mQX4feW1 ORMraJ9Jdguu2OxcoGvRvR7HS9zO55FjQpc7J3Cu3+xCqdyoWcDB43NdFK9e8sQr1i/D 7GUEqpITPFrltDMLyiF05JZPME/ZAkkD/pex7OFvl45biVYhWyFXpCzgSEBD2AVs351w W5cw==; 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=HFYkMi0+; spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::52c 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=1766108985; x=1766713785; 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:mime-version :sender:from:to:cc:subject:date:message-id:reply-to; bh=IV2QFbeLXBwxleIQOJMCLqPfnGK20jYEH5RD9EmmQtY=; b=ZGSbq/2ovcEx7IcmmdCqbzG9OCOA9+UJ9JZDZrZjWIiyMPYv1YJEgXeXLM6AG5fZYB PUn1R1bFotGIunKf8dStxXFSZAmuoLBv4R+ekZMpko+d9Cf37Vry1CXEE46Q7kALavBt MoCDEGmYQIdWlY5bmbiNW5aiXPJ3T0mdkHVlgwYzcoqyLajzKFt2VQsSFaLYYvOPuecW F+KV4XsElGDOy+cTEc5CKyMtI6BHWNGopFWDeCu1UMrOLR7jjZO/k2A8R3P+3wa70+/2 L/ofZxyRY46Y1v9Kv1mOZ79NcDcYqyBLzANAwd7lABZgwTtksE5FcMCRq9lPKOdCaVnD 3m1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766108985; x=1766713785; 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:mime-version :x-gm-gg:x-beenthere:x-gm-message-state:sender:from:to:cc:subject :date:message-id:reply-to; bh=IV2QFbeLXBwxleIQOJMCLqPfnGK20jYEH5RD9EmmQtY=; b=Wk+s8vU8V/L5a8jJPwW61HquDHDgcsKMmqp40zF+zNsDY79m0PbCLfHlOyqh9yCGYc rXx/wRFL73BTt3m5tKhBWC1hI8HdGYUaiNMHDziPoulP77RHKLa2CT2Sp80s5igrfOOI Dkg0OJZ9Fgh/YEKfQgk8D6dw3xIV5qmO/TZujmUyuAVoe5QNlsY0EKgQsLsPgBZbmeKX 47VKrU1SQVkJgy5u0dbOqI0bdJAgdiMa9Xai/SQxY3HsedAytAjQHcLPacYBFFKPk29Z fjlKECupBTTxOCu4mPFcQ/Q3xFuWKKR7s0NWoYDbMQvalHuwmnzzhjVal4IQefno23JC h/BQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUhSqogbMbd5y8KciMthoICdyjFPd0vuu9ovITk3gd1KLQj82rzZUms2LB0DA0nMM0yQKz5Kjsj4ARw@gnusha.org X-Gm-Message-State: AOJu0YzeD6dP+4F8FVwUrWwau+l94lmhK9KM0MGX6MQGfShw/oQcFh85 q9l9Snj8YzMM9VL+4HZfkOj4uKOZeI+aFKv5gsyHw3gb3LzRs4H2KEbR X-Google-Smtp-Source: AGHT+IFynjAP3NW4ACbBC72UDmUC7UgVIZ9LPuGOkAzlLzDYRwhlU5dEaIWF9OWIuEmSsibst9OSuQ== X-Received: by 2002:a05:6214:4e85:b0:880:47e0:19e8 with SMTP id 6a1803df08f44-88d83792f32mr27430806d6.42.1766108984612; Thu, 18 Dec 2025 17:49:44 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWYlkCwd5c/YnhldRMVEoc3aNUU675JHDG4w9zPHLBFiWQ==" Received: by 2002:a05:6214:3009:b0:888:1f20:6a87 with SMTP id 6a1803df08f44-8887c92e31als98188636d6.0.-pod-prod-04-us; Thu, 18 Dec 2025 17:49:36 -0800 (PST) X-Received: by 2002:a05:620a:1a0c:b0:8b2:e565:50b5 with SMTP id af79cd13be357-8c08fd03785mr278081685a.60.1766108976831; Thu, 18 Dec 2025 17:49:36 -0800 (PST) Received: by 2002:aa7:da47:0:b0:64b:3e1b:1324 with SMTP id 4fb4d7f45d1cf-64b4025580amsa12; Wed, 17 Dec 2025 12:57:55 -0800 (PST) X-Received: by 2002:aa7:dcc3:0:b0:649:9e21:bf51 with SMTP id 4fb4d7f45d1cf-6499e21bfb7mr12713906a12.1.1766005073016; Wed, 17 Dec 2025 12:57:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1766005073; cv=none; d=google.com; s=arc-20240605; b=cZJ81oWvgSnEdqaQeukSecV5xvIeJdjEfzLBYa1KhliQF6Ff/WhUvH5alR1fU0YLOI znhu8n4P+OeNxxs56WzBTo1usaOzGCvk140ruR0YfGf8tgy4PwHh/fgf7a36yH+KO+XF QBWDfaw2f/IqZiBj/Hjag2qEETMW98xfHeZnch4UWsS16kT2nnVyFi97Vi1p1zVb27FD tci2Lsk/SofZMlSbp6em/SMkK9SRQXjt5ttQS0ryv9PI6q7IdKjMFy8ZfXKlkmGdAm4B 01oTzYliCPmn2pj8Rl81i3vW1+EYERxUSYNVt8g3YCRIPClsCguLeLuqz64649mIu05M 4SrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=FKFAeXsT1JOQj6q2CxLqSu6T9f6tbIUKzOdIIHyDfWI=; fh=DMP0F9ULS1guKiqimntQRCN8ZraraesEgQuVcn7F0Z0=; b=lQZ0J6Wj1nku22bkq2LTLY+xFLz1zgQefNdR7vF12W2xZ3uxQWnHoubjGjaJnzV27/ 8KRkWgIK+aDOHsqBL2Rm9+z1jvS40XYR4UojhyIM+CcD1gw2xrR9AHXOwFo65YAqp8Z0 Ry90jJfBr0rKJ3w5ODCI8bN07fQutFVrkGsIzEX1/aazA4MJuE91Gk8y1JCbClyMSzo2 Hc5FSOxZt1RJQ3m8bcDJGivwpzwUKCIxsWM/dQ0Dxh1uwOw6sxXO/iETll4gOjza9R+I Uz9hMv0Z4MKe66Hf1wDkE/v7TCmW74A0BKUMoxSeG9CpN8JeO2NtLIY+WgFdymVdAXFi zRoA==; 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=HFYkMi0+; spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::52c as permitted sender) smtp.mailfrom=earonesty@gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com. [2a00:1450:4864:20::52c]) by gmr-mx.google.com with ESMTPS id 4fb4d7f45d1cf-64b5881d3easi15075a12.3.2025.12.17.12.57.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 17 Dec 2025 12:57:52 -0800 (PST) Received-SPF: pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::52c as permitted sender) client-ip=2a00:1450:4864:20::52c; Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-64b58553449so354061a12.1 for ; Wed, 17 Dec 2025 12:57:52 -0800 (PST) X-Gm-Gg: AY/fxX6QyCJiVgt+QqYT0fOj/CNFWxYm0J1BgRJjhda9o73hQ6WOJECdqUDJ0LsEV0b VVKQ/FqYnehzRfUNgHscMkOu7sfidXEXJgmCbsZAlAH/ikhGPmBLVt6mKYOoUCDo7lAEdbf0dlT PXVjVH1frq7W7HsrIkEVP/PE0QRXO482GTyU+Ubs9ccaQdD4Llw1xJa0zs0cSdBiZTe9ux5nqyk 7kcj8HiNv2Mab8i+f0IGUUpMtN3IZtL+dBvwJDRSHCPZVNzKsWGE02gVnCz5ZATt5ljlsvZdeq+ em8LXRnN2k3B2rCWHtCNjo4Mfo8pYDaP+Q== X-Received: by 2002:a17:907:d94:b0:b73:5f5e:574d with SMTP id a640c23a62f3a-b7d23a89c52mr2020053066b.59.1766005071961; Wed, 17 Dec 2025 12:57:51 -0800 (PST) MIME-Version: 1.0 From: Erik Aronesty Date: Wed, 17 Dec 2025 12:57:42 -0800 X-Gm-Features: AQt7F2r4LVtn0IvL762vdzg_Y4z5KaEJBFTIvJGsyaq2kqlB4A0wHDXYI_CWV0g Message-ID: Subject: [bitcoindev] Perhaps the simplest possible quantum-security upgrade To: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000fc647506462c183d" 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=HFYkMi0+; spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::52c 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 (/) --000000000000fc647506462c183d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=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 secur= ity 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 --=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/= CAJowKgLR%2BvjYrUXuJ-k3FZ9%3DZnOj3f3w2qB%3D%3DM7-yrbQYx_h2A%40mail.gmail.co= m. --000000000000fc647506462c183d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Was thinking about this and I realized that a quantum-r= esistance scheme doesn't technically need a new "signature" -= because those constraints (generality) are far harder than needed for Bitc= oin's "proof of utxo ownership".

Instead of new signatu= res, I propose a chain-native authorization primitive whose security is bou= nded by the same economic assumptions as transaction finality itself. The o= bjective 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 spen= ds.

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/CAJowKgLR%2BvjYrUXuJ-k3FZ9%3DZnOj3f3w2qB%3D%3DM7-yrb= QYx_h2A%40mail.gmail.com.
--000000000000fc647506462c183d--