From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 09 Jun 2026 02:35:47 -0700 Received: from mail-oa1-f59.google.com ([209.85.160.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wWss6-0002d6-Bn for bitcoindev@gnusha.org; Tue, 09 Jun 2026 02:35:47 -0700 Received: by mail-oa1-f59.google.com with SMTP id 586e51a60fabf-43ccd5d5357sf6338101fac.0 for ; Tue, 09 Jun 2026 02:35:45 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1780997740; cv=pass; d=google.com; s=arc-20240605; b=BxZC+vNaX160X8CnBqNOT0TQUF5m5JjqYen3tNNuwLBfVZfTN3q33By87j2wBXQdAG hL0dDlcjjrHX7SRmm+IvqWYbwtWKzNWaYt1as0Fef/7S0oPItmVDiaoXQtC+Vx95Bg+B HrecEHEjYfcOzbYZuQsIXuOKwSNPx3EDb2AEsa2yiXY6Iml+qy7vJs2PdyY/u51BakId e3A6uwBu9e0EHij4c9U15OH+Lo4a935Aonmrav7XAXyzpNJxqDCy61EtAnNh202fA73M +fntubffs56fYETf8GnktqF1VRktoaEekdhU2eUAn4S8D+glXJ+2TniKpFVs/yakyJLi vZEQ== 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:to:subject:message-id:date:from :mime-version:sender:dkim-signature:dkim-signature; bh=vkdI0RqdNkIqND1ZMciHIm+5DDFkyol/k4qqXXgSVn8=; fh=xipF/8Y7lBGpa6PMrL3hn6Wya0UEGfI6D04xZpKuHQw=; b=jEGRmXuarWVNEHd+ris0NUNszyuI1cgwGKp8yP2wQTwqYvwsHKuEu+1ngvp6uqytHZ qXr/sJzPrjPzND8YaWbkjH9K0DjTCtPaRVsih+EefUCVaweBa7l7G3IdKLqvD/mZOTjI zQNPIBjqn9Vr4Nf4GOmEubqY3kQo0yqy5qTVZxbwxqTjf7wrRYczjkfSGQZk8JCNMdyj xcwKKWNFAuq5zln6OPGN+NjNjSHkcCtca+MDEjrcwRpU3zciGPDL3DJ+IQSU2I+b35Wd 5RLtiwe65KntwpxWsEegmHUqXPYh5t1cKNr21caWmhZ1i97654Rn0v2Tspzgd9DTYPBB KvWw==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=bddXj7qL; arc=pass (i=1); spf=pass (google.com: domain of patrickcerri@gmail.com designates 2607:f8b0:4864:20::a29 as permitted sender) smtp.mailfrom=patrickcerri@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=20251104; t=1780997740; x=1781602540; 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=vkdI0RqdNkIqND1ZMciHIm+5DDFkyol/k4qqXXgSVn8=; b=hTBbZ23j9rVUZuwaGYBBivagmbI9Cm8m2PAaF+OVpmkC9pvBnjFcauqeTImhtWLMpI OM8mxCNBu+e9g32NeKf8veM7hlaNS6WhhMakaVuK2hktdAM+S04YaM2gpAn2mvTJexRs HEmZ2D7rNSvvUpGc3BBP7HeUkfeoHXgQIzCrKcXOwIpXNz97h43diFb24flWVTlf6TeW nouz8LDY8aU8lq6YsL2LAKRLd/KNpf08ZMnYnq6qIAShfJIW6oX86+vq3c2HW3KeEqnZ R9qAwmR3k+mcxgAa0Lyflrxlj1brAMLYDK/9spQb2Euzx1doflkQ5BPwn2rCGL1TS55q tSfA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780997740; x=1781602540; 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:from :to:cc:subject:date:message-id:reply-to; bh=vkdI0RqdNkIqND1ZMciHIm+5DDFkyol/k4qqXXgSVn8=; b=ZJfqF9ZlhAzPrOqzYvQJmF3a4IEptv362GUZyciuKKzJFXJR5JduqxU4n6XEhHqeNw CNKttnRVtaQLgvPyhPsaYDlcLKowJ94Xhh7Z8xi++8OaUWTG/1sYGPYJVArVdFsmwE7F Sx5qQdfB9+K1qu0430UP+sQRVVqvBI+Z0quipqRn5tXAIR1vSwvTl7RkkCtrWNeY6MOH 9VdXl5M5dPwiG6B02aKNHEI6V19/t9E1iOq7lMAJy5CAEkCr9oI9/fWeQ/3kWZJxSA4h q498ngFapOq70V4tHUpCF/S82D8MA11eyOxEuLAK0wSkWUCyrP1djcw8fvXtkJlbDV3M 6wjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780997740; x=1781602540; 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=vkdI0RqdNkIqND1ZMciHIm+5DDFkyol/k4qqXXgSVn8=; b=UVVMVT1J70bWZKpA13FhemhLP1uZVz52MOgPzghcZfO8RqaNFVcr+hBVuO/qGMWEv6 Q3MwlDs+8KKt4WEcMf1XPW7Bxsjps593Rr0jo/Nof7svoa4GuQ4HfdiJ9UVZqMdYHxBJ cL0mBJWqnk/4DqxhuN9ehfP8MvSdAL712opPFefzlHAvFJhDtsco0cZ7SGCsbM+AZvLi f51fNyVVUEBWOv3kPmcHIwCTZX2g288Nr7M8lvqCVvNFknSDkqAyuQNnnpE7fTWnJ+dU msi+BPgBiB3PQAdNibPgrJkQgY+cXODLjBNgmi++7UDP8VzzbGLbloBr9WcMaL3jPJkr Sd1w== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AFNElJ+WIScSjeFK0k7LTpR5KBCPc3UcZZXArUAJRyey2Zc3mwAVz2oHHU0/cy1rHpd2CoYVBpHgFur2lCRA@gnusha.org X-Gm-Message-State: AOJu0YwFLADQac6D5yv2A9mUY5EQnE+TVQ4XdpcfM5x4f1M+fCn4nSFg SEuJg+DKqh0VNF23DWf5yxjWC5/EZT13Kw1nn0pt2L3Y7iy0eD+0CBTZ X-Received: by 2002:a05:6871:e40b:b0:43d:3251:7070 with SMTP id 586e51a60fabf-4413d854f2dmr11387058fac.25.1780997739780; Tue, 09 Jun 2026 02:35:39 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUfrgQXiLEcPQP5OW+R3nSSaanatR7VXCa39BQtFXaiywA==" Received: by 2002:a05:6871:e683:b0:430:279e:462b with SMTP id 586e51a60fabf-4410921ebdcls2127301fac.0.-pod-prod-06-us; Tue, 09 Jun 2026 02:35:35 -0700 (PDT) X-Received: by 2002:a05:6808:152b:b0:486:5479:c1c6 with SMTP id 5614622812f47-4868de1bd84mr11027546b6e.31.1780997734975; Tue, 09 Jun 2026 02:35:34 -0700 (PDT) Received: by 2002:a05:690c:c1e:b0:7ba:f5aa:4ab8 with SMTP id 00721157ae682-7ed27751347ms7b3; Tue, 9 Jun 2026 02:02:45 -0700 (PDT) X-Received: by 2002:a53:d016:0:b0:660:7b47:24cc with SMTP id 956f58d0204a3-66106eefe0fmr15651734d50.1.1780995764761; Tue, 09 Jun 2026 02:02:44 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1780995764; cv=pass; d=google.com; s=arc-20240605; b=ifveqk/lmg6bo00HZJh7+NWd068qWQSgsGyVVAcoEbfbKvhb5DRMZnspS+KdeO+vZ+ 1ENikJ9M4HHO9Uez2lMXZhmrhp02e3wICc1LXntOxvd5u2tkB5fkJVWKCbnVTrID0pCN xhPZZQ5335T7NDnfBqszncb1sAOjVSsI6/HPJFRaJYbk6px1iU/wd3NsgAtmq4B3fwYy Lojgb9d7dvHpdiBVTF7ItbEvuEvsuyA1hXvn0s86ea2YbTiJaGlux3gbWlILNL/TJLXX /WSh8QYGjZcoLGf0vr4Exjma24nSSQuV9kj5lV6z25F879GPuB8aZsXdEQKG4c7PDG5G nZZw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=LgLD6tI+jSO0hjuhlKgj0uF1hmR0TGGRBOC7xzxp5Jg=; fh=VcGcg+Zjs9gw1uDcHbxsAILhBAcecnbJzZRdxgKVDIc=; b=iFjuDe/levZm/bmFjYXuZWwqRmSOKpHKyPiCdrBT72TolV+8vl7T1EwUwv7AKsS2W7 zT49YkUe2ZqJvDWbjZ9THyAHx+qTL5kOnjcB7CyH/2kH3jSDv61rHIu06x/exJvOniKm gJM51EVYJNHCmVsfNmLrSyEh+GKT5OlerfqBz8FR9ve6OMbwLn6LmUwh4qMo6mS+s3VX tTQH1dLfPXOgoiKAr9ZTYjc84ij4E0i5AI3MLHweV6DvFrCaPNJnv5A4rrAd1YxhoWkD A7UCRtQCYvOL9DMfan5lq0zQxvhmm+dUEL36sui/ItnhaC5woPCULnPRfLqDBqF+QTjB NJHA==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=bddXj7qL; arc=pass (i=1); spf=pass (google.com: domain of patrickcerri@gmail.com designates 2607:f8b0:4864:20::a29 as permitted sender) smtp.mailfrom=patrickcerri@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-vk1-xa29.google.com (mail-vk1-xa29.google.com. [2607:f8b0:4864:20::a29]) by gmr-mx.google.com with ESMTPS id 956f58d0204a3-660d5d1e532si647588d50.0.2026.06.09.02.02.44 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Jun 2026 02:02:44 -0700 (PDT) Received-SPF: pass (google.com: domain of patrickcerri@gmail.com designates 2607:f8b0:4864:20::a29 as permitted sender) client-ip=2607:f8b0:4864:20::a29; Received: by mail-vk1-xa29.google.com with SMTP id 71dfb90a1353d-59cfbfe64baso1769702e0c.2 for ; Tue, 09 Jun 2026 02:02:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780995764; cv=none; d=google.com; s=arc-20240605; b=dDfArMvg6dVnXbs8UtjJullcbq4NNs3Yq4p2txxjb+mvyWvOEueQFZzi3emzMzPkUt 8mq4SlbMCc1Bb6ep6XtyDAAu7D8C+C5UYPqsuJWOkQPxpAoUeXbLFTZuKfUpvnECVjP1 W7Djexop2vDZHehHahgj4hGINh5phk88B6WLvuIhi6h55RvfVw9PJLfG4WE/50sP2VLl LIKZpwsHLSIEbo1bDzRVTlDhsxURsnuytujPmZsjKe01tbflxwhyN1IpmFrLYt8cO1LD t7a8bRy5USyI1Sk4Sjf4lPqdP3f+VFwfzgJisPcnF6HyeFahPRKVaPU8CZzLJCLazFUB uEsw== 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=LgLD6tI+jSO0hjuhlKgj0uF1hmR0TGGRBOC7xzxp5Jg=; fh=VcGcg+Zjs9gw1uDcHbxsAILhBAcecnbJzZRdxgKVDIc=; b=U3i/nZFumz87Q38Q3MEAbu/PMTfWSnkvjmOFJ3BFfacZknaU7DiTkBVY95RMXUNitT BLc6OD00/d57nMU70ZvcyPeA8YnVynqWe1VEiWecGH4in7TOh8b832ohHQRdXHpdSUYn 6bVHKYrmf2Gm5F51w/BtMzr54KvRx5I0+Zp6MkZHMHTKMDPuN1eE0eovAPCv2Bra9uO6 kbHiVYTL2KZgWQ1Bo/b4pzoFBBZALJSEyoWxviebNkCYt9O0jAi6NhoFIdBBmC/A25rv d6P6ljvyZ8RpQCAF5V3J5iM537aB28AAAPkzTVCH0u6rcX1udg52M2OI16aa6dV32pmJ e2+w==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: Acq92OHewm3SNu+a8cQybeiILoPgGKXYEO36hE7KdjdOa3nPf/JmC4RIpeQHiSahDou FuvauLVCnmPM3w4rvuDqKhgqsm72HAAU3VkfzNalrVIvqV9EnurS1p0Y7da/S83bgZrqwvHY65a Mg5jfHBOwimk3pxGwWMk2l9R4b3tGngbIlcOHNbPGCoAHNNdPon/IxTA6xy1IIZF/WvIoZDsWAt p7+wHgvYrJwrELKITnNDdbcgyS5B3uUjzUWYst14gftKiwvNFlCJT2Hu2dF7o3ezR0GqtOhkbd9 XFZJ8FcXMwSKVXMLNdesFuMIuF80 X-Received: by 2002:a05:6122:3c46:b0:5a0:1bcb:acd1 with SMTP id 71dfb90a1353d-5ac4ee912efmr9072572e0c.5.1780995764130; Tue, 09 Jun 2026 02:02:44 -0700 (PDT) MIME-Version: 1.0 From: Patrick Cerri Date: Tue, 9 Jun 2026 10:02:33 +0100 X-Gm-Features: AVVi8CdYbCAMZIuDMqXoR_rvSg0zbWZe6FmgakRjWsjkvjqvhFQK0EvvkSmJIig Message-ID: Subject: [bitcoindev] A look at SHRINCS To: bitcoindev@googlegroups.com Content-Type: multipart/alternative; boundary="000000000000de2a8e0653ce63ab" X-Original-Sender: patrickcerri@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=bddXj7qL; arc=pass (i=1); spf=pass (google.com: domain of patrickcerri@gmail.com designates 2607:f8b0:4864:20::a29 as permitted sender) smtp.mailfrom=patrickcerri@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 (/) --000000000000de2a8e0653ce63ab Content-Type: text/plain; charset="UTF-8" Good Day, I would like to chip in. 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 level 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-of-tree keys (XMSS). This is what we do. This gives _potentially_ millions 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 potential sigs > 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 sizes. 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 SPHINCS+ tree path SHRINCS uses to allow either system to be used. Problems : 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 changes 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 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 carefully hidden BIP39 seeds are useless and need to be remade. If you choose to just use SPHINCS .. 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 base WOTS scheme. - 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 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. I do think a system like SHRINCS is the way to go but with some lee-way to choose the exact construction of your tree of keys. What you need is : - An OP_ for general Merkle 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 create in script using the first 2 ops but a single OP_ would be cleaner/faster. 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 email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAOWv0%2BUx1AiLbUagF8eWsmvMQ-xvu438WsOJ%2Br0MzsqbHWerOQ%40mail.gmail.com. --000000000000de2a8e0653ce63ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Good Day,

I would like to chip in.

I designe= d, 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 level e= very 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 tre= e you can sign the root of another tree with a leaf key and have tree-of-tr= ee keys (XMSS). This is what we do. This gives _potentially_ millions of si= gnatures from a single address at the cost of signature size. How big the t= ree-of-trees is, how deep in trees and how many leaf nodes per tree, does n= ot need to be hard coded and can be user defined. More potential sigs > = 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 sizes.<= br>
With basic parameters you can create a WOTS-Tree sig in anywhere fro= m 2-4k ( less if you use 128bit hash ) and have > 100,000 signatures. St= ill much larger than BTC sigs but manageable.

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

Problems = :

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

The idea that you can reset your nod= e 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 stumblin= g block. Key slot reuse and ergo insecure keys happens.

If the propo= sed changes assume that any reset of your node would then require you to us= e SPHINCS+ to sweep remaining coins and send them to a new address this wou= ld work.. but that in and of itself is not great.

- You lose your o= ld 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 carefully hidden= BIP39 seeds are useless and need to be remade.

If you choose to jus= t use SPHINCS .. this also has issues.

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

- Creating SPHINCS sigs is a lot more reso= urce intensive than WOTS.
- RAM usage is 100x more ( not soo bad )
= - SPHINCS sigs are BIG. ~20kb. Bigger than a regular WOTS sig and MUCH bigg= er than regular BTC sigs .
- Real issue is that on a phone the SPHINCS s= ig can take 20-30 seconds to create. Verification is still fast - just chec= king some merkle branches and WOTS sigs.

I do think a system like SH= RINCS is the way to go but with some lee-way to choose the exact constructi= on of your tree of keys.

What you need is :

- An OP_ for gene= ral Merkle branch checking. You need to use a HASH-SUM tree for SPHINCS.. s= o you can tell which HORS set you are using (technical point).
- An OP_ = for WOTS check
..
- An OP_ for SPHINCS checking - which you _could_ a= ctually create in script using the first 2 ops but a single OP_ would be cl= eaner/faster.

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

Regards,
spartacusrex

--
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/CAOWv0%2BUx1AiLbUagF8eWsmvMQ-xvu438WsOJ%2Br0MzsqbHWerOQ%= 40mail.gmail.com.
--000000000000de2a8e0653ce63ab--