From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 13 Jun 2026 09:04:30 -0700 Received: from mail-qt1-f186.google.com ([209.85.160.186]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wYQqQ-0002tu-UJ for bitcoindev@gnusha.org; Sat, 13 Jun 2026 09:04:30 -0700 Received: by mail-qt1-f186.google.com with SMTP id d75a77b69052e-5174a236220sf37260011cf.3 for ; Sat, 13 Jun 2026 09:04:26 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1781366657; cv=pass; d=google.com; s=arc-20240605; b=FgRxxEfuHC+ehgaYokvDEIUclPXQaiD6ixK/vo5qVf04zKwi/nss2YjZ20U8FUVdZn ow2yJiwC3nQACuUVcAt5PbFZE5WD7gbJW7Bk2zQMMKVHMNoZ3mW+5YWp4QtYmvbviSPj +dWR1mPjFT6NoNtbPKxpdkn37Jnz9PzEfvW79S7nwVz1zI5PrfaxHDnkcxNXAKRPFYYi Qj2ZsFgaJrkICNWAU0Zo3Fer7uNV+OJvpLeeNh2vls9PL2C4bZXq8I+KP8XPa9jf/gYA xFGhfarwg/lh7zeT/4OyiJj2NlZfcqoKohHWtjgOueSmtos4AJJ/tN7QNDfFz+V4IifN VyHw== 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=vVzd/DcLr/O8OBtHr2Oapn/OuNJDRC2Ip0X7l56g6Rg=; fh=814EQEDglkm+XPfvFr2LoQO8zR/vkNVJFD5/LtdJllU=; b=DFXyVTbOk0oMZ71KGGIFqV7OZEnXKabzYl/QocSROwlRvARcLyzhCvvnVUQ4/Wp9i3 IAmFpUnbTT3oCVX7TvqbbjcGn7hXJKyjCcWextEPDdreRSvm2oWyOnf1+QE3TbewR688 HcxWbZzkGkqAw9251ZqLVtsnZYveMkyjERV5nwBRlsPWHfrkK1Y8OBKhvY8F/cihiQV8 stusWOXq014aoFXxIgbGtGedEq9w80bLdsxYPyrocc6tfrXPmLfNMOjPGBQ26GFjgLCI BAXNCuztyeoZdyUSW9DckEoChhYHhSZMAHPQu/RLpxrGjj7XombAfr4lsLrklsQ+b5MY hHrA==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=PPY5E3AK; arc=pass (i=1); spf=pass (google.com: domain of patrickcerri@gmail.com designates 2607:f8b0:4864:20::e30 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=vVzd/DcLr/O8OBtHr2Oapn/OuNJDRC2Ip0X7l56g6Rg=; b=tI+WFWd0U9mJWEPhLsPjBsmzgh9Optf1gT5+TS2wPHAkjWSCR3mKrdTZ9WNYRyB6BG UD7FFh3X1MirO6qcJijB7RcZZ6ESE53sikpDOk5slUYp+Hdl72Oa0xFeqkp8TIvmXjlc EKDX4LSh0HMfLBP5idBHJPDKqiRqxid8nMGrzUHFlpiEX4OZasoVMNxdXaNBbKiu0yGf tBaehpw7HWNfroL9m89hw2ZoE162Ey/NaOo9U3hMyRmOubQyQfnn0bDL0kVb5mSEA6hl YalDeuBcS/+qmCOVZs+ycm7pc9BayOf4MzxMBElrpyxxenXanoNZneG+e8nZCMDarexn L76Q== 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=vVzd/DcLr/O8OBtHr2Oapn/OuNJDRC2Ip0X7l56g6Rg=; b=B/OxeerYcOl4Nx7+0ofhyY1DkYKhgX4X1fJOE3JU/ZajjL2HgQ/RmKtAs6FWW1SE9i XoijqyXG746QhV/zC0BehIg330lvZlCpg0hM9OimGbfvywsVpO7t3Oj1KYwrvv92hY47 6DkmWljQtJwlF6FIXtKLygYoIgxckP/HuZAzerFHVKmzuFFyTF+29P4NoqMWnUHufsdM F14FrFEisZ0z0ym9jNIIRoljItUf3AeofVR15YRd6ot4frijrZlJMH4IuUWeIW9zyiT1 PEkMKIxJ0iJEpSBalfiW+yxwqenxXbi38mC4NcdgSTM7Sb+OIKiGceBiVkS7xBZDtrIR ovgQ== 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=vVzd/DcLr/O8OBtHr2Oapn/OuNJDRC2Ip0X7l56g6Rg=; b=N7xIqw3B7h32KOF44gANE4OUMslIdPps32sY1PuAPfEp0n3B3aQGzfZyGB9+vY39S4 9QBW+WaUV/QZaEMbylCXP3dn54hOJcA9xkm+oN9P2KheGcSAuidJGGdczZ9Rw7wPDHRD QS4laAmdCieZzPzC9s9uIBYnxKhhqYNZVsOZZPX3iGQdhxa0Cwbdo2W0nhFEVXiL8C2l 4tvR2quBCo9DKm1vjqRAfQ+slj49h8FQ+PsPlhGLHAZA3BFj1li7XWg1KCcwTynXrWS9 EQicsI2JCHvM2WLgqFPHVIonSdqUyglfOe68zdRytVadAeOaDpkZBa6twxpWJbpwc1JC R9lw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AFNElJ+f++SDI+jDKrGawu3yyh/MytFpj8gRn31h7b5DhkeeoQwk1ShpIVIibt5Ebm49MFV/D9HcCB8f6W3x@gnusha.org X-Gm-Message-State: AOJu0Yz2ylxV1yYBP1je9MEfHmcRQ296tTjIp5VNciVnoeNdjLg2fptO KVawgOlLfXQYvNmyxwmsmn5JgAeBXAK0KO0jEt9pbfqIa0iNHtYvEo24 X-Received: by 2002:a05:622a:d12:b0:517:89d0:b8cf with SMTP id d75a77b69052e-517fe18fe25mr97113771cf.8.1781366657101; Sat, 13 Jun 2026 09:04:17 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUcwMeobe3rId+CJiUUZsc8UZxdbLJJ25WgTNATDB+Q+pQ==" Received: by 2002:a05:622a:48b:b0:517:7931:74c5 with SMTP id d75a77b69052e-517f9fa4fe4ls53711001cf.2.-pod-prod-01-us; Sat, 13 Jun 2026 09:04:13 -0700 (PDT) X-Received: by 2002:a05:620a:f0c:b0:8cf:f1d9:ba20 with SMTP id af79cd13be357-9161bab5f48mr1111330285a.8.1781366652915; Sat, 13 Jun 2026 09:04:12 -0700 (PDT) Received: by 2002:a05:6808:8854:20b0:480:77ce:ad79 with SMTP id 5614622812f47-48701e5f32bmsb6e; Wed, 10 Jun 2026 03:15:00 -0700 (PDT) X-Received: by 2002:a05:6a21:4cc1:b0:3a0:bc61:62e6 with SMTP id adf61e73a8af0-3b53bbe9261mr9796747637.8.1781086498560; Wed, 10 Jun 2026 03:14:58 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1781086498; cv=pass; d=google.com; s=arc-20240605; b=iWuV+SRTYfb0eejXKqG2DfBAig7iE3JUz8wW4TP1rQBc7A9+se91NEk3yBaElTSILC bfZvUJ27o9YJqv/BLIvTIy0VjdN+UnHHumvjafY1OAm2arTtc1qIVZl2Cz1guccH5kqu OiMZPL3JISxztZ9+Lu7MlYoFPOXp7uXx0dAewkYtu/mKE9JiJtRgd6+rTjJjCOdCF2n2 5fkMLCY8jjEEelLwkS9da1GJMs/2PBNW9/pNECDI2Bz52vlblqtGPGtRtYYa8ssh9Hsf fxcf+RPc65VF0sdaNsnFniRy6rPSfEdfPkD2X1Cb/oxYjSLxMgrGY8I5hPxqfLraB+zx WlpQ== 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=kDRayXXd51k09qs1vFQG/9HpKsPbdG1BDYExXEeWYlw=; fh=mzXEsTWDK6gnkBrY7ZCwwMohUIL8bXkfU2CQ462oZJ0=; b=khaq69cXp+NYRRXiJoncFFUjSWf2Du1AK7jsDLwGyELUoOCLwq648mFyTVfLRMKsyN R2iJnOMFBz+N0k+MUR8Iij3Q251ppDRsHSW5lMxVgLxE6YvrECQSbaaCrqPjoUNXSxir yH+3eiS9hG/A2JKSk6ou1+0k7cnFd8WSqtf8aqtMjeqd+n0alayzl66gqhCXZPU3sCtc +wOxVHzwHGrH/yHvMmorWkO5W2QZn14YV4iQIARM0aY38Df7ZyFK/dw1Q/wHQqffwSz1 ciqrx6U7jXlISVfL0g2RqAPZ2mukOCjWZ+FjsJ/HTRKa/97iMjpY/heWrOMXhv99qSeA 6Slg==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=PPY5E3AK; arc=pass (i=1); spf=pass (google.com: domain of patrickcerri@gmail.com designates 2607:f8b0:4864:20::e30 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-vs1-xe30.google.com (mail-vs1-xe30.google.com. [2607:f8b0:4864:20::e30]) by gmr-mx.google.com with ESMTPS id 41be03b00d2f7-c85df09c6e2si752252a12.7.2026.06.10.03.14.58 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 Jun 2026 03:14:58 -0700 (PDT) Received-SPF: pass (google.com: domain of patrickcerri@gmail.com designates 2607:f8b0:4864:20::e30 as permitted sender) client-ip=2607:f8b0:4864:20::e30; Received: by mail-vs1-xe30.google.com with SMTP id ada2fe7eead31-6cf48482ddeso2128306137.2 for ; Wed, 10 Jun 2026 03:14:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781086497; cv=none; d=google.com; s=arc-20240605; b=M0LpyhIc41oH0FxaeXbEria1hB0vetGhGjSIiGkftAipgeERil9a5nSy1RcFmaSGpg j/t662+bwPSEKpXj7tMlOeSPZKi54N/bEeeNoXI4dxV5DCp6o25FY9PUPB149j+0FWKv AbdpWK6vWyYvGLoET8ClACegOr9G9r3OyGCirKjZ1l2RiT4NYhF+om1QLR1a+L4a1emB Hr2jovmKX/vqN9Zwlrc4b/BDnY3Nx9672m9GbVKGz6YTrHIeMqXFhK9V5fCKyG057pd4 z5Fztl+KULLOqPvvbp1fW6+//9Y6BMqD/wkGt/tC4LM9W0BC8N7mRY8P1tjIVfmbe6yK WBKA== 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=kDRayXXd51k09qs1vFQG/9HpKsPbdG1BDYExXEeWYlw=; fh=mzXEsTWDK6gnkBrY7ZCwwMohUIL8bXkfU2CQ462oZJ0=; b=QCcP15gqzaNpGb0vT2MLoxkT+4Z1mT04000PBpUDaZg8IfjAxb3q4j//1/ir/Xl2Jh AMIs6Ld/TT0P4WUdBwP6n9AHeU0LehDdTYnxoyp1u+88rMJJJGXodH1y/EoNQQvu4iao pZy+hvWAcQ6Hwq1d5bROn3BQA87KZnpPpnUoi3Qw2QqK1YEJqljvbWlkoaQWpL6clp1e QjpQWjx+GjK1uNYKduZYWEr1mMc52EWyKxstpPfogsKoSVSv6grzIrTJ2SHLrHmbNw09 FDKNhbkwNukt0lcb5lJ2Ll91GfXiTnNyT8koRXBdGjsCail+u/OTQeOCI9WQ7rVikdw0 SAGQ==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: Acq92OH37mhaCKcWz4Tykx/h/HQl2FDuwkJ83NFEG/0UAJWS+2dzhWsMinNl9J3+qUm NDAsoprQq2+tAr8j5lQ3Rxrd5DweBpl5AFuOVU5Cb5A91f/L6QJWlx0iVomTdylWjiRXYsqUcgI pHR6BZxtDpunrLNzzD6EAkqndrDY6WyM0EFrW6nbiyDapEGnGVqIP5DNv3IsdV8O+y1eXNQO0Mp 4TKii6qwaU+Es/TrzcknFcaiUoVIh2wI7MTP4zxcMz/Yj7t2ZRzwnwiUhQLt7kc/ErnYoeOP5uH Hs2p+jCU049je8kP1A== X-Received: by 2002:a05:6102:80a3:b0:639:4bb7:c915 with SMTP id ada2fe7eead31-719361e0b44mr3882693137.16.1781086497412; Wed, 10 Jun 2026 03:14:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Patrick Cerri Date: Wed, 10 Jun 2026 11:14:45 +0100 X-Gm-Features: AVVi8CfRe-MK33gSCvjrUleobmwaU6pZbZJo7lt6v7suJZga7FofBY_6tZRJ2Fw Message-ID: Subject: Re: [bitcoindev] A look at SHRINCS To: conduition Cc: bitcoindev@googlegroups.com Content-Type: multipart/alternative; boundary="000000000000fe1c210653e3833c" 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=PPY5E3AK; arc=pass (i=1); spf=pass (google.com: domain of patrickcerri@gmail.com designates 2607:f8b0:4864:20::e30 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 (/) --000000000000fe1c210653e3833c Content-Type: text/plain; charset="UTF-8" Just to add : We are thinking about storing this information ON the chain itself - in some way. Knowing the value does not make the signatures any less secure so sharing publicy does not seem to be an issue. - The simplest way is to just count the number of times an address has been used by scanning the entire blockchain and all transactions.. and then use that value as your current key uses. This unfortunately does not work for pruned nodes. But you could ask a non-pruning node to give you this number. Resyncing from genesis on your pruned node works. This could be optimised a lot though. - You could add the value ( somehow ) to every transaction you send and then you would only need to check your very latest transaction from a certain address to retrieve the value. - This on-chain system does not work for any off-chain signatures you may have performed - say to prove ownership of coins ( which we do in one of our ticketing apps ). And would not work for lightning addresses - you'd need some other way to keep track. On Wed, 10 Jun 2026 at 09:58, Patrick Cerri wrote: > 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%2BXTFgWLZ9AwSJouyoy8gZ0iGwcKpUBMmXTWLoKehZ%2BfzA%40mail.gmail.com. --000000000000fe1c210653e3833c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just to add :

We are thinking about storing this i= nformation ON the chain itself - in some way.

Knowing the value does= not make the signatures any less secure so sharing publicy does not seem t= o be an issue.

- The simplest way is to just count the number of tim= es an address has been used by scanning the entire blockchain and all trans= actions.. and then use that value as your current key uses. This unfortunat= ely does not work for pruned nodes. But you could ask a non-pruning node to= give you this number. Resyncing from genesis on your pruned node works. Th= is could be optimised a lot though.
- You could add the value ( somehow = ) to every transaction you send and then you would only need to check your = very latest transaction from a certain address to retrieve the value.
- = This on-chain system does not work for any off-chain signatures you may hav= e performed - say to prove ownership of coins ( which we do in one of our t= icketing apps ). And would not work for lightning addresses - you'd nee= d some other way to keep track.



On = Wed, 10 Jun 2026 at 09:58, Patrick Cerri <patrickcerri@gmail.com> wrote:
Yo.

WRT to
| Keeping state is not trivial. This is MUCH harder for Users than I expec= ted.

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 par= t 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 Us= er 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 no= de through choice did not think to check that final value before starting u= p 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 sl= ots overlap. Although I did see there was some talk of creating separate tr= ee paths for separate devices which may help. All though then you would nee= d 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 j= ust not technical ) simply do not comprehend what this is and confuse it fo= r how many times they want to use their address.
- Even though we have t= ried to explain this as fully and comprehensively as we can, this informati= on has just not percolated through the ecosystem as we would have liked. So= me really have no idea that it is required at all and are just confused whe= n 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=C2=A0them 'Ho= w many times have you resynced ?'.. and whatever number they give we ju= st 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 bu= t 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 whe= n it happens. And some do not realise how important this is and always say = this is their first time to reduce information leakage - incorrectly thinki= ng we are harvesting information or something.

Some have used an ad= dress MORE than 10,000 times.. this especially applies to Exchanges or more= business oriented accounts that send a lot of transactions from a single a= ddress. It's a crude approximation that has pros and cons. Certainly no= t infallible.

As for our current implementation of SPHINCS.. this wa= s done in house with the scraps of information we managed to extract from t= he 'inter-web' - SPHINCS is really quite a simple and elegant syste= m. 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 ve= rsion takes 20-30 seconds to build a key and sign.. but that is probably th= e slowest it will ever be! The verification at least is still fast. This ma= y be something to think about though as anyone else trying to create an imp= lementation 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 202= 6 at 18:38, conduition <conduition@proton.me> wrote:
Hi spartacusrex, thanks for raising t= his 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 po= int out, SHRINCS v1 doesn't give signers any flexibility in the statefu= l signing path to handle alternative use-cases. Since I started working wit= h the blockstream folks, I think we've all come to agree this is a pote= ntially important feature for some use-cases, that ought to be available. S= ome use cases would prefer constant-size signatures with higher stateful si= gning budgets. We don't want to 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 where signers can choose to use a balanced or an un= balanced XMSS tree structure in their stateful signing path, with the conse= nsus-verifier being flexible enough to accept either format without disting= uishing (i.e. a signature from a balanced depth 8 XMSS tree is indistinguis= hable from the 8th signature of an unbalanced tree).

As for multi-tree support, that is still uncertain. The main use-case fo= r multi-tree XMSS would be lightning - nobody else ever needs to sign so mu= ch that they'd need multiple stateful trees, and if they do they can us= e the stateless path. We're still too early in the design process to sa= y 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 pu= blish 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 rea= l-world knowledge of how this plays out in a live environment.

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

I'd love to hear more ab= out your experience with this. You mentioned wallet restoration as the main= pain point, but are there any other issues you've run into deploying s= tateful signatures in the wild?=C2=A0

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

- Creating= SPHINCS sigs is a lot more resource intensive than WOTS.
= - RAM usage is 100x more ( not soo bad )
- SPHINCS s= igs are BIG. ~20kb. Bigger than a regular WOTS sig and MUCH bigger than reg= ular BTC sigs .
- Real issue is that on a phone the SPHIN= CS 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.=C2=A0

  • SPH= INCS+ signatures with a 128-bit security level can be as small as 3-5 kilob= ytes if you adjust parameter sets properly for your security and performanc= e tolerances. Given the fact you referenced HORS in your message, are you u= sing the legacy first version of SPHINCS?
  • RA= M 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 1= 2 milliseconds on my desktop CPU, or a bit slower on a mobile CPU. With a G= PU you can go even faster. Scott Fluhrer also has this awesome multit= hreading+AVX implementation which go= es pretty fast too.
  • The big performance pain point for SPHI= NCS is hardware wallets and other embedded systems. The current gen of hard= ware takes 60s+ to sign with SLH-DSA-SHA2-128s; longer if using a secure-el= ement like Ledger. But there are still ways to optimize even that use case.

What you need is :

- An OP_ for general M= erkle 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 sc= ript 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 op= codes/schemes in script. We decided not to, because of how challenging it w= ould be to implement secure multisignature scripts. You'd have to handl= e 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.
<= 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%2BXTFgWLZ9AwSJouyoy8gZ0iGwcKpUBMmXTWLoKehZ%2BfzA%= 40mail.gmail.com.
--000000000000fe1c210653e3833c--