From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 23 Feb 2026 14:03:10 -0800 Received: from mail-oi1-f191.google.com ([209.85.167.191]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vue1F-0004ZE-Sr for bitcoindev@gnusha.org; Mon, 23 Feb 2026 14:03:10 -0800 Received: by mail-oi1-f191.google.com with SMTP id 5614622812f47-45f11f18a89sf63828248b6e.2 for ; Mon, 23 Feb 2026 14:03:09 -0800 (PST) ARC-Seal: i=3; a=rsa-sha256; t=1771884183; cv=pass; d=google.com; s=arc-20240605; b=VKf8LPiG+SjABh11ZgmxiJFDe/SmCFl6wCsArWMO84nrTfpc73VWdvlzYHxQxCFkSP 9AhNbT4javNwC5Rrg+FsGODoN+/IzqFs/bkkAIgdKB/KFyW7LqSIYWpmCPxVbljLdkEO Zti7Vqx+koS0AiOxSJL3v7d1nDsh7lgfUA0H9eRZX8/6NTtHO2A5WaLfGczc4sBl28sz a+PRzjEHDOh45AX+8w94CNHURPPeFm0vCxZ5147RZ+ozaikP8mSmvpwB0pbB3rGICz9d equ8KFHPI3jA2wkW2jTQ2q9/PMiYm1hprtKc3h0pTn9RacGiK8NCOqKFrWOCqLj4UycF PtHg== 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:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=0tQXmQHEVgWmOPvrZcN2P+bOBtaDFrpr3ilnZcPzJXE=; fh=aINScm8/gHuMhjqHkAsUXDH8V1NNv9X8X3WYRZ+s71g=; b=HZRiEvAekvIoTpYvbG6Nt2q7WMip59+QvrWMZvwu8FioDPhLlvYoja6vNE47mFW+Nr XfEZZj04WXposTj2bEBWDyVlXPi/rEaRdpqv0+Dl2+zwufMRqJ2+74S7m6KamhYSnr+U nqyqUVSblRDm+HeX+CgVzKFlnKbiNFqWkolxZUj/Ase0W39pE3Sbil22j6uliQiKTzn8 1D5Q9Uw5vJ1WiCiEJNBHhhuaMxOnuxWz4dTVuIfdvxKho8lpX88RFg8jnlz/D9OWCXHn 1H/H1MYlu6lc5dIaOCmvP9dX7JRKYvfdS9X3EFgVVZwjsmwGfmHKWykXN+wuCRNAtISI U6vA==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=YqZj1cZW; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::536 as permitted sender) smtp.mailfrom=eth3rs@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1771884183; x=1772488983; 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:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=0tQXmQHEVgWmOPvrZcN2P+bOBtaDFrpr3ilnZcPzJXE=; b=oSGuQoWSFjWqSA+BuKwy8TJf2jXgviYivrBlrwkvJXmOft3p1krcloqJKqamjS1S0p TwQ/FwFkAvtr+puLd37M3dTMjat1T+Aibh10zrWDvDbfDpHjptpPpo6yype1uSVQtdDL +YA0kEwcnaGsLgCNS6PnYCDVf+p4dDWBlfrOJK9twdw1alfYOut6fqiCdL9J4F51rWRy KVEjKxKeaZ4KqKQXrx2+2CLp9zVhHbjChMSdK053xuGdrdzsZRhnxT9h3eg5iGMbR19u UeBhX0tLr5X2mrtS4FTiwBhZ5Iiab5Hp3AIffl7s+UXyldipFJsWG8JbwOgStEP4POMj WN6w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771884183; x=1772488983; 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:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0tQXmQHEVgWmOPvrZcN2P+bOBtaDFrpr3ilnZcPzJXE=; b=PpN5dH6Rlb1D7nhOVkXv/xTATrTJ++A/HOp8+lTMnkpxPrg8IzJwgTTHIYBhRSqGC6 Cml5pJg5uoVqJ1OB80f77QuF9vDa6lMDuWtgX387Cow1zsIgalg/Nnmv8nPtnDvnTyGO UMqFJvJFR4RqI5tj783a91CkFQ1xX/iu2xFzDTRw2zk7UIQyiY/PXihAPKo8uuM4sCek ftpBF9pjWA2SgkdhQtw2r7al3X7jndfbImuatAlkCZvDmZUb56qzAlxoGtp06tjLccE/ grduNrlxPUpFFYXAufHFEucgcZUm54q89BXgXybdIT8Bf/dXhob80MxHIHBgaCrCRsIX WoEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771884183; x=1772488983; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence: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 :sender:from:to:cc:subject:date:message-id:reply-to; bh=0tQXmQHEVgWmOPvrZcN2P+bOBtaDFrpr3ilnZcPzJXE=; b=Vcz5OFkzCwPyW2V8xcXIwzuuHhyQGJSk0LAKAZ+PGn/nl69q49AhyucMTY4QVPQxyp SsgqiIT/jT3mUkuleSQDU4IOMvn+LBXWx5V4tRBLLqplWd/m8aU3Bt5KEuOCoTuAs+bq rsPHXaV8dF1HIEPIhBX5qFP0MvhsT0E26DZBAAJQuX/BMEsUj7nstvtivifqRhqqA7D4 lI8A1iMeZyYz+3riegDtmdyAdT17BrQi0OwVKKEDSybX7yK3fn28FATZRCnTlIVVIxPA D3wodMdq+4JGPd2wJsM53NJYn/98dt2ElwnJxj46q4iw90cVR+Bs+6hKDiEIWFXaq2hk VKsw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AJvYcCVzV4Q6NPuOwB4OzBiCHwwMNiifr/zUHIBhwGbR995mi1RBxTzWBVaPM1jgeYXISJg3uPq5pgHFa5oY@gnusha.org X-Gm-Message-State: AOJu0Yz1K6z6/mLems+0BZT6GWJ5r2f2bMM7U3UwpTfMCqMolUg9Nu58 T7SMFzlv0BPYcZtfCdmLIMiab58/bjj8EVdEL3NaLcED7PNHWq9EiLUj X-Received: by 2002:a05:6808:1710:b0:463:ab56:9ed0 with SMTP id 5614622812f47-4644614357amr4932546b6e.2.1771884182951; Mon, 23 Feb 2026 14:03:02 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+Fi9fCThfoE7rNbMns4YWVrMgDqaM8hvE7X8FU/urgUrA==" Received: by 2002:a05:6871:7bc6:b0:409:6e30:2d79 with SMTP id 586e51a60fabf-40eca34a61cls8722853fac.0.-pod-prod-07-us; Mon, 23 Feb 2026 14:02:57 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCV1J/njFhtRP+NySJC0UaXTo7abVbkMkBXQ2JDvafi/OrmRJsOMbCGuxt+dQoXUzoGx48mpGVap+0gx@googlegroups.com X-Received: by 2002:a05:6808:158f:b0:463:ab56:9ed1 with SMTP id 5614622812f47-46446142794mr5090564b6e.6.1771884177731; Mon, 23 Feb 2026 14:02:57 -0800 (PST) Received: by 2002:a05:6808:b2b:b0:44f:fe66:38a2 with SMTP id 5614622812f47-46395e57794msb6e; Mon, 23 Feb 2026 13:43:27 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCUp0R15GfNfwhfsTGyv1bPsfTYg6LbtGeKgv/p+tJLYb6YnKU+sEBg1Mu2dRN5JHIFzrlZvRPqMLnjA@googlegroups.com X-Received: by 2002:a05:6a21:b8f:b0:36b:38e0:4bf0 with SMTP id adf61e73a8af0-39545f8ff91mr7940650637.60.1771883006929; Mon, 23 Feb 2026 13:43:26 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1771883006; cv=pass; d=google.com; s=arc-20240605; b=WdkIjguMqMuedwCokGMKW1HVgXQ+mw/nuBTcjt18CWAfXVQwkIwW0omJqvXP5HkOvA ZUrhWY+Ibeq44QWMNGHfuJgs7Oop2jlpoCCH8XB1qvmjkSmOBpG5FhGGQKfEL6myi+O9 buDyuCSenDS3Zs7LOxZNwXgkQ0PqDXs2c9He7Idhgh9GtpVXWjLzahc2HQnfFr9tCQ1e sUZ3mjH3RJJceUS+r3XS+e+htDm0LR7vuOmxd52nr7CwHOv1hjoRhtVVyKzG2vheOhIP xM5zjZerDLGyAgCeCGb6jt6B7JLZMB8HYk3DFGGk+F8tttmGcnn3Ecjo5zN7ozZvR6KC q4WA== 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=iHdvVV6ZS486eVEqrg/4PntzQQ2ovYjA/iX5rZ5mIC4=; fh=b4hteE3ppcqEvxdtR7+0ORGsFt2Be6SKqAVC7pct0/M=; b=beTmgIz1p6R13hM06TGf6BJM3WcnH8+/bbBD0AIEdBx0VryocemREKTEH5qsQ3K1Fu NJcRh1qBhQguwch4mmXK/FQhaz8rYchn0IML4g52n+TV48/JbFx7oSADqrBjHwXPibPM FYPsw/oejkOG/OaLWh47S7HXccz2AJz9WakKV0dfdG2WlYaA0XG04O+U0EUDDD2Fz3rf BPo/7IiRlVt9lTu7L2dSJTqSh44jnR+weL9rihJFrL2GwacZFsBI0YrxptSoOtPDfyLJ 3jzdlRCAUSwtp28xWmMpcNW6midCSfTpts0JJlsPXLzw63Il24gEJmg5W4nT5EKP8sjy Rnew==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=YqZj1cZW; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::536 as permitted sender) smtp.mailfrom=eth3rs@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com. [2607:f8b0:4864:20::536]) by gmr-mx.google.com with ESMTPS id 41be03b00d2f7-c70b720c1c4si314666a12.5.2026.02.23.13.43.26 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Feb 2026 13:43:26 -0800 (PST) Received-SPF: pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::536 as permitted sender) client-ip=2607:f8b0:4864:20::536; Received: by mail-pg1-x536.google.com with SMTP id 41be03b00d2f7-c6e266a3572so1614340a12.0 for ; Mon, 23 Feb 2026 13:43:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771883006; cv=none; d=google.com; s=arc-20240605; b=PVX/zc48eT4tykDmJB2QHh1yBJshm3UGQCHTM/Xr4h8McMoFRWiqkm6npjdpeaycbi Ud6snIti6foIkAaZHyrCa6mN4Hr+RC+mL0cpoqFV1JowhaVccFMWsyNQ3URhrVgUoukJ BrtOeav9csiUHaietlmD3zq3iwMZMzFQeVeeuCuXBwM/wN+dYSQShm/fhOFVxHQJ5cxV SleIQROu+mtujJOf+05wNhgVpgiLWwHMlrml0ARKO6+RgxbljaL0Knz1RAyCAn3/SiJq cgIiUgxrjqarMRPZjGmVwoaYdv6U7eIvZtIA/Wf7Be+Vjg/Bhnahi3Txjr9+RQ0MYKyY suvQ== 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=iHdvVV6ZS486eVEqrg/4PntzQQ2ovYjA/iX5rZ5mIC4=; fh=b4hteE3ppcqEvxdtR7+0ORGsFt2Be6SKqAVC7pct0/M=; b=Jn2uzNWa11M1FoBZpetwzpGWwEaqMlD8C0yRG5Iz2AfNBESIs8otk5T2phvXnAQBdR 6PPMpQKaBIcC4gbn/KYz4VBNO09NcAeQsqBMoSVXrQN6nT7mHvyqA1zhBsTExCf8H4/5 ThXNtxtVDUk/7P3NWKf5GClLgbAygJ+VKe7q3Kec8ZA4XJAFnk2OLTSZpOWcy1jOcsm2 3gCHEZxexiWzTovYcP2sZ+OOdTdEmFQkAGSowAy2qqEXh1L1BcY7/LCHHW3+/y1y7fCP 5JhMFSj+HHBfOj5/0wsRgxP2IrLRXt3jutIcTBmZi7n3zjet0qpeTVtcZ/BFNsdQg1Hl 1CQg==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Forwarded-Encrypted: i=1; AJvYcCUio1ggv9sMzqeRmolLkmBxLCoerEMBFfCVNSYp91bdCT+PkruYW012yfQUNrNC/A4LOEW5oWe2TDYo@googlegroups.com X-Gm-Gg: ATEYQzymhuwcWlV5pIS7Gms+lZJc8Iume5QdXM8JIH3xMklzUsza19p/+i1HlUDJJz+ 1kHhX6LBkL4qk8pldq+p84ZRxdSpIg32GOyVGorKqIcSdEj9FmtEeOiA+u3FNWJJrYj9tK58SKV 5mpwCGxITdZkVr6u16vqi8M3MrYBOWEDkmoaFhRS6hC0hCtJkKzPUmJmdnlt29HpyeK0Cf0wtvk D7E8y4294Yp7sB97SoQox29t7/WYh3amiqrZfz+55Ck/FGBosdHtbHysJf1f5YUHiSVdKKTjm5G Ys09fRgHK3oIS8uiuAzLfGajZnvQD8KFGwyOcz7IWXIhbcaaxqDD4Y8sGcWQjHcD7CL0mUU/71o SdaAzdi5MojfPRPD+1X/zDyT4V7Nz/IyzauHTz2AyovFg3nGWon0kUv8XNIjaZdL9tE4ETkSoGb KDMlfjU2co60DVvlBEZV/84G2iX7wLI2HhVdAXIlN64ugqptHB+8JU3Nf5sg5H6aKAF2b9nyHGI uWxJHo= X-Received: by 2002:a17:90b:2e0f:b0:32e:3829:a71c with SMTP id 98e67ed59e1d1-358ae8b23damr9514859a91.16.1771883006363; Mon, 23 Feb 2026 13:43:26 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ethan Heilman Date: Mon, 23 Feb 2026 16:42:50 -0500 X-Gm-Features: AaiRm5040YTqbf-O7qGxKIcbUGSH2zrCKn4An9Dc8xdIxkWMqsJlFugSkmHTxTw 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: Erik Aronesty Cc: conduition , "garlonicon@gmail.com" , Jonas Nick , bitcoindev@googlegroups.com Content-Type: multipart/alternative; boundary="0000000000002d8cba064b84a9ab" X-Original-Sender: eth3rs@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=YqZj1cZW; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::536 as permitted sender) smtp.mailfrom=eth3rs@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=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.5 (/) --0000000000002d8cba064b84a9ab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 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. SPHINCS is ~8kb (7,888 bytes) not 17kb. SPHINCS SLH-DSA-128s has 32 byte public keys and 7,856 byte signatures Total size of 7,888 bytes not 17kb. The Lattice sigs aren't that much better than SPHINCS CRYSTALS-Dilithium ML-DSA has 1,312 byte public keys and 2,420 byte signatures Total size of 3,732 bytes. Falcon has 897 byte public keys and 666 signatures 1,563 bytes ML-DSA currently has the most support in the Lattice world, but it is still too large to be a drop in replacement for ECC without a witness discount. If we had to choose tomorrow, I'd advocate for ML-DSA with a massive witness discount, but I'd be very unhappy with the witness discount. If the witness discount was out of the question, then I'd advocate for something similar to 324-byte stateful hash based SHRINCS signature. Neither is ideal= . My current thinking is to use SLH-DSA as a backup. This keeps us safe if everything goes wrong and allows us to reach safety early so we can take time to determine the right drop-in replacement for ECC. Hopefully in 3 years, SQI-sign is fast enough to be considered. On Mon, Feb 23, 2026 at 2:08=E2=80=AFPM 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 read= y > yet. > --=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/= CAEM%3Dy%2BWAR3YXmdrrT-zN210ob53dmYC1KZwBZ%3DOK2bKgNeAHUg%40mail.gmail.com. --0000000000002d8cba064b84a9ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0 I thought "tweaking", in general, is lost in SPHINCS, as well as = multiparty sigs.=C2=A0 Be interested to see those solutions.=C2=A0 =C2=A0Bu= t, regardless, 17kb sigs are... not compatible with a decentralized bitcoin= , imo.=C2=A0 =C2=A0Lattice-sigs are the only reasonable PQ way forward and = they aren't ready yet.

SPHINCS is ~8kb (7,888 bytes) not 17kb.
SPHINCS SLH-DSA-128s has 32 byte public keys and=C2=A07,856 byte sign= atures
Total size of 7,888 bytes not 17kb.

The Lattice sigs aren&= #39;t that much better than=C2=A0 SPHINCS=20

CRYSTALS-Dilithium ML-DSA has 1,312 byte public keys and 2,420 byte= signatures
Total size of 3,732 bytes.

Falcon has 897 byte public keys and 666 signatures
1,563 bytes
ML-DSA currently has the most support in the Lattice world, but it is= still too large to be a drop in replacement for ECC without a witness disc= ount. If we had to choose tomorrow, I'd advocate for ML-DSA with a mass= ive witness discount, but I'd be very unhappy with the witness discount= . If the witness discount was out of the question, then I'd advocate fo= r something similar to 324-byte stateful hash based SHRINCS signature. Neit= her is ideal.

My current thinking is to use SLH-DSA as a backup. Thi= s keeps us safe if everything goes wrong and allows us to reach safety earl= y so we can take time to determine the right drop-in replacement for ECC. H= opefully in 3 years, SQI-sign is fast enough to be considered.

On Mon, Feb 23, 2026 at 2:08=E2=80=AFPM 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 viability of your linked= protocol? I'm not questioning its quantum-resistance properties (yet).= I'm wondering how it is possible to instantiate this scheme in a way t= hat allows a wallet to actually use this commit/reveal scheme without knowi= ng the final destination CTV templates (denoted T & E in the delving po= st) in advance of creating the phase 0 locking script.

I provided an example script that shows how it wor= ks:=C2=A0https://gist.github.com/earonesty/ea086aa995= be1a860af093f93bd45bf2. you don't pin to the final destination in p= hase 0.

txhash is a partial-commitment, not over all fields.=C2=A0 t= his=C2=A0give the flexibility needed for the final spend, since you don'= ;t commit to it.=C2=A0 =C2=A0

however someone has pointed out a fee-= problem that CCV's value-aware composability can solve.=C2=A0 =C2=A0com= ing around to thinking the ccv-based construction would be necessary.=C2=A0= =C2=A0CCV is more powerful but requires much more care in policy and analy= sis.=C2=A0 CTV is trivial, we could merge it tomorrow and hardly worry abou= t surface area issues.=C2=A0 =C2=A0TXHASH is only slightly more complicated= .=C2=A0 CCV has a much bigger burden of proof around implementation and nod= e safety... but i think you could do many kinds of vaulting schemes with it= alone.


But in the case of hash-based signature (HBS) scheme= s, i disagree. HBS is already mature. Whatever cryptanalytic breakthroughs = the future holds, we can be reasonably sure that SHA256 preimage resistance= will hold for a long time, so HBS security will hold. Even today md4 and m= d5 preimage resistance still holds. Securing coins using hashes alone is th= e ideal fallback, and even if HBS is not the most efficient class of scheme= s, that doesn't matter so much if we don't use HBS as our primary e= veryday signature scheme. Its value lies in security, not efficiency.
=

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

1.=C2=A0Earlier versions of the SPHINCS framework were found to be suscept= ible to=C2=A0fault attacks
2.= Earlier "Tight" proof for v1 SPHINCS was flawed, leading to 60 b= its of security, not 128

> If you're worried about stu= ff 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.=C2=A0 Be interested to see those solutions.=C2= =A0 =C2=A0But, regardless, 17kb sigs are... not compatible with a decentral= ized bitcoin, imo.=C2=A0 =C2=A0Lattice-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 &= 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/CAEM%3Dy%2BWAR3YXmdrrT-zN210ob53dmYC1KZwBZ%3DOK2bKgNeA= HUg%40mail.gmail.com.
--0000000000002d8cba064b84a9ab--