From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 13 Jun 2026 09:04:29 -0700 Received: from mail-qt1-f192.google.com ([209.85.160.192]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wYQqR-0002tw-8B for bitcoindev@gnusha.org; Sat, 13 Jun 2026 09:04:29 -0700 Received: by mail-qt1-f192.google.com with SMTP id d75a77b69052e-517787172b0sf5227711cf.0 for ; Sat, 13 Jun 2026 09:04:27 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1781366657; cv=pass; d=google.com; s=arc-20240605; b=j/XCPaGf8bNKm9/hnRJO4tq0gDwfDBiTzVysk8YsDZXNHamY8iY8nNKdDrkrH84tEj /hnrLbGj3KXUh/O6AMi9NkQ5O1rccYLKuPIiwyNzkoK4zKCc68g/DHNKKqpj9Vh4PF6f SEICVhDSTY8rmtz0r/2uvgFn4IFYFPRtJ/PZZ1frbB3w79l+KyzghjwbQPRbAH2a6I+q qYaasRYXrkgcRAB7E/PJSTLbSLPA5UHktJb5BwBq3juu6GPU2nQPx6NTap+8uy4RkeCW +wFtp9JWDZcKFPqvAK1SQ/fgIvWBRDxcrdnNUiBMqkA01HXVMcCZ3Ajg+8ef/UHB368U H1tw== 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=SlQFQmwo7QxGvh1gcHPSficIfAqwG3PbWGdsq12AP/4=; fh=ZV54MdbhwDosezjfKuhpQJwQ0SAf7qp1e0ntpiwnbeM=; b=bddlDURwZQfvrxqjVNknlmFMCQrRjTfxAylHyfeXV0tQaJ/0W4fTk1tJXmBJmyhOs/ GXGA++jHNqaDgkk9UeARRUlYq63rnkgjRhOZ0yUyiVROJmFky2yv6hDcxmI9hKwjZS6/ nuQN7rOvrzMwg1legqlUGeQRqPHZjeTcoioXJmOdAJ9T197C4TLMut1Hj2nkxsZR5Ku3 eS6dRno14ogiGdqJA31NdAtZz5ouNJw20U185G8F3bTHJK4ivk26Tb4pvXVXgZpGk1am NL7214X94CqSvHzfGZyp4hxG9UZIlCFvqA3+rZqP0bp/61oBTaQKyYzA71wARtiW1EsD PQqQ==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=APNQZ98Y; arc=pass (i=1); spf=pass (google.com: domain of patrickcerri@gmail.com designates 2607:f8b0:4864:20::92c 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=1781366657; x=1781971457; 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=SlQFQmwo7QxGvh1gcHPSficIfAqwG3PbWGdsq12AP/4=; b=XYsT4LQjMJm84wYQIjefAebuWhUhEilaHB9zKK6cekGkF209566jHJdFQPnZqCWmXr 9dNDjw7GRiRsVBRDdX3hvV77Qte38hN1DKsmjv21FoGN74f8zqhxdAG7PvVdOuHhWJI5 S0P64wFDwTFkUSSCBO8DbXstP6SSf8nZhq0E9YEc6/oPUFXqQzXB/waWAAS4Zkkz2VTe 9NWLa1uL/SD5P0kbKgudLYglBcSLHUa9jdR/pqoxxFaMSjlJvMce9lzCv3B51uZfRBnq nWz0V+5SbBbSN/NguAUFpwBE4GLklZLXoG0skVH0T+8ynTIqoT0QoJbPyrXN9X9chMax 20pA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781366657; x=1781971457; 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=SlQFQmwo7QxGvh1gcHPSficIfAqwG3PbWGdsq12AP/4=; b=NSxX1ZixxSk0iW5XUBL+SUQb1XM8MPV4PN7TeAHZa28pshMHPsdNnP6YB1nGV2w8vh H2ziwNdoUA8Kfm/gzgVG4Pgrt463fKHxD04zX8OI50hf83QBURoLawKFuOtIdOZHGmQ8 qbCca+BgJmWci1R+KIlaPl3a2jO2yogfIUoRu5w5Ip9H7FvjJjxgljgRBZdTfjsvMnYu vhgL8QVvNE8eMrGe/JR8NXve6G23jF2uuEOD82Fh5LQAhhEoueytcm9lYrxO5l13RC6P vdnkYAbTPbMmKHqktn6y1GxFoHZQjYIgkDo+/CE7diDBeKcy/0bB7MISfDbqLpSn/cL7 REAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781366657; x=1781971457; 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=SlQFQmwo7QxGvh1gcHPSficIfAqwG3PbWGdsq12AP/4=; b=KDDQ5NIrAn5vkVHZPO9rgsS3hn3pJOuK+aOdCj+czqFmbjab/cWVsf/bZs2JRQWrZx fSGh018kBo8SlMVDlqAZpgIUF8nMWYYjt9ZnGgV+nzSDJ9fMcjVIFaYfK90vESW05l6E B8jFZ82mTIbMiY9XH+0hSV+NIuhUwW/T9RpZaVyk/WJC+sPDsALKz8vNSYCJuDFJd/WJ 4JF94xZ/lY/hQwOeeR0FkX8ufarTnbPzG+O2kZL9iFcQfcccbelHAZWYpFPR0PuKucMK 9lmGB+cgLRy4BBzc/hlj2PKL8v4KimLWkjhPze4FztlJ6jbE1QrvEObnbdJ/omEhSdon p1yw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AFNElJ/GsdUeelTAgwODBgPHIag8x7Q28r6OZ3rH1HNlFyUA4mR9iCWA1JnCJ1DXknM8IhyHU57lpsC8amaC@gnusha.org X-Gm-Message-State: AOJu0YyZ0cjcFxazlRPrgqygPEAp6CpgoCnOW1zhLBc15iANezNnn1T3 cze8XlVlgfOlPE+1BAf1G+xshlpp8eXE8VB2+M/VDJC+p6aL8IC7FCN9 X-Received: by 2002:a05:622a:a90b:b0:50d:3eac:8466 with SMTP id d75a77b69052e-517fe4fba36mr91580011cf.30.1781366657254; Sat, 13 Jun 2026 09:04:17 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUdOzlpESAtz++DbpZbkeZKAT+doRKsZiLU79v2M73WLhQ==" Received: by 2002:ac8:5d4c:0:b0:509:760:59b3 with SMTP id d75a77b69052e-517f9a88199ls50957461cf.0.-pod-prod-07-us; Sat, 13 Jun 2026 09:04:13 -0700 (PDT) X-Received: by 2002:a05:620a:7106:b0:914:c61f:c699 with SMTP id af79cd13be357-9161baeb35dmr1080785785a.13.1781366652912; Sat, 13 Jun 2026 09:04:12 -0700 (PDT) Received: by 2002:a05:620a:a0d:b0:8cd:90d4:fad8 with SMTP id af79cd13be357-915e5e4d774ms85a; Wed, 10 Jun 2026 01:59:09 -0700 (PDT) X-Received: by 2002:a05:6102:a47:b0:631:ff40:22b5 with SMTP id ada2fe7eead31-6ff09f95299mr14295806137.21.1781081948610; Wed, 10 Jun 2026 01:59:08 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1781081948; cv=pass; d=google.com; s=arc-20240605; b=DkVwZgUjd5JKog1Ch99zmBsTPpQjmup6mBcZB68IMQ8TkMtAh0oyN+gnqTpkFBnQq/ GGprYNzzo2/ZNffViScFVM11LYFi1EF1gnu0a6rp1AwsYesyiTpUVcUu9Ojtts33CDFz 1KDwMRVk7CCweisFUkugDj2tKHQRpHfUxxlg0MZJwB5MYWxcXHQ6a965/FS/UF7m8ue0 0yXjaZQhvHktEqjGV9qPCLcfIqZ/ysc/t4Yl5cjZ+a68jmwRMO4zBdE+7GgIpjE3FY/c F0Fh5cwftJr5gYCYlrUF5Sh4FtKEegiqqr7JYIsRsGfEerJKJcw81XYORypX5aCa2Xas F6eQ== 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=RzuogD8ZuW7Es0wi/HwFcunhiXZ+NryUFFR1juCwQ20=; fh=mzXEsTWDK6gnkBrY7ZCwwMohUIL8bXkfU2CQ462oZJ0=; b=j2zO0OtrWTBnzQUcUeVY6NhzuASjRUEdDFaO245VTtcJhOdLoArkFy76yzccww99tn BRbkH+tKxUB0dH7gD4I6mpA9eZ3prsww90SHuGhuKjJ3Zeq4Eee4sVMlr7punOgcMgaI cfUyEaoT3vNETV7a3hWS/VWZ46WSXuDMaDDrG8+geizdqNnY6VkgVbhXIRdlPK1/cPYC nPs67x3+E38DgUgozLQduEwotMH2IpePjWSbKSdaSkhBZrxl4ad3ha+7wqZyKIYzMVC+ PfQk+1lHf5M2Z6sgck3qy2HmGP2IuowfTqk9vDv+1ovAFYqefwhaRK79UEnogzcU/lmm mzGA==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=APNQZ98Y; arc=pass (i=1); spf=pass (google.com: domain of patrickcerri@gmail.com designates 2607:f8b0:4864:20::92c 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-ua1-x92c.google.com (mail-ua1-x92c.google.com. [2607:f8b0:4864:20::92c]) by gmr-mx.google.com with ESMTPS id ada2fe7eead31-6eb6863fe9esi809689137.4.2026.06.10.01.59.08 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 Jun 2026 01:59:08 -0700 (PDT) Received-SPF: pass (google.com: domain of patrickcerri@gmail.com designates 2607:f8b0:4864:20::92c as permitted sender) client-ip=2607:f8b0:4864:20::92c; Received: by mail-ua1-x92c.google.com with SMTP id a1e0cc1a2514c-9639130b20fso4044613241.3 for ; Wed, 10 Jun 2026 01:59:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781081948; cv=none; d=google.com; s=arc-20240605; b=GQOYipMEwEbFaoR5SuQW6ujs7EwW1gj33o061zzWyvHenTkVelKYbj2PmcF2VWzNRy g/txFabPs7fdORDPgmvbi3HE8guYk+SJTpHcFIh71vZuztJGva4yFtStoEKfpnXqf7Vt c8E3iW1qBCPSNDQPi/7CbQcd72ad5oTQW9hYoLPHMEdkyVyK8sjkcwDivmFr1YOoPKqT RPvvFWHrbZT0qRNmfdKtic5D93QpYzagks9u1Zgw1HYGUh4QntZGvFmGM+WpNH7eklXV XhXIfkdJp1lwbc4s5d117QpJAkJvU4cas9wAObDT4/0o7ePg0TImghuooaHg8Lo62eMG WRYw== 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=RzuogD8ZuW7Es0wi/HwFcunhiXZ+NryUFFR1juCwQ20=; fh=mzXEsTWDK6gnkBrY7ZCwwMohUIL8bXkfU2CQ462oZJ0=; b=ab6j8vKLvb23s4eSX59UynBZLcmBC0vM1dQyT9b1by7IAehuAURoevoaQ+Rz5JiP3r LPdW4KtzAc+xAtOv5YmJuXw8auyfm3grqCX1oTaSfSJUbGhdydFcDzIyi7Q0FzjSoHco ni6DKkG4jihnf52ks7OFzucLExva+/0DQwb3iT0RxryjPbiLpaaHE1Zn3RKQ7jgcMH8f Rx56kc76y3AIU1B8ezjyllrg4uwxPKg1blF2PQthuvxLB4/bA9ivJ0/UsrFcRxaSVToH I7ya9GcvJF5ow5zaxnT+krRrJPlfJgUu2SiwuHIt8ivTkHlvIWLw/QYc0IYZR2qjl46k nJ9Q==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: Acq92OE3nN8fcdNS5mgLcMbmjJkveClKNepZ60pBgVHgy/YNg5GrpxBPFNstEXqEsTj lC/gpn+dZd2LfqAP/vvyMQR2QUqV+r+DFWzl05UlfyV88edWe4JMeQY6n1YldVjtlcbSCL7/nsH woIwRHhWpu8+80v/z86zdwifW+agCoQVxaAnZSIM7iXR9wnipUp3c/FiO7HuSpObpVNjmdqSN2J ZXZyWecCVXR7Ym8lN8qmFypJ8nBE4ORdS0JlLwzDOFoB3sV73FMXlNHRMyztG+pNHJ4lCJnEUeL pTNBfkTX+qUz3yDIxw== X-Received: by 2002:a05:6102:442c:b0:633:34c6:6ace with SMTP id ada2fe7eead31-6ff0c144eb8mr12597358137.26.1781081948082; Wed, 10 Jun 2026 01:59:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Patrick Cerri Date: Wed, 10 Jun 2026 09:58:56 +0100 X-Gm-Features: AVVi8CctxksAvt7ZEQz9oCLH5ob67BviLiUuI9QUf7h7QCpnGPfxpKNTwUhowd0 Message-ID: Subject: Re: [bitcoindev] A look at SHRINCS To: conduition Cc: bitcoindev@googlegroups.com Content-Type: multipart/alternative; boundary="000000000000d4d7a00653e274aa" 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=APNQZ98Y; arc=pass (i=1); spf=pass (google.com: domain of patrickcerri@gmail.com designates 2607:f8b0:4864:20::92c 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 (/) --000000000000d4d7a00653e274aa Content-Type: text/plain; charset="UTF-8" Yo. WRT to | Keeping state is not trivial. This is MUCH harder for Users than I expected. In our system Users can obviously restart/reset their node and at that point a seed-phrase is required. We also ask them to provide a KEY_USES value for how many slots they have used. The 'KEY USES' value can easily be obtained from their original node but this has proved a sticking point. We are a mobile first blockchain so phones play a big part of our system. - The node is lost/wiped and they do not know what their key uses was when they lost their node. In "best case" a User should know this value after every transaction - AND REMEMBER / STORE IT - so that they are ready should their node be lost to them. This is asking A LOT. The main issue imho. - Even Users who have simply wiped their node through choice did not think to check that final value before starting up a fresh node - and cannot retrieve it after the fact. - Some Users use multiple devices - with the same seed - and these do not synchronise so slots overlap. Although I did see there was some talk of creating separate tree paths for separate devices which may help. All though then you would need to keep track of more than 1 number, 1 for each device - even harder. - Normal / non-techie Users (through no fault of their own - smart people just not technical ) simply do not comprehend what this is and confuse it for how many times they want to use their address. - Even though we have tried to explain this as fully and comprehensively as we can, this information has just not percolated through the ecosystem as we would have liked. Some really have no idea that it is required at all and are just confused when we ask them for the value on resync. Like I said - people _expect_ their seed to be enough. We tried to change it so we ask them 'How many times have you resynced ?'.. and whatever number they give we just multiply by 10,000 but this is also not great as - again - they need to remember how many times they have done this. You'd think it was easy but we have seen people get even this wrong. It is possible to tell from the merkle branch in the signature which key is being used - so we can tell when it happens. And some do not realise how important this is and always say this is their first time to reduce information leakage - incorrectly thinking we are harvesting information or something. Some have used an address MORE than 10,000 times.. this especially applies to Exchanges or more business oriented accounts that send a lot of transactions from a single address. It's a crude approximation that has pros and cons. Certainly not infallible. As for our current implementation of SPHINCS.. this was done in house with the scraps of information we managed to extract from the 'inter-web' - SPHINCS is really quite a simple and elegant system. No optimisation and no hardware support so am pleased to see you have a solution to the resource issues I raised. Yes - on a phone our pure java version takes 20-30 seconds to build a key and sign.. but that is probably the slowest it will ever be! The verification at least is still fast. This may be something to think about though as anyone else trying to create an implementation may also create a working-but-much-slower version than the nice, clean, optimised this-is-how-to-do-it-correctly version. On Tue, 9 Jun 2026 at 18:38, conduition wrote: > 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 > signing path to handle alternative 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 constant-size signatures with higher > stateful signing budgets. We don't want to force signers who *can* keep > track of state to use the stateless path and waste blockspace unnecessarily. > > Our current working design (unpublished) uses 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 distinguishing (i.e. a > signature from a balanced depth 8 XMSS tree is indistinguishable from the > 8th signature of an unbalanced tree). > > As for multi-tree support, that is still uncertain. 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, and 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 personally suspect it'd be better > implemented as an entirely separate scheme from SHRINCS. > > For now we're still writing 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 knowledge of how this plays out in a live > environment. > > First - keeping the state is non-trivial. This is MUCH harder for Users > than 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? > > If possible, would you be able to share the docs/specs/standards that you > worked 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 > 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. > > > - 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 > performance tolerances. Given the fact you referenced HORS in your message, > are you using the legacy first version of SPHINCS > ? > - RAM usage can be reduced to almost nothing with streaming > techniques. > - 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 milliseconds 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 > implementation which > goes pretty fast too. > - The big performance pain point for SPHINCS is hardware wallets and > other 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 > 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. > > > We considered the option of implementing different SHRINCS sub-components > as distinct opcodes/schemes in script. We decided not to, because of how > challenging it would be to implement secure multisignature scripts. You'd > have to handle the combinatorial explosion that occurs if different signers > 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 the > client-side if they need to. Scripts should be kept clean and any new > signature scheme 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 < > patrickcerri@gmail.com> wrote: > > 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 > . > > > -- 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%2BUi4Ku0CDBguOgnv_n4KJXrnLrAtRNHOmZsYfuawDyNmw%40mail.gmail.com. --000000000000d4d7a00653e274aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yo.

WRT to

| Keeping state is not trivial. T= his is MUCH harder for Users than I expected.

In our system Users ca= n obviously restart/reset their node and at that point a seed-phrase is req= uired. We also ask them to provide a KEY_USES value for how many slots they= have used.

The 'KEY USES' value can easily be obtained from= their original node but this has proved a sticking point. We are a mobile = first blockchain so phones play a big part of our system.

- The node= is lost/wiped and they do not know what their key uses was when they lost = their node. In "best case" a User should know this value after ev= ery transaction - AND REMEMBER / STORE IT - so that they are ready should t= heir node be lost to them. This is asking A LOT. The main issue imho.
- = Even Users who have simply wiped their node through choice did not think to= check that final value before starting up a fresh node - and cannot retrie= ve it after the fact.
- Some Users use multiple devices - with the same = seed - and these do not synchronise so slots overlap. Although I did see th= ere was some talk of creating separate tree paths for separate devices whic= h may help. All though then you would need to keep track of more than 1 num= ber, 1 for each device - even harder.
- Normal / non-techie Users (throu= gh no fault of their own - smart people just not technical ) simply do not = comprehend what this is and confuse it for how many times they want to use = their address.
- Even though we have tried to explain this as fully and = comprehensively as we can, this information has just not percolated through= the ecosystem as we would have liked. Some really have no idea that it is = required at all and are just confused when we ask them for the value on res= ync. Like I said - people _expect_ their seed to be enough.

We tried= to change it so we ask=C2=A0them 'How many times have you resynced ?&#= 39;.. and whatever number they give we just multiply by 10,000 but this is = also not great as - again - they need to remember how many times they have = done this. You'd think it was easy but we have seen people get even thi= s wrong. It is possible to tell from the merkle branch in the signature whi= ch key is being used - so we can tell when it happens. And some do not real= ise how important this is and always say this is their first time to reduce= information leakage - incorrectly thinking we are harvesting information o= r something.

Some have used an address MORE than 10,000 times.. thi= s especially applies to Exchanges or more business oriented accounts that s= end a lot of transactions from a single address. It's a crude approxima= tion that has pros and cons. Certainly not infallible.

As for our cu= rrent implementation of SPHINCS.. this was done in house with the scraps of= information we managed to extract from the 'inter-web' - SPHINCS i= s really quite a simple and elegant system. No optimisation and no hardware= support so am pleased to see you have a solution to the resource issues I = raised. Yes - on a phone our pure java version takes 20-30 seconds to build= a key and sign.. but that is probably the slowest it will ever be! The ver= ification at least is still fast. This may be something to think about thou= gh as anyone else trying to create an implementation may also create a work= ing-but-much-slower version than the nice, clean, optimised this-is-how-to-= do-it-correctly version.

On Tue, 9 Jun 2026 at 18:38, = conduition <conduition@proton.me= > wrote:
=
Hi spartacusrex, thanks for raising this point.=C2=A0

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 g= ive signers any flexibility in the stateful signing path to handle alternat= ive 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 som= e use-cases, that ought to be available. Some use cases would prefer consta= nt-size signatures with higher stateful signing budgets. We don't want = to force signers who can=C2=A0keep track of state to use the statele= ss path and waste blockspace unnecessarily.

Our cu= rrent working design (unpublished) uses a flexible XMSS structure where sig= ners can choose to use a balanced or an unbalanced XMSS tree structure in t= heir stateful signing path, with the consensus-verifier being flexible enou= gh to accept either format without distinguishing (i.e. a signature from a = balanced depth 8 XMSS tree is indistinguishable from the 8th signature of a= n unbalanced tree).

As for multi-tree support, tha= t is still uncertain. The main use-case for multi-tree XMSS would be lightn= ing - nobody else ever needs to sign so much that they'd need multiple = stateful trees, and if they do they can use the stateless path. We're s= till too early in the design process to say for sure if multi-tree is neces= sary, but I personally suspect it'd be better implemented as an entirel= y separate scheme from SHRINCS.

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

I designed, wrote and work on a blockchain that implemen= ts WOTS sigs as standard so have some real-world knowledge of how this play= s out in a live environment.

= First - keeping the state is non-trivial. This is MUCH harder for Use= rs than 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 oth= er issues you've run into deploying stateful signatures in the wild?=C2= =A0

If possible, would y= ou be able to share the docs/specs/standards that you worked on?

- Creating SPHINCS sigs is a lot more resour= ce 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 c= reate. Verification is still fast - just checking some merkle branches and = WOTS sigs.

=
Sounds like you might have some places to opt= imize.=C2=A0


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 u= sing (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 s= ingle OP_ would be cleaner/faster.
=
We considered the option of implementing differ= ent SHRINCS sub-components as distinct opcodes/schemes in script. We decide= d not to, because of how challenging it would be to implement secure multis= ignature scripts. You'd have to handle the combinatorial explosion that= occurs if different signers want to use different signing paths in the sam= e witness. It's better if we have one unified standardized scheme which= signers can customize on the client-side if they need to. Scripts should b= e kept clean and any new signature scheme should be compartmentalized.

Regarding the opcode for mer= kle branch checking... Maybe have a look at the OP_PAIRCOMMIT pro= posal.

regards,
conduition
On Tuesday, June 9th, 2026 at 5:35 AM, Patrick Cerri <patrickcerri@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 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 hav= e tree-of-tree keys (XMSS). This is what we do. This gives _potentially_ mi= llions of signatures from a single address at the cost of signature size. H= ow 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 potentia= l sigs > signature size.

The only thing a verifier needs to be ab= le 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 si= gnatures. Still much larger than BTC sigs but manageable.

I do like = the SPHINCS+ tree path SHRINCS uses to allow either system to be used.
<= br>Problems :

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

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

If th= e proposed changes assume that any reset of your node would then require yo= u to use SPHINCS+ to sweep remaining coins and send them to a new address t= his 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 transa= ctions may cost a lot - especially given the size of a SPHINCS sig.
- Yo= u 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 mo= re resource intensive than WOTS.
- RAM usage is 100x more ( not soo bad= )
- SPHINCS sigs are BIG. ~20kb. Bigger than a regular WOTS sig and MU= CH bigger than regular BTC sigs .
- Real issue is that on a phone the SP= HINCS sig can take 20-30 seconds to create. Verification is still fast - ju= st 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 con= struction of your tree of keys.

What you need is :

- An OP_ f= or general Merkle branch checking. You need to use a HASH-SUM tree for SPHI= NCS.. so you can tell which HORS set you are using (technical point).
- = An OP_ for WOTS check
..
- An OP_ for SPHINCS checking - which you _c= ould_ actually create in script using the first 2 ops but a single OP_ woul= d be cleaner/faster.

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

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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAOWv0%2= BUx1AiLbUagF8eWsmvMQ-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/CAOWv0%2BUi4Ku0CDBguOgnv_n4KJXrnLrAtRNHOmZsYfuawDyNmw%40ma= il.gmail.com.
--000000000000d4d7a00653e274aa--