From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 20 May 2026 10:44:11 -0700 Received: from mail-oa1-f62.google.com ([209.85.160.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wPkxn-0008Iz-4R for bitcoindev@gnusha.org; Wed, 20 May 2026 10:44:11 -0700 Received: by mail-oa1-f62.google.com with SMTP id 586e51a60fabf-43a4f4a252csf6426229fac.2 for ; Wed, 20 May 2026 10:44:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1779299045; x=1779903845; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:sender:from:to:cc:subject:date :message-id:reply-to; bh=NVLDVZ8/42/U02Qr49QEqQVRZIoGSmiFyp/RYJkN9WU=; b=jaLDAkzoLOjjhBjXmShWAEe4r3r0lUivK70/0bmJvRqfSHUeC/mRyJGgTCfjVOswrr rzIX1cqDtE1+JI0tbTW//RLKGwh0lb9mw43rmJFg1s5c8LpEpQrszEabvZbQm0JbWiiY 0tmKzdy0I3vWpN0FixRrp8AQpXEs3tZGQtxGVDweoRA5YZZtjSSBRrqXFW+mFDcbWs8H R9oOpA4yBf4io/rCoKA87NaWubgwCMWhbyPACK1GiLkWX3RFtZdwfLK6Yk5i8Kd8awM2 DHr10ERaOjw/1mb79QvFUT4135a/Bf4pzY5ax8ASH9/MBZzKt+TVS+YmpmD2e9OgvRzF iL0g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779299045; x=1779903845; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:from:to:cc:subject:date:message-id :reply-to; bh=NVLDVZ8/42/U02Qr49QEqQVRZIoGSmiFyp/RYJkN9WU=; b=kLUUhc/j+xsZkd04ltYvEyMdWM0kMJzrOlmsQiOdHN1jSX4ksZAb267Wyfq/xAL0Un irRtSUrIyDBnXv1oAnRuDvzJQ+HKFle69BsQFglp9HGACc1Awjbp7xXdTNih6oorWgJc 8mLmp5lv6yuWd3322GKu45AbTFfBlVlNlfR0gc70tapDGi2mkVoUPEAQRg6RLg67O9+3 48RJJ1CE5IBiMvIc65mXrt+7aMqSJV4jZRCaOPxK1A1rTeUHyXihiPw3LF+qs2BxAxEq BjCdLLE5ezALH1RbkpPF3X4d4ukoKKiH7JfCyA/uOYeM/CLw1cHzsVufTyyqoRg5OdaT UpOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779299045; x=1779903845; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=NVLDVZ8/42/U02Qr49QEqQVRZIoGSmiFyp/RYJkN9WU=; b=tYWGTo4v/pob/8rvl6tPtDezm+Tn9R3KTvXjGnS306IBsoaeE/geOod9tYyyYj6rrj Goe9mW04QM9PJyTpGvqaRqNa8Bk3FZcpoOEsOc6RQysJ2z1JAJf3Ffb2lQEa84ElTGI2 oEElYuodFMFMG0k0Or1kutu+Q8+8F7CQ0MQbhhGp5nc/4slfaFFDaPHEvxBOVqcW2HVx XS5Y7rqeeMP+nx7IOpxgxjqnQJJhWoZ1pqAcxUTqrXA9KpbBooinyn0TulLXAg/ndT3P Goa90YDBrNoBHpaHovolfeTE80dfMstpLLEtjdz5o7KvheYEyeVkxmGJTkj4i2oIb3Vp zeMA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ8fRCc/LSwo+aOQlGWuywcjwVmlGdoFbGzjEVm3bpH0DsDB5EVl4krwm3Vj/o2at/0KlG9+5I3A7n4M@gnusha.org X-Gm-Message-State: AOJu0Yww0fDOf5SsJP8R7MzAIRJEtZ1MCxbposkhmJZZ76rklUznMDpy ErWxhZCEJBA22J6LmuYHVnLn4DKnxyP1siS/tU3Ew/5+gxvNKc4/DqYd X-Received: by 2002:a05:6871:b21:b0:42f:cd67:2b84 with SMTP id 586e51a60fabf-43a2d9cb7damr15630221fac.9.1779299044510; Wed, 20 May 2026 10:44:04 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMNRH6kmFOqR54nV3nngStOaagCUNo7xc0tfJyQQgG3Z/g==" Received: by 2002:a05:6870:a083:b0:422:c0f1:a9e4 with SMTP id 586e51a60fabf-43a0119a7cdls6843847fac.0.-pod-prod-08-us; Wed, 20 May 2026 10:43:59 -0700 (PDT) X-Received: by 2002:a05:6808:3028:b0:479:2ef3:50a5 with SMTP id 5614622812f47-482e55aa09emr13876899b6e.7.1779299039413; Wed, 20 May 2026 10:43:59 -0700 (PDT) Received: by 2002:a05:690c:4507:b0:7b3:13f7:5f3a with SMTP id 00721157ae682-7c698ddb9c3ms7b3; Wed, 20 May 2026 10:41:23 -0700 (PDT) X-Received: by 2002:a05:690c:6d84:b0:7bd:7d69:7660 with SMTP id 00721157ae682-7c95c6f43b2mr277848247b3.43.1779298880884; Wed, 20 May 2026 10:41:20 -0700 (PDT) Date: Wed, 20 May 2026 10:41:20 -0700 (PDT) From: Jason Resch To: Bitcoin Development Mailing List Message-Id: Subject: [bitcoindev] One Time Signatures as an Advantage? MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1525834_879220573.1779298880517" X-Original-Sender: jasonresch@gmail.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 (/) ------=_Part_1525834_879220573.1779298880517 Content-Type: multipart/alternative; boundary="----=_Part_1525835_1737648294.1779298880517" ------=_Part_1525835_1737648294.1779298880517 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable NIST is standardizing SLH-DSA as a stateless, post-quantum-secure=20 hash-based signature scheme. However, to achieve the stateless feature of= =20 being able to sign multiple messages, requires a significant size overhead. SLH-DSA (for parameters n=3D16, w=3D16) results in signatures that are 7,88= 8=20 bytes long. However, if statelessness isn't required, and this can be reduced to 900=20 bytes for something like XMSS using the same parameters. Furthermore, if multiple signings per key are dropped as a requirement, and= =20 "one time signatures" are used (e.g. WOTS+) then this size reduces further= =20 to 560 bytes. This is a ~14=C3=97 reduction in signature size for a feature that Bitcoin= =20 transactions not only don't need, but are strongly discouraged if not=20 harmful. Using the same key more than once is only required if one is=20 reusing the same address (discouraged), or if one is attempting some kind= =20 of double-spend attack. This could be seen as a sort of advantage: if one attempts to double-spend,= =20 they may expose their private key. This same property was an element of=20 Chaum's digital cash: attempting to double-spend exposed you. Is there any advocacy for NIST to standardize stateful or one-time-use=20 signature algorithms? They seem well-suited to the block-chain use case,=20 where there is always global and persistent state, and keys ought not be=20 re-used. Though this needs to be carefully managed by wallet software: to= =20 only expose a one-time-use address to handle a single transaction with a=20 single payer, and never use a OTS address for any kind of public-facing or= =20 long-term donation address. Perhaps this complication makes OTS not worth= =20 introducing generally, but their space saving properties are attractive. Jason --=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/= d3648bd4-03d3-4b98-92bf-d845302be349n%40googlegroups.com. ------=_Part_1525835_1737648294.1779298880517 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable NIST is standardizing SLH-DSA as a stateless, post-quantum-secure hash-base= d signature scheme. However, to achieve the stateless feature of being able= to sign multiple messages, requires a significant size overhead.

SLH-DSA (for parameters n=3D16, w=3D16) results in signatures t= hat are 7,888 bytes long.

However, if statelessn= ess isn't required, and this can be reduced to 900 bytes for something like= XMSS using the same parameters.

Furthermore, if= multiple signings per key are dropped as a requirement, and "one time sign= atures" are used (e.g. WOTS+) then this size reduces further to 560 bytes.<= /div>

This is a ~14=C3=97 reduction in signature size = for a feature that Bitcoin transactions not only don't need, but are strong= ly discouraged if not harmful. Using the same key more than once is only re= quired if one is reusing the same address (discouraged), or if one is attem= pting some kind of double-spend attack.

This cou= ld be seen as a sort of advantage: if one attempts to double-spend, they ma= y expose their private key. This same property was an element of Chaum's di= gital cash: attempting to double-spend exposed you.

<= div>Is there any advocacy for NIST to standardize stateful or one-time-use = signature algorithms? They seem well-suited to the block-chain use case, wh= ere there is always global and persistent state, and keys ought not be re-u= sed. Though this needs to be carefully managed by wallet software: to only = expose a one-time-use address to handle a single transaction with a single = payer, and never use a OTS address for any kind of public-facing or long-te= rm donation address. Perhaps this complication makes OTS not worth introduc= ing generally, but their space saving properties are attractive.
=
Jason

--
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/bitcoind= ev/d3648bd4-03d3-4b98-92bf-d845302be349n%40googlegroups.com.
------=_Part_1525835_1737648294.1779298880517-- ------=_Part_1525834_879220573.1779298880517--