From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 26 Aug 2026 14:38:08 -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 1wzLJv-00079D-7z for bitcoindev@gnusha.org; Wed, 26 Aug 2026 14:38:08 -0700 Received: by mail-oa1-f59.google.com with SMTP id 586e51a60fabf-46524220c5asf2218356fac.0 for ; Wed, 26 Aug 2026 14:38:07 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1787780281; cv=pass; d=google.com; s=arc-20260327; b=V1hdvhc+pae0rRCEfolNZF8L308poE9vgciFTZ0uKZxZhFCcU+o8WOgyNyfs7eCRT6 IlJz7pQnMtGqzzs767TlCkiVL6n6o5EEbj56DxF/1Azp71gCtuh8ZHuY6lo+rx3VImpk vJLPYlwEh35z7Wl3V9XNJS4uTKBzmfgPlzGqke2l7vLGy/1MFAqPLl1R/dTvaT20GWbk 2ujF1M2qxO+Y7CKhmrzYZOeDREJSS01Y/RxF4twT0xv2BJvbev4IhHfrwHCq4uK4J6wQ WPotJRXbC3ixwJZVMfTTL8d1GY7AVpZ0DnaeEatoGHGO76BQ9v5P1ZJL9kA7KgjdSq5j zIaA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id :message-id:subject:from:to:date:dkim-signature; bh=YI3hlrQIxqgo96i9djCJS0cp+cECXQoNnISxk1/Z1/A=; fh=ma1zUQOVQ/Tt6SqB98n+CcNiVnBcX8QIdYMOx7/movI=; b=baNQeHc/upgfNy2brU2wbwT6k2otAizWT1XmC0oNEU5iXw+iS0sYgGnXhTWDsnDvKh g9KmRPdufzmvUYJfjthU8C0oWa7fSv6KZA2T8NwqAKj1g916hS9mRQzgMVa6sB07DPvp ZKgmUyCE7hU7ftBX/0lB9OcXueNrT+Y7ZG2iDUGjdRhzGPEm9IBP/0MnA32pON6Zekpu tY9MYChCpI/ugMBe+rmgzuRYF8PqqdXaHTdQZ0rxdrp7oUSB5qflUAYjpjrHQg+t35YX VwAqM7+Du95CohnIRQ+Fw2L1pTBVxq0ENAc3DOkKviPDmMbvG6ywjV8c/NYRcCmmCKte FJ0g==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=b7sgfo5j55htncldsnxipqgsue.protonmail header.b=h0Pqrrto; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.24 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=1787780281; x=1788385081; 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:content-type :mime-version:feedback-id:message-id:subject:from:to:date:from:to:cc :subject:date:message-id:reply-to:content-type; bh=YI3hlrQIxqgo96i9djCJS0cp+cECXQoNnISxk1/Z1/A=; b=I4niMcJ7nGhvaOxa28WALim0yOKAs9az1IMV+L7v4sLLk8pg4talYj3/JlRp2+sjDV 7MfZ4vdnjl2JlaB3mPBOaLNQGv8IRTi/6JHfv9RvX30CZzd4hirQNXxKhh3E2dQ7DEhz BHbEp8Skyjb7Mtd2TNKemCcbmBsJnJuJR4z9SqQt1416FEHYhYL88LDnZsENyIFethPB l5BSV8mbxvdhPZ3BOf4CInJA+cYw1zc99ClncedJzqZpt6TpwL30o6bdeouMndSyPccR 7TTbmyaYjbbnB8u9IStR96znimWaNTGwOK0gdQqZqd938gMbeFvQP4f43cakryoV5u7Q rKDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787780281; x=1788385081; 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:content-type :mime-version:feedback-id:message-id:subject:from:to:date :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=YI3hlrQIxqgo96i9djCJS0cp+cECXQoNnISxk1/Z1/A=; b=C45ksH3IpY/9oe9lVfGDuYNOctFLU2kZAiG5WCXeP9tUmbZbsmyKqo56LgIDocRZ4Q d3w2OZVJPu0UIP80EFKnwiqp86bYb16N5sl7PrP04J18i8kqlDKzhmsQrBAahmbRwP3h NwPEsO2Vs2Motax97CleqqbTC8MEgKgc3GXPT4GuB5VvXjxyMHsvFd7ifJ/Jx4EXm19V o6F+0rLkFMJrdpKa9rhMo9oqNSuSS3njiA15eSOIhLBzzpy2abgUqeL3mKlW+aHt2+5g /fnj9JRjF3LpaOrzCDHovZN22PFXkjP47NjrIlOiD9GgOFnqv9XfHe/yIBQFHn0z+9kE IHpg== X-Forwarded-Encrypted: i=2; AHgh+RpyYbRaqgYGHxKFEpHMvct67azYKcuhxseOlqSe4IUc7+3OfmCK/w9ZemYSQpd/TPOETG1ztWPsdPc6@gnusha.org X-Gm-Message-State: AFuF++lRkBQ5WjVWMK7rTfojDFkB9Zh1YmLQWpGnYaWIHX9pOKDoZ66S ayibx6u9eJwiSz1l8K0Kw6PyKoybyA44bWUeG5f/T6itsBMgZv4p6AXY X-Received: by 2002:a05:6871:e8c:b0:44c:a987:82f4 with SMTP id 586e51a60fabf-46599818af5mr11419531fac.10.1787780280982; Wed, 26 Aug 2026 14:38:00 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLddOvC5n36WcTRKKToxziKa40OjY44jruAe56BgbVBAUQQ==" Received: by 2002:a05:6870:82a4:b0:466:8741:3d07 with SMTP id 586e51a60fabf-467145f21b8ls202151fac.2.-pod-prod-08-us; Wed, 26 Aug 2026 14:37:55 -0700 (PDT) X-Received: by 2002:a05:6808:c2f9:b0:4a4:866:c395 with SMTP id 5614622812f47-4b366b2a7b8mr11606625b6e.13.1787780275449; Wed, 26 Aug 2026 14:37:55 -0700 (PDT) Received: by 2002:a05:6808:c0db:20b0:495:e116:a399 with SMTP id 5614622812f47-4b366f58bdbmsb6e; Wed, 26 Aug 2026 14:17:26 -0700 (PDT) X-Received: by 2002:a17:90b:164b:b0:396:4cbf:45a2 with SMTP id 98e67ed59e1d1-3966d8b56d7mr18175520a91.14.1787779045867; Wed, 26 Aug 2026 14:17:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1787779045; cv=none; d=google.com; s=arc-20260327; b=M81AbS1Hn0FsgecBcsEERFd1NQASFoVkxAw/hStkp+jEX2QrqZzvCY/zCCK4RUZvRa P1VajeMB/5tTchFxSOMU+XVCV9SDu1GiLpbKtY2Gn1atkE8u1hzU6Ty5mIEi53qbrbqC pM4vkHOKqkv5Fl+NzteFijltktx5RW0UCsAjaLtQpyHyjlvevMCTn0ihH1JdWSqW8mqP wDXl8a30iuA6UARjgd6cCGWyLDzBfVoOcEPGkDvu8WyiyDczhkvmx7ZDesmL1DCgT5Vy fuTPJNuMoo+73njTy34UK8CTIQ3oqIL7R19kNd7H0RBI/+vg9QfYTI0hLg9ovmoBChJN GJOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=mime-version:feedback-id:message-id:subject:from:to:date :dkim-signature; bh=3XW60jVr+gPAZqXIZDPvuVqg6Ra6fPfndgjMv6wY6gg=; fh=lhFSo2W/mHC0QoJ9oNg3A35n0DTltt3CQl1/0RggJlk=; b=gpQMYy0niLHw3yLLwC3ZZyZA1i1CeJRqybK7PUj/f0k2tt5OvQChURksIg+o93pZTJ efhbKw3xhaUgSOxkxCXx5PFhHk3CPhwmxqHOJ8iC66tRwI3NsDnjROLlzrcXCroSuSSt MmYyPaA65ch01zIyGvRfMi3neyowoRCe7ubE5MBcX0wBqweUnLH7t9uZM4/SmI12qDUd Z57vygPBsbCAA+eHiY6Qh1v989wgGUD/sMlnIuXmW10VQTE+f58FzZbNTY+AeAVqELu3 OFgwet+/K6AAdfFl/RHycsI5fsSRFn+VVCT4I0CJKB13eJS7hvUUiM3VPXRvtxTm5Uij 8khg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=b7sgfo5j55htncldsnxipqgsue.protonmail header.b=h0Pqrrto; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.24 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-24424.protonmail.ch (mail-24424.protonmail.ch. [109.224.244.24]) by gmr-mx.google.com with ESMTPS id a92af1059eb24-141a8ec9b63si130420c88.1.2026.08.26.14.17.25 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Aug 2026 14:17:25 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 109.224.244.24 as permitted sender) client-ip=109.224.244.24; Date: Wed, 26 Aug 2026 21:17:20 +0000 To: "bitcoindev@googlegroups.com" From: "'conduition' via Bitcoin Development Mailing List" Subject: [bitcoindev] SHRINCS: an efficient hash-based signature scheme for Bitcoin (first draft) Message-ID: <-w8D4WbD7zY2bfYQIES40iBZQWbZx6ab-S6EW8tWsMEFaHO9NEOLUkte_MZZgNQDd0pljCM2wD1Ccnk3BfjwLPgCiVz-NfTwjHJ4aZHUqUw=@proton.me> Feedback-ID: 72003692:user:proton X-Pm-Message-ID: e3f4e90c2eb8ebf7a8ecc22024d53611a4126d71 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------3c19ac54d73f50d026176b98cdcbb42c50ad630d2ee739799c6eaa49ae933ee9"; 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=b7sgfo5j55htncldsnxipqgsue.protonmail header.b=h0Pqrrto; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.24 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) --------3c19ac54d73f50d026176b98cdcbb42c50ad630d2ee739799c6eaa49ae933ee9 Content-Type: multipart/mixed;boundary=---------------------3a06de878e4bbf8da60fec44c8ea26fc -----------------------3a06de878e4bbf8da60fec44c8ea26fc Content-Type: multipart/alternative;boundary=---------------------53ce17e0b9569d993e51df0d52bb4822 -----------------------53ce17e0b9569d993e51df0d52bb4822 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi everyone, it's me again. On behalf of the SHRINCS Working Group, I am excited to announce a first dr= aft of a cryptographic BIP that fully specifies SHRINCS: A semi-stateful ha= sh-based signature scheme for Bitcoin. https://github.com/SHRINCS/shrincs-bip/blob/main/SHRINCS.md Disclaimer: Do NOT use in production. SHRINCS is prototype cryptography, st= ill in need of peer review. Formal security proofs are WIP. Features SHRINCS offers: - Compactness. SHRINCS public keys are 48 bytes. Stateful signatures are = 548 bytes at the smallest, with a stateless fallback component built into e= very key pair by default that produces larger 5777-byte signatures. - NIST-I security (~128-bit classical and ~64-bit post-quantum). SHRINCS'= security depends only on properties of the (truncated) SHA256 hash functio= n which are believed to be post-quantum-secure. - Fast verification performance. Amortized on a per-byte basis, SHRINCS s= ignatures are 4x-16x faster to verify than BIP340 Schnorr depending on whet= her SHA256 hardware acceleration is available. At worst, verification costs= 2792 SHA256 compressions with a 5777 byte stateless signature. - Flexibility. SHRINCS allows signers to control the shape and size of th= eir stateful keypair to best suit their use-case, while SHRINCS' stateful v= erifier is agnostic to signer-side choices and contains only a single code = path to be scrutinized and optimized. - Good incentives. SHRINCS with UXMSS provides the most compact signature= s possible within the scheme, and the signatures grow as a key is reused. I= f SHRINCS comes into common use, users will be economically incentivized no= t to reuse addresses. Address reuse would still be possible, either via sta= teful BXMSS keys, or via the stateless component. Drawbacks SHRINCS has drawbacks: - The efficient stateful component requires software that can manage an i= ncrementing state counter (essentially the number of signatures issued) for= each keypair. If wallet software accidentally reuses the same state counte= r on two distinct signatures under a key, any adversary who observed both s= ignatures can forge a new one. - The key generation and signing algorithms are computationally expensive= - Though this can be mitigated using SIMD, parallism, or hardware accelera= tion techniques. - SHRINCS lacks any algebraic structure allowing for public key rerandomi= zation (to admit BIP32-style xpubs), multisignature schemes (like MuSig), e= tc, in contrast to feature-rich cryptosystems like Schnorr. Changes This new specification is the evolution and formalization of ideas original= ly put forward by Jonas Nick and Mikhail Kudinov in=C2=A0this Delving threa= d=C2=A0and in=C2=A0their joint paper=C2=A0referenced therein. Also see=C2= =A0this related mailing list thread. Notable changes since the original proposals 8+ months ago include: - Black-box compatibility with SLH-DSA (FIPS-205) algorithms. This encour= ages interoperability with non-Bitcoin systems, and leans into established = security proofs. =20 - Flexible XMSS (FXMSS). Prior descriptions of SHRINCS implied only unbal= anced stateful trees were allowed. We now allow stateful trees of any struc= ture. - New parameter sets. The stateless component now uses a parameter set al= lowing at most 2^40 stateless signatures, rather than 2^20. This allows SHR= INCS to be useful for=C2=A0protocols that require high-frequency signing, s= uch as Lightning. The stateful component now uses parameters which offer mu= ch faster performance (at the cost of larger signatures) compared to the or= iginal proposal. Status This initial draft specification contains only the cryptography of the SHRI= NCS scheme, decoupled from consensus validation rules. Further BIPs would b= e required to deploy the SHRINCS signature scheme on Bitcoin. Notably, we c= annot safely deploy SHRINCS without introducing at least one new output typ= e, which we do not define in this BIP. The draft BIP-SHRINCS is not ready to be submitted to the BIPs repository y= et. We still have much work to do. Notably absent from this draft are: - Test vectors - Unit tests - A security proof - An optimized implementation - Mediawiki or Markdown format compliance We are posting here to seek review of SHRINCS' design, parameters, cryptogr= aphy, and reference code, primarily for security, correctness, compatibilit= y, consistency, and clarity, in that order. Insightful reviews will be high= ly appreciated and met with positive vibes and beers at the next conference= :) We also hope that seeing a concrete specification will spur further discuss= ion of related problems, such as how PQ HD wallets will work, and how to ha= ndle user experience of a semi-stateful signing scheme. We note that SHRINCS' parameters offer a complex=C2=A0multi-dimensional tra= de-off space between performance and signature size. The choice of paramete= r set therefore seems ripe for bikeshedding. We provide a forum for paramet= er set discussion here, but we encourage prospective cyclists to first=C2= =A0read the relevant sections of the=C2=A0design rationale, and invite read= ers to also play with=C2=A0our interactive stateless and stateful parameter= set exploration tools. Those who prefer video format may be interested in this interview discussin= g the internals of SHRINCS:=C2=A0https://youtu.be/n-jGPICZMR0?si=3DNpfyTRB8= 8-sUxtlh Related Work We are building libshrincs, an attempt at a formally verified C implementat= ion. One machine-checked Rocq=C2=A0theorem covers WOTS+C, the one-time sign= ature in FXMSS: honest signatures verify, the linked C implements its four = public contracts under CompCert's semantics (VST), and forging costs breaki= ng truncated SHA256 (SSProve). Still a prototype, more detail on Delving. Acknowledgements The SHRINCS specification is the result of several months' collaboration be= tween contributors across multiple organizations. The SHRINCS Working Group= is, in alphabetical order: - Mike Casey (OpenChain) - Conduition (Brink) - Ethan Heilman (Cloudflare) - Mikhail Kudinov (Blockstream) - Oleksandr Kurbatov (Blockstream) - Boris Nagaev (Independent) - Jonas Nick (Blockstream) - remix7531 (OpenSats) regards, conduition --=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/= -w8D4WbD7zY2bfYQIES40iBZQWbZx6ab-S6EW8tWsMEFaHO9NEOLUkte_MZZgNQDd0pljCM2wD1= Ccnk3BfjwLPgCiVz-NfTwjHJ4aZHUqUw%3D%40proton.me. -----------------------53ce17e0b9569d993e51df0d52bb4822 Content-Type: multipart/related;boundary=---------------------c0f988977e43876ee2d6b2def2131b02 -----------------------c0f988977e43876ee2d6b2def2131b02 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone= , it's me again.

On behalf of the SHRINCS Working Group, I am excited to announce a first dr= aft of a cryptographic BIP that fully specifies SHRINCS: A semi-stateful ha= sh-based signature scheme for Bitcoin.

https://gi= thub.com/SHRINCS/shrincs-bip/blob/main/SHRINCS.md

<= div style=3D"font-family: Arial, sans-serif; font-size: 14px;">Disclaimer: Do NOT use in product= ion. SHRINCS is prototype cryptography, still in need of peer review. Forma= l security proofs are WIP.

Features

SHRINCS offers:

<= ul data-editing-info=3D"{"orderedStyleType":1,"unorderedStyl= eType":2}" style=3D"margin-top: 0px; margin-bottom: 0px;">
  • Compactness. SHRINCS = public keys are 48 bytes. Stateful signatures are 548 bytes at the smallest= , with a stateless fallback component built into every key pair by default = that produces larger 5777-byte signatures.
  • NIST-I security (~128-bit classical and= ~64-bit post-quantum). SHRINCS' security depends only on properties of= the (truncated) SHA256 hash function which are believed to be post-quantum= -secure.
  • Fast verific= ation performance. Amortized on a per-byte basis, SHRINCS signatures ar= e 4x-16x faster to verify than BIP340 Schnorr depending on whether SHA256 h= ardware acceleration is available. At worst, verification costs 2792 SHA256= compressions with a 5777 byte stateless signature.
  • Flexibility. SHRINCS allows signers to c= ontrol the shape and size of their stateful keypair to best suit their use-= case, while SHRINCS' stateful verifier is agnostic to signer-side choices a= nd contains only a single code path to be scrutinized and optimized.
    • Good incentives. SHRINC= S with UXMSS provides the most compact signatures possible within the schem= e, and the signatures grow as a key is reused. If SHRINCS comes into common= use, users will be economically incentivized not to reuse addresses. Addre= ss reuse would still be possible, either via stateful BXMSS keys, or via th= e stateless component.

    Drawbacks
    SHRINCS has drawbacks:

    <= ul data-editing-info=3D"{"orderedStyleType":1,"unorderedStyl= eType":2}" style=3D"margin-top: 0px; margin-bottom: 0px;">
  • The efficient stateful component = requires software that can manage an incrementing state counter (essentiall= y the number of signatures issued) for each keypair. If wallet software acc= identally reuses the same state counter on two distinct signatures under a = key, any adversary who observed both signatures can forge a new one.=
  • The key generation and = signing algorithms are computationally expensive - Though this can be mitig= ated using SIMD, parallism, or hardware acceleration techniques.
  • SHRINCS lacks any algebraic struct= ure allowing for public key rerandomization (to admit BIP32-style xpubs), m= ultisignature schemes (like MuSig), etc, in contrast to feature-rich crypto= systems like Schnorr.

    • Changes<= /div>

    This new specification is the evolution and formaliz= ation of ideas originally put forward by Jonas Nick and Mikhail Kudinov in<= span style=3D"scrollbar-width:thin;scrollbar-color:rgba(0, 0, 0, 0.35) rgba= (0, 0, 0, 0)"> this Delving thread and in&n= bsp;their joint paper referenced therein. Also see this related mailing list thread.

    Notable changes since th= e original proposals 8+ months ago include:

    • Black-box compatibility with SLH-DSA (FIPS-205) algorithms. This= encourages interoperability with non-Bitcoin systems, and leans into estab= lished security proofs.
    • Flexible XMSS (FXMSS). Prior descriptions of= SHRINCS implied only unbalanced stateful trees were allowed. We now allow = stateful trees of any structure.
    • New parameter sets. The stateless component n= ow uses a parameter set allowing at most 2^40 stateless signatures, rather = than 2^20. This allows SHRINCS to be useful for protocols that require= high-frequency signing, such as Lightning. The stateful component now uses= parameters which offer much faster performance (at the cost of larger sign= atures) compared to the original proposal.

    Status

    This initial draft = specification contains only the cryptography of the SHRINCS scheme, decoupl= ed from consensus validation rules. Further BIPs would be required to deplo= y the SHRINCS signature scheme on Bitcoin. Notably, we cannot safely deploy= SHRINCS without introducing at least one new output type, which we do not = define in this BIP.

    The draft BIP-SHRINCS is not ready to be submitted to the BIPs= repository yet. We still have much work to do. Notably absent from this dr= aft are:

    <= ul data-editing-info=3D"{"orderedStyleType":1,"unorderedStyl= eType":2}" style=3D"margin-top: 0px; margin-bottom: 0px;">
  • Test vectors
  • Unit tests
    • A security proof
    • An = optimized implementation
    • Mediawiki or Markdown format compliance

    We are posting here to seek review of SHRINCS' design, parameters, cryp= tography, and reference code, primarily for security, correctness, compatib= ility, consistency, and clarity, in that order. Insightful reviews will be = highly appreciated and met with positive vibes and beers at the next confer= ence :)
    We also hope that seeing a concrete specification will spur further discus= sion of related problems, such as how PQ HD wallets will work, and how to h= andle user experience of a semi-stateful signing scheme.

    We note that SHRINCS' parameters offer a complex multi-dime= nsional trade-off space between performance and signature size. The = choice of parameter set therefore seems ripe for bikeshedding. We provide <= a href=3D"https://github.com/SHRINCS/shrincs-bip/issues/32" target=3D"_blan= k" rel=3D"noreferrer nofollow noopener">a forum for parameter set discussio= n here, but we encourage prospective cyclists to first read= the relevant sections of the design rationale<= /a>, and invite readers to also play with our interactive stateless and = statefu= l parameter set exploration tools.

    Those who prefer video format may be interested in this interview discussin= g the internals of SHRINCS: https://youtu.be/n-jGPICZMR0?si=3DNpfyTRB88-sUxtlh

    Related Work
    <= br>
    We are building li= bshrincs, an attempt at a formally verified C implementation. One machi= ne-checked Rocq theorem covers WOT= S+C, the one-time signature in FXMSS: honest signatures verify, the linked = C implements its four public contracts under CompCert's semantics (VST), and forging costs breaking truncated= SHA256 (SSProve). Still a prototype, more detail on Delving.

    Acknowledgements

    The SHRINCS specification is the result of several months' collaboration be= tween contributors across multiple organizations. The SHRINCS Working Group= is, in alphabetical order:

    - Mike Casey (OpenChain)
    - Conduition (Brink)
    - Ethan Heilman (Cloudflare)
    - Mikhail Kudinov (Blockstream)
    - Oleksandr Kurbatov (Blockstream)
    - Boris Nagaev (Independent)
    - Jonas Nick (Blockstream)
    - remix7531 (OpenSats)


    regards,
    conduition

    --
    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/-w8D4W= bD7zY2bfYQIES40iBZQWbZx6ab-S6EW8tWsMEFaHO9NEOLUkte_MZZgNQDd0pljCM2wD1Ccnk3B= fjwLPgCiVz-NfTwjHJ4aZHUqUw%3D%40proton.me.
    -----------------------c0f988977e43876ee2d6b2def2131b02-- -----------------------53ce17e0b9569d993e51df0d52bb4822-- -----------------------3a06de878e4bbf8da60fec44c8ea26fc 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== -----------------------3a06de878e4bbf8da60fec44c8ea26fc-- --------3c19ac54d73f50d026176b98cdcbb42c50ad630d2ee739799c6eaa49ae933ee9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmqPV9AJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmcC9l0uC3yoU4dgflT2AN4WGGtRJhstA36jBF17 coJbKhYhBEdIka0CMtrLdg13a3gpbO2E9rPFAAAZcwD/dlVEhffSfSe5XinU 8+RNKjL+jTr61rph1o7hNRDqwYwA/30/Ia9eoInmBWpNYaMFeW+OktHg2Ysc hGtCmrx/3qkG =8jFL -----END PGP SIGNATURE----- --------3c19ac54d73f50d026176b98cdcbb42c50ad630d2ee739799c6eaa49ae933ee9--