From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 09 Jun 2026 11:39:43 -0700 Received: from mail-oa1-f63.google.com ([209.85.160.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wX1MU-0007BY-0n for bitcoindev@gnusha.org; Tue, 09 Jun 2026 11:39:43 -0700 Received: by mail-oa1-f63.google.com with SMTP id 586e51a60fabf-43d133d9796sf4014759fac.0 for ; Tue, 09 Jun 2026 11:39:41 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1781030376; cv=pass; d=google.com; s=arc-20240605; b=Y78kAmmPeM8ZOnyYMR6CIlJlp4A1zJNESOSZBF1K2HiE8EP42PFAOwFosl0CLoQN80 Q09mXDt6KmggUrVRXU64tpFq8Xp8Klf5dH1qUDYM5KnxEzy+OGrbB7lOAPZBd4rBEUcm 0su/3Pt2ZNdBrRNXmjZPkHBT8F/REeKQBTwUJLMAl49THLA57kwKzHUl/Yne95kAWCiV aDd4fyva2z7U3sjKCyODw3+6XVH1uGVVrvnL8iPaC7bae+Vw8Ab4e7rqdGDgD7gUU1W2 ygLPDfAX1t+nioZCiEAHXjNFfemsL4xkxysWorIyPWN0YANl6D+odCRiVkvK8Ewk3XH4 Z8xQ== 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:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=M32aN7/oVQwu0p8krp3NDnz2IlvbMrxjf1PFZ077DLM=; fh=KaqR41EW3D19E6MMF2n0XVc7+QLsKUXBL5C/fiueAxM=; b=LQjXJR3P2XdimBiH08mACFIpfUPyeMQJbMsvoUAKj9i+ON/KTb3NBi2ncAPhQYQh9W yE7QdD/XYpFBTWJrLi0qd5ESR3cwS074Vrh1oQsccBw32Ujuu5M3F+NlOUhC0EQ37ufI YH6b7A/JXEHU+K+53chk1illvJKkHn4zcq0p7ZFC0D+Z7sJNQsdon/sMR8FhsqeuSk1f QJ+kKoLZJgfrlVWdXJmr4azuL5iJrdM4A7jcRL9fE0UKpckZ06qc7+WtxpRAylSkpyN2 FXFrktW9IKvcvRufdNOe5dxQ38inZC2uWToSVpMZOWszKrL1+5J9KvNQTKOVc7GqBiYw umuw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=pdxvuzmetjdpvfzat2dqidao44.protonmail header.b=VJBOLpBh; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.25 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1781030376; x=1781635176; 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:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=M32aN7/oVQwu0p8krp3NDnz2IlvbMrxjf1PFZ077DLM=; b=ECggdw8Y87HpPZXhpdSRKAl15sZPEUoCcHOQzbPUMR49b0WkPhLAhjAs27iwIRtZUX wdNIjziEaJMbnu1lNjOoSn0oypBzsGsw6MpivsnL1MD6SXCF0JxhCqaDV0mtxVXswSLz xG7WfzV9MC5XnHz5XCIDC5WHVMSn5sYBEC43oy0O5GU2/oOKloEr3YYnMu75UehRlik1 Qr0sWpDGWcifk3Y8jfnBX0FajZI74BMSejo8DNwVz7dqmGfFFYNW83Oy0hfALddJPCYV zn+C12pzvFqOiZbSNxWUjbF3ROAivwsXWSgfhJXPGqZsrY8jw9P1D7E2k+LB0xwOmMnw WeCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781030376; x=1781635176; 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:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=M32aN7/oVQwu0p8krp3NDnz2IlvbMrxjf1PFZ077DLM=; b=YHobIOMtFaZp1WMe1UJxh7jZ+P7jDyxPAdOh8n0zDuJfKJHraVYqYGMyERfu3yPqni +OY+MJqUIdm7NX5oYEO99PtKyzyImd9F5xjtN0KuP+vhP+r9+B9f09NSGV/KRCWIYbLv B16nMJopVCBvmt20xTzu/Rl++iFZY/VOtBeWkiCSrnEMVj7gTVDjfe05Z27h/sWUsxBC FKXBCQXk8SNPuTwbzGHoENBaFPQIRGSLgJW04IP0BS0OazEEWMJx3sSfFtYBCmj1QiBU 6Eht3LJbOhOUzzN8OSBkVIxbwKrn+AcGuF2fmttw1DZMR4jZLlBCENyifBzrnr1n3IBc GWvg== X-Forwarded-Encrypted: i=2; AFNElJ+0ZDStHMGDtFG9AkH/1RTigQw4P+mgSZyxPO4o0mVNM08UBM+WGwQ9HfsP4JC0ZG3zC+crbQxx5Y8+@gnusha.org X-Gm-Message-State: AOJu0YwYWdap8F3V87WTVjTrq14kBBz9AAVD9hZG9gkPcYs63fQkw9G/ LL8w4JpS2r8HTkEtzQdahjKr7q08G9LfrTokqrLA8+zMw8ML/SaR8PA1 X-Received: by 2002:a05:6871:ea08:b0:43a:2607:e610 with SMTP id 586e51a60fabf-4413dc38061mr11515633fac.25.1781030375645; Tue, 09 Jun 2026 11:39:35 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUf0k7+GLr5blYCnCTfPtsi1y+rbuD8cpysB9YkFEIor9g==" Received: by 2002:a05:6870:e60b:b0:441:4757:d51e with SMTP id 586e51a60fabf-44147581107ls2299036fac.0.-pod-prod-02-us; Tue, 09 Jun 2026 11:39:31 -0700 (PDT) X-Received: by 2002:a05:6808:118d:b0:486:89d8:6d57 with SMTP id 5614622812f47-4868db1f053mr13036524b6e.8.1781030371781; Tue, 09 Jun 2026 11:39:31 -0700 (PDT) Received: by 2002:a05:6402:406:b0:670:416a:5ab4 with SMTP id 4fb4d7f45d1cf-692917f36c9msa12; Tue, 9 Jun 2026 10:38:53 -0700 (PDT) X-Received: by 2002:a17:907:9812:b0:bec:18d5:ddec with SMTP id a640c23a62f3a-bf37311392cmr1046882066b.41.1781026731325; Tue, 09 Jun 2026 10:38:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781026731; cv=none; d=google.com; s=arc-20240605; b=eH5uyrHpHB2ua0bAuC8S6avNAEO/GIIluENQAalLnbqQvapVTv37zzJ0A/+Y9s5Qp7 u1iZRKYBPJsWa+kOuFiM5ACNM9Jx1/YaNSlg6fDZBM9gsThjE8Oneme0txBqDZfhq9++ K/WennLhTzO4+lqUEiyFDtIoUAYtDaLrcxO9xMfLic25omcgk6L5eu9gRqk59cpEjEZE RZORELvDMgdHjcpCGu1q1laE8OXTZSl6Gy1x15DcgNA8qjOg/2g9QvllcZg97LVPmslv N1+tYBUNCUMsE7Olw23ZqnUyWCQm/C6mET1cwTdi/fUFca6f8526H1G0Lwt56zqkwARd IrXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=rBzKOiSAixDuFhjJhaAx3ATLsiTRQ+hrtL7sfCt5/sE=; fh=Ay4HlRJuxal9koIWeivLse1RGgWoZfU6sSIMmLQhD5Y=; b=fcSVhXZO/psvP9W/yA3SyOS+2hN9OeXXoC/h6SPMOH25u4R+JJAbpIi71lPZKGw64u p+ZwQSJpFKQL6gH04+tlay+gVOYuzSnYsdKrTbmaZKoaV529zZ4Ey7eRX6xSylNyc3jg G+rRFiQwxE09yAovOJE19EXGB57FVm25e/nuwlN7oM9fcIl+TTy3ZyhGe3QHunvA3YoL EGPuI3Ydo1Tw69kWyxnSAXIqIKGzD79bdakSraouZ9jvEpzrWrXkjWYA2VlK4lBb217+ ftRg1uwto9RPOAPHcL3jfTKLs2bewD28M3Oe8TANaA07CBasDCuEwPyTSVuOD5J/uXWK QBiA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=pdxvuzmetjdpvfzat2dqidao44.protonmail header.b=VJBOLpBh; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.25 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-4325.protonmail.ch (mail-4325.protonmail.ch. [185.70.43.25]) by gmr-mx.google.com with ESMTPS id a640c23a62f3a-bf05460dfd9si41103166b.2.2026.06.09.10.38.51 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Jun 2026 10:38:51 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 185.70.43.25 as permitted sender) client-ip=185.70.43.25; Date: Tue, 09 Jun 2026 17:38:45 +0000 To: Patrick Cerri From: "'conduition' via Bitcoin Development Mailing List" Cc: bitcoindev@googlegroups.com Subject: Re: [bitcoindev] A look at SHRINCS Message-ID: In-Reply-To: References: Feedback-ID: 72003692:user:proton X-Pm-Message-ID: edba6c06596bc0aed8bdbc809e36b012eb9d072c MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------8f1e68045cc56235042d15e34e535a8d02832660b74b50851ea277de6d0ee5c4"; charset=utf-8 X-Original-Sender: conduition@proton.me X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=pdxvuzmetjdpvfzat2dqidao44.protonmail header.b=VJBOLpBh; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.25 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me X-Original-From: conduition Reply-To: conduition 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: -1.0 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------8f1e68045cc56235042d15e34e535a8d02832660b74b50851ea277de6d0ee5c4 Content-Type: multipart/mixed;boundary=---------------------c715be9da62d1cfa191f08b938231864 -----------------------c715be9da62d1cfa191f08b938231864 Content-Type: multipart/alternative;boundary=---------------------7cabeec84e2abec343364c8081345c5f -----------------------7cabeec84e2abec343364c8081345c5f Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi spartacusrex, thanks for raising this point.=C2=A0 The current published version of SHRINCS (described here) is not the versio= n which we'll end up proposing for Bitcoin. As you point out, SHRINCS v1 do= esn't give signers any flexibility in the stateful signing path to handle a= lternative use-cases. Since I started working with the blockstream folks, I= think we've all come to agree this is a potentially important feature for = some use-cases, that ought to be available. Some use cases would prefer con= stant-size signatures with higher stateful signing budgets. We don't want t= o force signers who can=C2=A0keep track of state to use the stateless path = and waste blockspace unnecessarily. Our current working design (unpublished) uses a flexible XMSS structure whe= re signers can choose to use a balanced or an unbalanced XMSS tree structur= e in their stateful signing path, with the consensus-verifier being flexibl= e enough to accept either format without distinguishing (i.e. a signature f= rom a balanced depth 8 XMSS tree is indistinguishable from the 8th signatur= e of an unbalanced tree). As for multi-tree support, that is still uncertain. The main use-case for m= ulti-tree XMSS would be lightning - nobody else ever needs to sign so much = that they'd need multiple stateful trees, and if they do they can use the s= tateless path. We're still too early in the design process to say for sure = if multi-tree is necessary, but I personally suspect it'd be better impleme= nted as an entirely separate scheme from SHRINCS. For now we're still writing the spec and putting in the work to make sure i= t's secure, but stay tuned for updates. We'll publish the new & improved SH= RINCS scheme here and on DelvingBitcoin when it's ready for public review := ) > I designed, wrote and work on a blockchain that implements WOTS sigs as s= tandard so have some real-world knowledge of how this plays out in a live e= nvironment. >=20 > First - keeping the state is non-trivial. This is MUCH harder for Users t= han I expected. I'd love to hear more about your experience with this. You mentioned wallet= restoration as the main pain point, but are there any other issues you've = run into deploying stateful signatures in the wild?=C2=A0 If possible, would you be able to share the docs/specs/standards that you w= orked on? > - Creating SPHINCS sigs is a lot more resource intensive than WOTS.- RAM = usage is 100x more ( not soo bad ) > - SPHINCS sigs are BIG. ~20kb. Bigger than a regular WOTS sig and MUCH bi= gger than regular BTC sigs . > - Real issue is that on a phone the SPHINCS sig can take 20-30 seconds to= create. Verification is still fast - just checking some merkle branches an= d WOTS sigs. Sounds like you might have some places to optimize.=C2=A0 - SPHINCS+ signatures with a 128-bit security level can be as small as 3-= 5 kilobytes if you adjust parameter sets properly for your security and per= formance tolerances. Given the fact you referenced HORS in your message, ar= e you using the legacy first version of SPHINCS? =20 - RAM usage can be reduced to almost nothing with streaming techniques.= =C2=A0 - Signing should definitely not take 20-30 seconds. My SLH-DSA-SHA2-128s = implementation can make an SLH-DSA-SHA2-128s signature in 10 to 12 millisec= onds on my desktop CPU, or a bit slower on a mobile CPU. With a GPU you can= go even faster. Scott Fluhrer also has this awesome multithreading+AVX imp= lementation which goes pretty fast too. - The big performance pain point for SPHINCS is hardware wallets and othe= r embedded systems. The current gen of hardware takes 60s+ to sign with SLH= -DSA-SHA2-128s; longer if using a secure-element like Ledger. But there are= still ways to optimize even that use case. > What you need is : > - An OP_ for general Merkle branch checking. You need to use a HASH-SUM t= ree for SPHINCS.. so you can tell which HORS set you are using (technical p= oint). > - An OP_ for WOTS check > .. > - An OP_ for SPHINCS checking - which you _could_ actually create in scri= pt using the first 2 ops but a single OP_ would be cleaner/faster. We considered the option of implementing different SHRINCS sub-components a= s distinct opcodes/schemes in script. We decided not to, because of how cha= llenging it would be to implement secure multisignature scripts. You'd have= to handle the combinatorial explosion that occurs if different signers wan= t to use different signing paths in the same witness. It's better if we hav= e one unified standardized scheme which signers can customize on the client= -side if they need to. Scripts should be kept clean and any new signature s= cheme should be compartmentalized. Regarding the opcode for merkle branch checking... Maybe have a look at the= OP_PAIRCOMMIT proposal. regards, conduition On Tuesday, June 9th, 2026 at 5:35 AM, Patrick Cerri wrote: > Good Day, >=20 > I would like to chip in. >=20 > I designed, wrote and work on a blockchain that implements WOTS sigs as s= tandard so have some real-world knowledge of how this plays out in a live e= nvironment. >=20 > 'SHRINCS' uses a ladder of WOTS keys that grows one level every time you = use it. I think a tree of keys works better. This way you can have a set am= ount of slots/keys at a constant sig size. >=20 > Using a tree you can sign the root of another tree with a leaf key and ha= ve tree-of-tree keys (XMSS). This is what we do. This gives _potentially_ m= illions of signatures from a single address at the cost of signature size. = How big the tree-of-trees is, how deep in trees and how many leaf nodes per= tree, does not need to be hard coded and can be user defined. More potenti= al sigs > signature size. >=20 > The only thing a verifier needs to be able to do is check a merkle branch= and a WOTS sig. This covers all possible tree sizes. >=20 > With basic parameters you can create a WOTS-Tree sig in anywhere from 2-4= k ( less if you use 128bit hash ) and have > 100,000 signatures. Still much= larger than BTC sigs but manageable. >=20 > I do like the SPHINCS+ tree path SHRINCS uses to allow either system to b= e used. >=20 > Problems : >=20 > First - keeping the state is non-trivial. This is MUCH harder for Users t= han I expected. >=20 > The idea that you can reset your node JUST from a seed is deeply embedded= .. asking Users to keep track of even a single digit - the number of 'slots= ' used - has proved a stumbling block. Key slot reuse and ergo insecure key= s happens. >=20 > If the proposed changes assume that any reset of your node would then req= uire you to use SPHINCS+ to sweep remaining coins and send them to a new ad= dress this would work.. but that in and of itself is not great. >=20 > - You lose your old addresses. > - You may have a lot of coins and the sweep transactions may cost a lot -= especially given the size of a SPHINCS sig. > - You need a NEW phrase.. all your cold wallets are no good. All your car= efully hidden BIP39 seeds are useless and need to be remade. >=20 > If you choose to just use SPHINCS .. this also has issues. >=20 > We have implemented a SPHINCS+ scheme that runs in the base txn scripting= .. so you can use that instead of the base WOTS scheme. >=20 > - Creating SPHINCS sigs is a lot more resource intensive than WOTS. > - RAM usage is 100x more ( not soo bad ) > - SPHINCS sigs are BIG. ~20kb. Bigger than a regular WOTS sig and MUCH bi= gger than regular BTC sigs . > - Real issue is that on a phone the SPHINCS sig can take 20-30 seconds to= create. Verification is still fast - just checking some merkle branches an= d WOTS sigs. >=20 > I do think a system like SHRINCS is the way to go but with some lee-way t= o choose the exact construction of your tree of keys. >=20 > What you need is : >=20 > - An OP_ for general Merkle branch checking. You need to use a HASH-SUM t= ree for SPHINCS.. so you can tell which HORS set you are using (technical p= oint). > - An OP_ for WOTS check > .. > - An OP_ for SPHINCS checking - which you _could_ actually create in scri= pt using the first 2 ops but a single OP_ would be cleaner/faster. >=20 > Then you have the freedom to create a SHRINCS style keys with variable pa= rameters that allow signature size to be sacrificed for greater potential k= ey uses. >=20 > Regards, > spartacusrex >=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= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/CAOWv0%2BUx1AiLbUagF8eWsmvMQ-xvu438WsOJ%2Br0MzsqbHWerOQ%40mail.gmail.com. --=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/= nLUFIVQQskgzQynb7yquUh6S6IQQ_QQQ3_Yakhgfg2BoEkj3VFQxw3vUwvEDs4vKTO_wajVy9tD= BFIPgMyaumOviGWOaJ35XFn8nkrsx7jI%3D%40proton.me. -----------------------7cabeec84e2abec343364c8081345c5f Content-Type: multipart/related;boundary=---------------------3b4721fe2b8b91ff1ad2e8846df2a123 -----------------------3b4721fe2b8b91ff1ad2e8846df2a123 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi spartacusrex, thanks for raising this point. 
=

The current published version of = SHRINCS (described here)= is not the version which we'll end up proposing for Bitcoin. As you point = out, SHRINCS v1 doesn't give signers any flexibility in the stateful signin= g path to handle alternative use-cases. Since I started working with the bl= ockstream folks, I think we've all come to agree this is a potentially impo= rtant feature for some use-cases, that ought to be available. Some use case= s would prefer constant-size signatures with higher stateful signing budget= s. We don't want to force signers who can keep track of state t= o use the stateless path and waste blockspace unnecessarily.

Our current working design (unpublished) u= ses a flexible XMSS structure where signers can choose to use a balanced or= an unbalanced XMSS tree structure in their stateful signing path, with the= consensus-verifier being flexible enough to accept either format without d= istinguishing (i.e. a signature from a balanced depth 8 XMSS tree is indist= inguishable from the 8th signature of an unbalanced tree).

As for multi-tree support, that is still un= certain. The main use-case for multi-tree XMSS would be lightning - nobody = else ever needs to sign so much that they'd need multiple stateful trees, a= nd if they do they can use the stateless path. We're still too early in the= design process to say for sure if multi-tree is necessary, but I personall= y suspect it'd be better implemented as an entirely separate scheme from SH= RINCS.

For now we're still w= riting the spec and putting in the work to make sure it's secure, but stay = tuned for updates. We'll publish the new & improved SHRINCS scheme here= and on DelvingBitcoin when it's ready for public review :)

I designed, wrote and work on a= blockchain that implements WOTS sigs as standard so have some real-world k= nowledge of how this plays out in a live environment.

= First - keeping the state is non-trivial. This is MUCH harder for Users tha= n I expected.

I'd love to hear more about your experience wi= th this. You mentioned wallet restoration as the main pain point, but are t= here any other issues you've run into deploying stateful signatures in the = wild? 

If possible, would you be able to share the docs/specs/standard= s that you worked on?

- Creating SPHINCS sigs is a lot more resou= rce intensive than WOTS.
- RAM usage is 100x more ( not so= o bad )
- SPHINCS sigs are BIG. ~20kb. Bigger than a= regular WOTS sig and MUCH bigger than regular BTC sigs .
- Real issue is that on a phone the SPHINCS sig can take 20-30 seconds to = create. Verification is still fast - just checking some merkle branches and= WOTS sigs.

Sounds like you might = have some places to optimize. 

What you need is :

= - An OP_ for general Merkle branch checking. You need to use a HASH-SUM tre= e for SPHINCS.. so you can tell which HORS set you are using (technical poi= nt).
- An OP_ for WOTS check
= ..
- An OP_ for SPHINCS checking - which you _could_= actually create in script using the first 2 ops but a single OP_ would be = cleaner/faster.

We considered the option of implementing different SHRINCS sub-com= ponents as distinct opcodes/schemes in script. We decided not to, because o= f how challenging it would be to implement secure multisignature scripts. Y= ou'd have to handle the combinatorial explosion that occurs if different si= gners want to use different signing paths in the same witness. It's better = if we have one unified standardized scheme which signers can customize on t= he client-side if they need to. Scripts should be kept clean and any new si= gnature scheme should be compartmentalized.

Regarding the opcode for merkle branch checking... Mayb= e have a look at the OP_PAIRCOMMIT proposal.

regards,
conduiti= on
On Tuesday, June 9th, 2026 at 5:35 AM, Patrick Cerri <patric= kcerri@gmail.com> wrote:
Good Day,

I would like to chip in.
<= br>I designed, wrote and work on a blockchain that implements WOTS sigs as = standard so have some real-world knowledge of how this plays out in a live = environment.

'SHRINCS' uses a ladder of WOTS keys that grows one lev= el every time you use it. I think a tree of keys works better. This way you= can have a set amount of slots/keys at a constant sig size.

Using a= tree you can sign the root of another tree with a leaf key and have tree-o= f-tree keys (XMSS). This is what we do. This gives _potentially_ millions o= f signatures from a single address at the cost of signature size. How big t= he tree-of-trees is, how deep in trees and how many leaf nodes per tree, do= es not need to be hard coded and can be user defined. More potential sigs &= gt; signature size.

The only thing a verifier needs to be able to do= is check a merkle branch and a WOTS sig. This covers all possible tree siz= es.

With basic parameters you can create a WOTS-Tree sig in anywhere= from 2-4k ( less if you use 128bit hash ) and have > 100,000 signatures= . Still much larger than BTC sigs but manageable.

I do like the SPHI= NCS+ tree path SHRINCS uses to allow either system to be used.

Probl= ems :

First - keeping the state is non-trivial. This is MUCH harder= for Users than I expected.

The idea that you can reset your node= JUST from a seed is deeply embedded.. asking Users to keep track of even a= single digit - the number of 'slots' used - has proved a stumbling block. = Key slot reuse and ergo insecure keys happens.

If the proposed chang= es assume that any reset of your node would then require you to use SPHINCS= + to sweep remaining coins and send them to a new address this would work..= but that in and of itself is not great.

- You lose your old addres= ses.
- You may have a lot of coins and the sweep transactions may cost = a lot - especially given the size of a SPHINCS sig.
- You need a NEW phr= ase.. all your cold wallets are no good. All your carefully hidden BIP39 se= eds are useless and need to be remade.

If you choose to just use SPH= INCS .. this also has issues.

We have implemented a SPHINCS+ scheme= that runs in the base txn scripting.. so you can use that instead of the b= ase WOTS scheme.

- Creating SPHINCS sigs is a lot more resource inte= nsive than WOTS.
- RAM usage is 100x more ( not soo bad )
- SPHINCS= sigs are BIG. ~20kb. Bigger than a regular WOTS sig and MUCH bigger than r= egular BTC sigs .
- Real issue is that on a phone the SPHINCS sig can ta= ke 20-30 seconds to create. Verification is still fast - just checking some= merkle branches and WOTS sigs.

I do think a system like SHRINCS is = the way to go but with some lee-way to choose the exact construction of you= r tree of keys.

What you need is :

- An OP_ for general Merkl= e branch checking. You need to use a HASH-SUM tree for SPHINCS.. so you can= tell which HORS set you are using (technical point).
- An OP_ for WOTS = check
..
- An OP_ for SPHINCS checking - which you _could_ actually c= reate in script using the first 2 ops but a single OP_ would be cleaner/fas= ter.

Then you have the freedom to create a SHRINCS style keys with = variable parameters that allow signature size to be sacrificed for greater = potential key uses.

Regards,
spartacusrex

--
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+u= nsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAOWv0= %2BUx1AiLbUagF8eWsmvMQ-xvu438WsOJ%2Br0MzsqbHWerOQ%40mail.gmail.com.

--
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/nLUFIV= QQskgzQynb7yquUh6S6IQQ_QQQ3_Yakhgfg2BoEkj3VFQxw3vUwvEDs4vKTO_wajVy9tDBFIPgM= yaumOviGWOaJ35XFn8nkrsx7jI%3D%40proton.me.
-----------------------3b4721fe2b8b91ff1ad2e8846df2a123-- -----------------------7cabeec84e2abec343364c8081345c5f-- -----------------------c715be9da62d1cfa191f08b938231864 Content-Type: application/pgp-keys; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWkRub0tSWUpLd1lCQkFI YVJ3OEJBUWRBcnBZYWFjZDgwcXdocmNaQW9VbW9NSHNWS21iZWlPZUEKcFhXbk1ybFdPZkxOSzJO dmJtUjFhWFJwYjI1QWNISnZkRzl1TG0xbElEeGpiMjVrZFdsMGFXOXVRSEJ5CmIzUnZiaTV0WlQ3 Q2pBUVFGZ29BUGdXQ1pEbm9LUVFMQ1FjSUNaQjRLV3p0aFBhenhRTVZDQW9FRmdBQwpBUUlaQVFL YkF3SWVBUlloQkVkSWthMENNdHJMZGcxM2EzZ3BiTzJFOXJQRkFBQTZhQUVBM1RmNHdqSVoKYnox K0diS0h4K09WQytNUXlVdi84RStoWUpjTE5QZnA0NEFBLzNiak5OTXN4WHdJTGZEM0xManNVVWFo CitBV2JyblVjVUFqQ2R1d3hUT01LempnRVpEbm9LUklLS3dZQkJBR1hWUUVGQVFFSFFDSXYxZW5J MU5MbAo3Zm55RzlVWk1wQ3ZsdG5vc0JrTmhQUVZxT3BXL3RKSkF3RUlCOEo0QkJnV0NBQXFCWUpr T2VncENaQjQKS1d6dGhQYXp4UUtiREJZaEJFZElrYTBDTXRyTGRnMTNhM2dwYk8yRTlyUEZBQUFR TFFEL2NCR2kwUDdwCkZTTkl2N1B6OVpkeUNVQjhzTy90dWZkV3NjQkNZK2ZMYTV3QkFNK0hTL3Jp S014RGt0TkhLakRGc2EvUgpEVDFxUGNBYXZCaXc2dDZ4Ti9jRgo9Y3d5eAotLS0tLUVORCBQR1Ag UFVCTElDIEtFWSBCTE9DSy0tLS0tCg== -----------------------c715be9da62d1cfa191f08b938231864-- --------8f1e68045cc56235042d15e34e535a8d02832660b74b50851ea277de6d0ee5c4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmooT5cJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmfMX1j967DhBo9QT3nDdl3zGrlkq1cnmjukYTpk uIJm5xYhBEdIka0CMtrLdg13a3gpbO2E9rPFAADUqAD9HRWSEWBUUVl8REuZ IecyhXhRGvuu02eNtG+Psginq/cA/2Xdfw+oX8317qOlQO/PqthB7TlmfvL1 22yvJ2p5mGQE =KyJK -----END PGP SIGNATURE----- --------8f1e68045cc56235042d15e34e535a8d02832660b74b50851ea277de6d0ee5c4--