From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 01 Mar 2026 04:31:00 -0800 Received: from mail-ot1-f64.google.com ([209.85.210.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vwfwo-0000VD-OR for bitcoindev@gnusha.org; Sun, 01 Mar 2026 04:30:59 -0800 Received: by mail-ot1-f64.google.com with SMTP id 46e09a7af769-7d4beca8c53sf43815424a34.2 for ; Sun, 01 Mar 2026 04:30:58 -0800 (PST) ARC-Seal: i=3; a=rsa-sha256; t=1772368252; cv=pass; d=google.com; s=arc-20240605; b=THVjNWOhouemnWDqZlBBGgTnYW1bpCDBIT/dYplhm2McprcPSGfAUqor2UjA2j5Vcc K3Igbhh5I0489T2cUBXtAavq/HWGtv9u7DGckhLE05RW79QyZVdGtlBRdAKd+iVIxxY+ 0J4IPmBySQpq3LafABCbj+vszwI5iH0pe8d9fK07e/1AV03nnwoiBMTbITgk9L7sCbme YJwUROlayr0sdkLxoW6l0OrrwIMcFWaFvzCEACW8YVQft/2lXI/+rkQnB2YPMze8rq1E sYBao+OBI4vte+Kh9VFA3zaKob+XgJWNClQkqneLQ0hb2P1a98JVhmx36djG23Le0oj7 GDog== ARC-Message-Signature: i=3; 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:reply-to:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:dkim-signature; bh=Hfjwk1EM6fIGrgOjOf/63qDPjE7hZ74zdLDJHE3UHPE=; fh=xiHbnjCzgRJevU555MsGYJJqrueJOPyau5EyEob99WY=; b=Vy6MHaEUGkfz2MLJUgZWsLZNn+857zE+BNQRDiMEpSXKeFaRM5XpQ6QaKxlYMiShK+ LoB/T7Cir24geGPNnkfxrLwCUnxn+fCe+fs7HRG2IUlwod7EZbK18LxzqBBhq5RwmQEq LQ0pIjgfnFvN2ydzZBu9QyzrhluYpdohMimnfxJXksnidcI76tvdRauU0QjEJ69x3WAh 1Eo1HZMrHZ5oKYckTw5rZUSaa2lxtVZih5400cK1a/3f3t8TQsJlOsSA5isYQJFlB0d+ G2otja7fWc2IBVqo1uH54TWR4Z1oW0nX+95UmVl4eZHhD1JDqJnP95auITpazsEpLxOS 8T7Q==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@blockstream.com header.s=google header.b=Uv9zlq8i; arc=pass (i=1); spf=pass (google.com: domain of mkudinov@blockstream.com designates 2a00:1450:4864:20::231 as permitted sender) smtp.mailfrom=mkudinov@blockstream.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=blockstream.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1772368252; x=1772973052; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version:from:to:cc :subject:date:message-id:reply-to; bh=Hfjwk1EM6fIGrgOjOf/63qDPjE7hZ74zdLDJHE3UHPE=; b=A5mYpHTSyLZLoxtcat+g4Fe6QLo3FAFvo0qr9gFo3LQRB4KcksaXzsRBiny/ylZocS VHO7BHIrhkRb92VjhPHA9pAruU4rNKqDpm0SMB4YvG2rQJ1P/G/YyS10rd0/NZT/9/Sh MsQMPFADvRH8z5uBBkumXYvhcHsqaYIP6ZolSaG2d0RpVUIZULn+WEW1eFNZJRtLRO1D zodOmCgxAj+RrQUoqrcdm9spgijvi2rg4hRkv7LWkWlTvo90F23rkH12qT9Fd9Z73wP9 BZdcRxO1p1HXTokbp3NwntznWALwbbSSemdBMEqOoc5lN2fWyiFnu2eFTGnBHwOjb6+q 8I8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772368252; x=1772973052; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version:x-gm-gg :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Hfjwk1EM6fIGrgOjOf/63qDPjE7hZ74zdLDJHE3UHPE=; b=gnAgghxAqFw3bupj6xOkEhb1KEtJ5IpjaZgksksG1jABjw2rjP79vkPUUc2/QQH05S MAQI78p4uA31JH7LRuDhorC9gdPiFY91IxFnO/TatsydEKf9INburLJz8ZSFQ1Aq06tr +P60Q0ownTkaE8epKgMqMb4462kkt4I8crb1OeXca1O6KAPVKnzCY1AKdxvzusRPCzAg Ls++/JaWERmHH56Z9cEnRrFYZThPykRMBUNoef4jEjQIaKKya/gSv6oWYQwss1CJteEh tnehhuruzrT4zchhrVhFnUEm5yzOj30DwrC84+34CveyKcni9JLJPK3VpaS6hXiRcN5o 7CPg== X-Forwarded-Encrypted: i=3; AJvYcCV5TkTfdDItXQl9kBcEgYZZBZ9OP0g0QPEQRqWHVhNzCFG65XWd3Cquctnv7uTCbeGeXLgHRHlcSyxh@gnusha.org X-Gm-Message-State: AOJu0YwhOwx8499jbfA5LhASMRb++sqfW1XbjDp8Kzk3XRZLiBiA8sYw DXiVY9q6fyX0mmvUHwuUpneWi4OzxZHuAyt/OW4H3VfEgN76soqJ+Qzb X-Received: by 2002:a05:6871:c902:b0:409:b130:787a with SMTP id 586e51a60fabf-416270ff39fmr6069653fac.46.1772368251863; Sun, 01 Mar 2026 04:30:51 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+FAeZzS+dWiLNnuVnWVyQ7k0RcvWQqnE9xl4fFe/1My7A==" Received: by 2002:a05:6871:8706:20b0:409:6e30:2d79 with SMTP id 586e51a60fabf-415ede70776ls1368808fac.0.-pod-prod-07-us; Sun, 01 Mar 2026 04:30:44 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCWyVqnQJfoje4mgacTjI4twQ1wAnAY4re0jAGBl3Hn09iGTmR6P5lGqr8sySubek3ef+b5iiv9KLhUq@googlegroups.com X-Received: by 2002:a05:6808:1186:b0:464:305e:8fcc with SMTP id 5614622812f47-464bead18fdmr4869927b6e.20.1772368244384; Sun, 01 Mar 2026 04:30:44 -0800 (PST) Received: by 2002:a05:600c:41d5:b0:483:6a76:922 with SMTP id 5b1f17b1804b1-483c9ca729bms5e9; Sun, 1 Mar 2026 04:24:17 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCV7YiqYfhzAmNLlR9keoBvv92tKW7DK5yGlzcG1wo5fQF5X7n1EZJBzfMTEeMzW63ahUO1aMSJXhDMw@googlegroups.com X-Received: by 2002:a05:600c:474c:b0:483:a352:b4e4 with SMTP id 5b1f17b1804b1-483c990bdf0mr151402735e9.6.1772367855109; Sun, 01 Mar 2026 04:24:15 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1772367855; cv=pass; d=google.com; s=arc-20240605; b=iQu+BqT18cQ50Sua/A7N6a0kyrJAFS/90YgQ+qZuSiBICvH3kMI5u7MKivL/fE854v XrRQyLlxrdIEmRZlA5slhmJ7yFYz6cjDSCaIu5XhsQ1d4bOgQoU9hDDw4vn7xB0R1rsG MGWrFHAzmBi1jAktHyJRwG0aP6BcbQquTdP8eKuA5dXz/rExExWmq9FcPMSMpGepCmgx upDMyuoGe3qBfhVLUJVE5J8IkZKPggro5fIn7ZmEdep6tV/Sv2YobtADWFGRfdT3KJnQ c3+JOZUBdZqrrfxw+UgrxKUH8B1XaffYziQy74U//1J3fvYgZifXKHM/UlUesNj0ZVcP ocrg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=YFv1PCKOImUInzo/BSTVDvQ4do5/O7l2nlMB66DYoB4=; fh=KqbMxrGhK/Cu4S+TAJTGxs54E/9tjBhvREa17lBQuAo=; b=DeD8V2og2VKHzrY9INAdtDDiDe9hEPnyGHFiIIGGWCVLdpmgCadBPeMkCC3JdjB5I/ DXGKG8wCCFA0bQXT8so8B1f/dWbDnKS9P3YK9SRQ5jEHLpsz0jqPaUjGT0dKkRNncz0j TYGi4ujRR1NJQrpsAdB6paifJC0f94d8pbbyCkBQEetyF7ORwsL2PT3RlwYlD8jiJXtf mRV8pbnmnwXO4pf1pLFb0ErNbr2P8ug7s/xXcu34wkbmfvC8xu6cZkdGT9x21VhSGJPe jedm/HqLVxnLrZ7R5VKHBxjQgH2Z71SaUbGRNLbJljZEhnyS/p7z+WmIue5Kh9h3zaV5 XVpQ==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@blockstream.com header.s=google header.b=Uv9zlq8i; arc=pass (i=1); spf=pass (google.com: domain of mkudinov@blockstream.com designates 2a00:1450:4864:20::231 as permitted sender) smtp.mailfrom=mkudinov@blockstream.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=blockstream.com; dara=pass header.i=@googlegroups.com Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com. [2a00:1450:4864:20::231]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-439ad99599fsi56893f8f.8.2026.03.01.04.24.15 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 01 Mar 2026 04:24:15 -0800 (PST) Received-SPF: pass (google.com: domain of mkudinov@blockstream.com designates 2a00:1450:4864:20::231 as permitted sender) client-ip=2a00:1450:4864:20::231; Received: by mail-lj1-x231.google.com with SMTP id 38308e7fff4ca-389ecf61114so3753121fa.2 for ; Sun, 01 Mar 2026 04:24:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1772367854; cv=none; d=google.com; s=arc-20240605; b=jpBTIabdyV9ccP58KOSBWM2ag0sWyTouZ/XJTD0hCejbliAxKcL01LkQsVHQJj2QL2 c55UMYLc9J12y8d3mqMOUXW5vmzjxRYbQWWYHAEknaiG9KtQEL5NU48U2xhNaywSEigY 6CFutlTdwLeumk5Q3GhViR9pZrX7XU4E6I5O9tLUC3KZSKX5ShATWB1YeANBpv8H2I/G qitYJTccJlT5afgBjW/CstzjtPEuzCW5j6iWMOovVsK/D+SCJKoVe/TPie8k9co28FWj 3+2vZNUXqSQH0pwtkefhBklm9ntuZ4snFa2OOHSdMfULXlivL1POzfTdizHwiDBTIaa+ HarA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=YFv1PCKOImUInzo/BSTVDvQ4do5/O7l2nlMB66DYoB4=; fh=KqbMxrGhK/Cu4S+TAJTGxs54E/9tjBhvREa17lBQuAo=; b=BUewAlzSXcuqizZfytntljDpX0f/jbmm0lHfSWKgm2X4nNOidOKN52OX4RFoekBPv6 v/gXaITj1pXi9dnGj6uQ5vA05qBYMbusBG5TKt/u+DpDcX7pOAOfl+9+NH4Opw7qsUXP i/iCfx7HDNj8zyCmh3+V+tXlXSboBsmuHsWR7fa54Akf79BVvyNJ+PRSHn8AdNt/U7zX 5gZtmqD4HPK1z17+KC74kp9adpEw+3eMHRc5SDmK/bdXOHH76afMbHIkwU7g/Dn1iolZ OnKF0i/tpMaQfOuygPy0XDxu0YRHGgIZ+khZ4ibIYgKfs7PRfv+nKTFH7SsRDMh2tPg2 ANtw==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Forwarded-Encrypted: i=1; AJvYcCVbYE6Wn7X/NmwHgB/FpVQ1/IPJhTh1sIBdBI+s4Db50sWrTZvPK7BrB3rKGihRl13tOU9VBCg85gox@googlegroups.com X-Gm-Gg: ATEYQzzonebCMbzqmGnE+Ze4n1FXV8HoME/seNz0Rdj6V0YCw/VYK8QNpPDOdc3yHwf b/j8uTxyPWF8e2I6mCxOaw42YKWIO5C1Y80aU3XUQjKtZEkeouS6HZUcp4Eg5FexhJe6Wo91SMP FAvuR7lGlnXoox81ilsFcLL/NuKxHRuofKUvafEbzci3OngegaT+1PXSCCVu2QoSjZtdwAQKdkX WQyV1gOKDYrPT2Zw58qK5HKz42hFU2QuBhcswYWYnl1zrT8gnh85+WZEq20dk8pw1WBINFzMC6z /7bz2mtn+8rFSigEXC1yIKC29JMu2ts27BZC X-Received: by 2002:a2e:a808:0:b0:383:2856:c99b with SMTP id 38308e7fff4ca-389ff3645f9mr26736281fa.8.1772367854142; Sun, 01 Mar 2026 04:24:14 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "'Mikhail Kudinov' via Bitcoin Development Mailing List" Date: Sun, 1 Mar 2026 13:24:02 +0100 X-Gm-Features: AaiRm50wI-BU4CwSR2JrFQCgPvZQ3bR7RUW_nVwek6bk4s-agfk6jJv-ATGIFWc Message-ID: Subject: Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms To: conduition Cc: Erik Aronesty , "garlonicon@gmail.com" , Ethan Heilman , Jonas Nick , bitcoindev@googlegroups.com Content-Type: multipart/alternative; boundary="0000000000005b97ba064bf58c10" X-Original-Sender: mkudinov@blockstream.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@blockstream.com header.s=google header.b=Uv9zlq8i; arc=pass (i=1); spf=pass (google.com: domain of mkudinov@blockstream.com designates 2a00:1450:4864:20::231 as permitted sender) smtp.mailfrom=mkudinov@blockstream.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=blockstream.com; dara=pass header.i=@googlegroups.com X-Original-From: Mikhail Kudinov Reply-To: Mikhail Kudinov 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: 2.0 (++) --0000000000005b97ba064bf58c10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don=E2=80=99t think that Fault attacks are mitigated for SLH-DSA, the mit= igation that is available is to run the signing process multiple times and check if the signatures are the same. But fault injection attacks require physical access to signing device with the ability to flip at least one bit during the computation. As for the security proof. There was a problem with the old security proof, but the scheme still had a proof, just not as tight as it was claimed. The problem with the proof did not constitute any attack. A new proof was constructed with out changing the scheme even slightly. This new proof was later formally verified with EasyCrypt: https://eprint.iacr.org/2024/910 =D0=9F=D1=82, 27 =D1=84=D0=B5=D0=B2=D1=80. 2026=E2=80=AF=D0=B3. =D0=B2 22:2= 1, 'conduition' via Bitcoin Development Mailing List : > I thought "tweaking", in general, is lost in SPHINCS, as well as > multiparty sigs. Be interested to see those solutions. > > > This is correct, but you don't actually need public-key tweaking to use a= n > SLH-DSA pubkey as a backup for an ECC xpub. You can just append the SLH-D= SA > public key to a BIP32 xpub, and use the result to construct PQ-hybridized > child addresses. For privacy we can attach a pseudorandom nonce derived > from the chaincode, to prevent on-chain fingerprinting of unused BIP360 > leaves. The resulting tap leaf hash looks random, and the SLH-DSA public > key (and nonce) is only revealed if used for spending. > > All this will be spec'd out as part of a non-consensus BIP, to help > wallets build safe and robust quantum-resistant addresses. > > I provided an example script that shows how it works: > https://gist.github.com/earonesty/ea086aa995be1a860af093f93bd45bf2. you > don't pin to the final destination in phase 0. > > > This pseudocode seems to commit the CTV hashes T & E in the anchor_script > which > is used to construct the funding UTXO > . > This is exactly the problem I mentioned which would prevent this techniqu= e > from being usable as a PQ fallback script. > > txhash is a partial-commitment, not over all fields. this give the > flexibility needed for the final spend, since you don't commit to it. > > > You've stated specifically in your post that TXHASH enforces that the > AnchorPublishTx=E2=80=8B creates a UTXO paying to P_anchor=E2=80=8B. > > OP_TXHASH is used only in Phase 0 to enforce a partial covenant... [that]= pins > the next envelope (P_anchor) > > > You've also stated that P_anchor=E2=80=8B commits to the CTV template has= hes T=E2=80=8B & > E=E2=80=8B. > > P_anchor: Taproot output key committing to an Anchor script tree that ...= enforces > reveal-or-escape spending conditions > > > This statement is backed up by the pseudocode which depends on T=E2=80=8B= and E=E2=80=8B > when constructing P_anchor=E2=80=8B, as i pointed out earlier in this ema= il. > > Thus, TXHASH (and by extension, the funding script pubkey) commits to CTV > hashes T=E2=80=8B & E=E2=80=8B, yes? > > Perhaps it would help if you mentioned which TxFieldSelector=E2=80=8B you= are > using, otherwise i'm just left to guess. The pseudocode is unclear. > > regards, > conduition > > On Monday, February 23rd, 2026 at 11:08 AM, Erik Aronesty > wrote: > > >> >> I'd be excited to learn about this as an option. Erik, could you please >> answer my previous questions about the viability of your linked protocol= ? >> I'm not questioning its quantum-resistance properties (yet). I'm wonderi= ng >> how it is possible to instantiate this scheme in a way that allows a wal= let >> to actually use this commit/reveal scheme without knowing the final >> destination CTV templates (denoted T & E in the delving post) in advance= of >> creating the phase 0 locking script. >> > > I provided an example script that shows how it works: > https://gist.github.com/earonesty/ea086aa995be1a860af093f93bd45bf2. you > don't pin to the final destination in phase 0. > > txhash is a partial-commitment, not over all fields. this give the > flexibility needed for the final spend, since you don't commit to it. > > however someone has pointed out a fee-problem that CCV's value-aware > composability can solve. coming around to thinking the ccv-based > construction would be necessary. CCV is more powerful but requires much > more care in policy and analysis. CTV is trivial, we could merge it > tomorrow and hardly worry about surface area issues. TXHASH is only > slightly more complicated. CCV has a much bigger burden of proof around > implementation and node safety... but i think you could do many kinds of > vaulting schemes with it alone. > > > But in the case of hash-based signature (HBS) schemes, i disagree. HBS is >> already mature. Whatever cryptanalytic breakthroughs the future holds, w= e >> can be reasonably sure that SHA256 preimage resistance will hold for a l= ong >> time, so HBS security will hold. Even today md4 and md5 preimage resista= nce >> still holds. Securing coins using hashes alone is the ideal fallback, an= d >> even if HBS is not the most efficient class of schemes, that doesn't mat= ter >> so much if we don't use HBS as our primary everyday signature scheme. It= s >> value lies in security, not efficiency. >> > > When I mean "too soon", I'm including SPHINCS, not sure what > > 1. Earlier versions of the SPHINCS framework were found to be susceptible > to fault attacks > 2. Earlier "Tight" proof for v1 SPHINCS was flawed, leading to 60 bits of > security, not 128 > > > If you're worried about stuff like how xpubs would work with HBS, we > have solutions for that too, and they are mostly drop-in replacements for > existing standards. > > I thought "tweaking", in general, is lost in SPHINCS, as well as > multiparty sigs. Be interested to see those solutions. But, regardless, > 17kb sigs are... not compatible with a decentralized bitcoin, imo. > Lattice-sigs are the only reasonable PQ way forward and they aren't ready > yet. > > > -- > 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/xGWRYbDSxkWxiv5eYH_LbX3hTXs1= x2wrn6ar5EfMKKCwvRAT137keXQZqs9SaeTxOjrb5tziRcFU82wSPGD-QVokCrA-Aikfr4vktqS= vK7c%3D%40proton.me > > . > --=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/= CAPcK4uR_Zh4Mncjkj10CDojs%2BddYB08CT%2BJ3coWSKEBL%3Dd_EJw%40mail.gmail.com. --0000000000005b97ba064bf58c10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don=E2=80=99t think that Fault attacks are mitigated fo= r SLH-DSA, the mitigation that is available is to run the signing process m= ultiple times and check if the signatures are the same. But fault injection= attacks require physical access to signing device with the ability to flip= at least one bit during the computation.=C2=A0

=
As for the security proof.=C2=A0
There was a problem with the old security proof, but the scheme still = had a proof, just not as tight as it was claimed. The problem with the proo= f did not constitute any attack. A new proof was constructed with out chang= ing the scheme even slightly. This new proof was later formally verified wi= th EasyCrypt:=C2=A0

=D0=9F=D1=82, 27 =D1=84=D0=B5=D0=B2=D1=80. 20= 26=E2=80=AF=D0=B3. =D0=B2 22:21, 'conduition' via Bitcoin Developme= nt Mailing List <bitcoind= ev@googlegroups.com>:
I = thought "tweaking", in general, is lost in SPHINCS, as well as mu= ltiparty sigs. Be interested to see those solutions.

This is correct, but you don't actually need public-key tweak= ing to use an SLH-DSA pubkey as a backup for an ECC xpub. You can just appe= nd the SLH-DSA public key to a BIP32 xpub, and use the result to construct = PQ-hybridized child addresses. For privacy we can attach a pseudorandom non= ce derived from the chaincode, to prevent on-chain fingerprinting of unused= BIP360 leaves. The resulting tap leaf hash looks random, and the SLH-DSA p= ublic key (and nonce) is only revealed if used for spending.=C2=A0

All this will be spec'd o= ut as part of a non-consensus BIP, to help wallets build safe and robust qu= antum-resistant addresses.

I provided an example script that sho= ws how it works: https://gist.github.com/earonesty/e= a086aa995be1a860af093f93bd45bf2. you don't pin to the final destina= tion in phase 0.

This pseudocode seems to commit the CTV hashes T & E in the <= code style=3D"font-family:monospace">anchor_script=C2=A0which is used to construct = the funding UTXO. This is exactly the problem I mentioned which would p= revent this technique from being usable as a PQ fallback script.

txhash is a partial-commitment, not over= all fields. this give the flexibility needed for the final spend, since yo= u don't commit to it.

You've stated specifically in your post that TXHASH enforces that the = AnchorPubli= shTx= =E2=80=8B creates a UTXO paying to P_anchor=E2=80=8B.

OP_TXHASH is used only in Phase 0 to enforce a part= ial covenant... [that]=C2=A0pins the next envelope (P_anchor)

Yo= u've also stated that=C2=A0P_anchor=E2= =80=8B commits to the CTV template hashes=C2=A0T=E2=80=8B = &=C2=A0E= =E2=80=8B.=C2=A0

P_anchor: Taproo= t output key committing to an Anchor script tree that ...=C2=A0enforces reveal-or-escape spending condit= ions

Th= is statement is backed up by the pseudocode which depends on=C2=A0T=E2=80=8B and E=E2=80=8B when constructing P_anchor=E2=80=8B, as i pointed out earlier in this ema= il.

Thus, TXHASH (and by extension, the funding scr= ipt pubkey) commits to CTV hashes=C2=A0T=E2=80=8B &=C2=A0E=E2=80=8B, yes?
<= /div>

Perhaps it would help if you mentioned which TxFieldSelector=E2=80=8B you are= using, otherwise i'm just left to guess. The pseudocode is unclear.

regards,
conduition

On Monday, February 23rd, 2026 at 11:08 AM, Erik Aronesty <erik@q32.com> wrote:
=


I'd be excited to learn about this as an = option. Erik, could you please answer my previous questions about the viabi= lity of your linked protocol? I'm not questioning its quantum-resistanc= e properties (yet). I'm wondering how it is possible to instantiate thi= s scheme in a way that allows a wallet to actually use this commit/reveal s= cheme without knowing the final destination CTV templates (denoted T & = E in the delving post) in advance of creating the phase 0 locking script.

I provided an example script th= at shows how it works: https://gist.github.com/earonesty/ea086aa995be1a860af093f93bd45bf2. you don't pin to the final destination in phase 0.

txhash is= a partial-commitment, not over all fields. this give the flexibility need= ed for the final spend, since you don't commit to it.

however= someone has pointed out a fee-problem that CCV's value-aware composabi= lity can solve. coming around to thinking the ccv-based construction woul= d be necessary. CCV is more powerful but requires much more care in polic= y and analysis. CTV is trivial, we could merge it tomorrow and hardly worr= y about surface area issues. TXHASH is only slightly more complicated. C= CV has a much bigger burden of proof around implementation and node safety.= .. but i think you could do many kinds of vaulting schemes with it alone.


But in the case o= f hash-based signature (HBS) schemes, i disagree. HBS is already mature. Wh= atever cryptanalytic breakthroughs the future holds, we can be reasonably s= ure that SHA256 preimage resistance will hold for a long time, so HBS secur= ity will hold. Even today md4 and md5 preimage resistance still holds. Secu= ring coins using hashes alone is the ideal fallback, and even if HBS is not= the most efficient class of schemes, that doesn't matter so much if we= don't use HBS as our primary everyday signature scheme. Its value lies= in security, not efficiency.

When I mean "= too soon", I'm including SPHINCS, not sure what

= 1. Earlier versions of the SPHINCS fram= ework were found to be susceptible to fault attacks
2. Earlier "Tight" proof for v1 SPHINCS wa= s flawed, leading to 60 bits of security, not 128

> If you= 're worried about stuff like how xpubs would work with HBS, we have sol= utions for that too, and they are mostly drop-in replacements for existing = standards.

I thought "tweaking", in gene= ral, is lost in SPHINCS, as well as multiparty sigs. Be interested to see = those solutions. But, regardless, 17kb sigs are... not compatible with a = decentralized bitcoin, imo. Lattice-sigs are the only reasonable PQ way f= orward and they aren't ready yet.

--
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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/m= sgid/bitcoindev/xGWRYbDSxkWxiv5eYH_LbX3hTXs1x2wrn6ar5EfMKKCwvRAT137keXQZqs9= SaeTxOjrb5tziRcFU82wSPGD-QVokCrA-Aikfr4vktqSvK7c%3D%40proton.me.

--
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.co= m/d/msgid/bitcoindev/CAPcK4uR_Zh4Mncjkj10CDojs%2BddYB08CT%2BJ3coWSKEBL%3Dd_= EJw%40mail.gmail.com.
--0000000000005b97ba064bf58c10--