From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 08 Dec 2025 22:49:55 -0800 Received: from mail-oa1-f58.google.com ([209.85.160.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vSrXl-00032H-Gm for bitcoindev@gnusha.org; Mon, 08 Dec 2025 22:49:54 -0800 Received: by mail-oa1-f58.google.com with SMTP id 586e51a60fabf-3ec7ae153fasf3496144fac.0 for ; Mon, 08 Dec 2025 22:49:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1765262987; x=1765867787; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :mime-version:subject:references:in-reply-to:message-id:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=XBEvy+e2z0BE9vXhFfF81MVx1kRhZ2M67JzG+fDYfaA=; b=v/hMcXB1bSt7hxUaaf/Ki4pZ6j1FB2FDOrDkh57RBzSuUaYf8MpujI7cfqSz9SS6uO +Qp1JYsVHlzLINRPepPb+UFUHebg8Ced9d0IES2OyWlr7KLLq5XOf4oC/+upBNUyhAWc A+NOni3MGcYTqPS7PU0cnw3MRPWpZgb7sY3hK38jwI7OIEl+Pm0rm5XmlJMQO3ZwoG2G rjxFEMBx/31+vAyOCxgG4I7yOJARe8KWGuooCjKb6hWG9Dwf9dJUvtlnJ4AFSaLiHEwH OaLWaDtGvx0czWVB/qEXEbCc97nx7snRtMrRUYk5A54frzMfdxLSbwFOmhuld2uw83Dr +86A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765262987; x=1765867787; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :mime-version:subject:references:in-reply-to:message-id:to:from:date :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=XBEvy+e2z0BE9vXhFfF81MVx1kRhZ2M67JzG+fDYfaA=; b=g969XO3xnEsoHhxatKzHH/FagDypCa5CwXXue6C5FRttQg+GaFubazvAyTpMQtKkEr 5NAbMgy6Vk/rtuuf32AnVMRvvKEI0Z2uocKNWqre8rpIK/La3YI5uDijCU2lmXPlsWun fJOEw3RRGk9klI5fyaq6RDoRKWOGXOYVzw2IBK3tl/8omyJ6BwbSY4kY5nLErvvLptQb WcM8bMJTnqUGJt1K45DEpelE9ybv8YxNCZf4tc+qxSzt7v3UDSa9h7/0l2wzi7lXlGJ7 2IZJW3D2Pf8aPSnHuua5j63GUqqfvFMB3rsqeMZ+t+laCatkYChDb7+IwFuQU/aJoNKp wSqg== X-Forwarded-Encrypted: i=1; AJvYcCU4L0b2Sy5Ym74NarRXyVFDCpY72ifsZ01xw/ubul3qKgeXhURg5k40ne/tGWD1AkmRolx+QRxb1/f9@gnusha.org X-Gm-Message-State: AOJu0YwFe6cIqRgNXeHwDXpZMnYrIp0HkHkZ0BVgm9s0dlqxWemMHYKF gQN57nthw/iaBLd8EMWkXBDn7tGAJ9+dNpOaNGLxRw7suKAwg8iWVAPX X-Google-Smtp-Source: AGHT+IHXMo7ldvhzVuGPj5nq9DVg6Tx8xHpDZksYDLlD7E9TDxZZf8IfpuY5pghuLIzhI9BqgACL4A== X-Received: by 2002:a05:687c:201:b0:3e7:eee7:948f with SMTP id 586e51a60fabf-3f543e87b9emr3475798fac.9.1765262986757; Mon, 08 Dec 2025 22:49:46 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWZfECMnQACHkWvZlJC/bcUM1EP4b6/SGzjEzwSiY+0UqA==" Received: by 2002:a05:687c:51:10b0:3ec:461d:1e8f with SMTP id 586e51a60fabf-3f50903a87els2206115fac.2.-pod-prod-03-us; Mon, 08 Dec 2025 22:49:42 -0800 (PST) X-Received: by 2002:a05:6808:1924:b0:44f:8f27:e39a with SMTP id 5614622812f47-4539ded83fbmr3701593b6e.8.1765262982744; Mon, 08 Dec 2025 22:49:42 -0800 (PST) Received: by 2002:a05:690c:768f:b0:786:8d90:70d8 with SMTP id 00721157ae682-78c23b93f22ms7b3; Mon, 8 Dec 2025 21:08:04 -0800 (PST) X-Received: by 2002:a05:690e:4283:10b0:63c:e853:669d with SMTP id 956f58d0204a3-6444e7a916dmr6462223d50.50.1765256883466; Mon, 08 Dec 2025 21:08:03 -0800 (PST) Date: Mon, 8 Dec 2025 21:08:03 -0800 (PST) From: "'conduition' via Bitcoin Development Mailing List" To: Bitcoin Development Mailing List Message-Id: <0e2402c5-d593-49ff-b002-5ab348b46964n@googlegroups.com> In-Reply-To: References: <3e815d03-5e21-41ed-ba1a-4f9b2120a986n@googlegroups.com> Subject: Re: [bitcoindev] Hash-Based Signatures for Bitcoin's Post-Quantum Future MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_277674_2015083683.1765256883134" X-Original-Sender: conduition@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 (-) ------=_Part_277674_2015083683.1765256883134 Content-Type: multipart/alternative; boundary="----=_Part_277675_652322138.1765256883134" ------=_Part_277675_652322138.1765256883134 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Great work Jonas and Mikhail, glad to see more eyes and ears surveying=20 these schemes and their potential. Also shameless plug for some of my prior= =20 work on related topics=20 . The post-quantum HD wallet derivation problem is one i've been thinking=20 about a lot lately. Due to the lack of algebraic structure in SLH-DSA it's= =20 gonna be impossible to fully emulate BIP32 with that scheme alone. I'm=20 personally hoping that we'll find a way to derive child pubkeys using=20 lattices (ML-DSA) and/or isogenies (SQIsign), but I haven't heard of any=20 solid proposals yet. Currently reading on isogeny crypto as that sounds=20 like a promising candidate. If such a thing is possible, then we could derive BIP360 tap trees=20 containing a static SLH-DSA pubkey, alongside dynamically derived keys for= =20 a more structured algebraic PQ scheme like ML-DSA, and finally a regular EC= =20 BIP340 pubkey derived by regular BIP32. The idea being one could distribute= =20 a 'post quantum xpub' containing a regular BIP32 key extended with PQ=20 public keys. Wallets or 3rd parties could derive child addresses which=20 contain tap trees with one leaf per signing scheme. Since SLH-DSA doesn't= =20 support unhardened derivation, the SLH-DSA public key would have to be used= =20 as-is in every child leaf, without any derivation (maybe with an extra=20 pseudorandom nonce thrown in to avoid reusing the same tap leaf hash in=20 different TXs). Think of defining: CDKPub_slh(spx_pubkey, chaincode, n) := =3D=20 (spx_pubkey, HMAC(chaincode, n)) Regarding smaller signatures: I used to be a big fan of SPHINCS+C and=20 SPHINCS-=CE=B1 . I asked Andreas Hulsing,= the=20 SPHINCS+ team lead, why weren't these obviously better schemes standardized= =20 instead? he said NIST shied away from them because they complicated the=20 implementation for little material benefit. There were also "political"=20 considerations, owing to the fact that they were proposed late in the=20 standardization competition's timeline. Obviously bitcoin is a different=20 ballgame entirely, but the point is we should optimize where it matters=20 most. IMO that means smaller parameter set(s). Even without PoW=20 compression, hybercubes , or other modern= =20 tricks to optimize SLH-DSA, we can make sigs *much* smaller by just=20 tweaking constants, and we can do so *without* losing compatibility with=20 the NIST-compliant algorithm. So that idea has a big +1 from me. NIST is in= =20 the process of standardizing smaller parameter sets=20 but= =20 they have much higher signing/keygen perf overhead. If we want smaller=20 hash-based sigs, we should pick new parameter sets to standardize in=20 Bitcoin, covering different use cases, and use them with the standardized= =20 FIPS-205 algorithm. Agreeing on *which* parameter sets will be hard though.= =20 See https://github.com/chrisfenner/slh-dsa-rls I agree with Greg about the verification cost, you can't just consider=20 cycles/byte, you have to consider the cost of verifying entire blocks full= =20 of these signatures. While my recent research showed that SLH-DSA signing= =20 and keygen can be very effectively parallelized, verification is much=20 harder to parallelize. You have to parallelize generically across=20 signatures in a block (which can also be done with ECC, or any sig-verify= =20 algo for that matter).=20 On statefulness: I once felt quite strongly that we should have stateful=20 WOTS on-chain as an opcode - WOTS is pretty much the smallest hash-based=20 signatures you can get. But talking with Ethan and Hunter has since=20 convinced me that stateless sigs are the only way to go. There's just too= =20 many landmines and footguns to step on with schemes like WOTS, or even its= =20 big daddy XMSS, if you use them to sign non-deterministic data statefully.= =20 Finally, while everyone (including me) is really excited about hash-based= =20 signatures because we know and love and trust hash functions, in reality=20 the performance, functionality, and sig-size tradeoffs will lead to 99% of= =20 people using schemes with new assumptions like ML-DSA for everyday usage.= =20 Hash based sigs will be the worst-case scenario fallback, in case the more= =20 efficient schemes like ML-DSA or SQIsign turn out to be cryptographically= =20 broken (a real possibility, the feds have standardized broken schemes=20 before after all). > I don't think it matters much if signing is slow on low power devices --= =20 e.g. taking seconds per input.=20 It's far worse than that. Here are some benchmarks run by Trezor on their= =20 Model T signing device=20 . 75=20 seconds to create one SLH-DSA-SHA2-128s signature. RAM requirements are=20 quite low for SLH-DSA compared to ML-DSA which is nice. Apparently some of= =20 their newer devices have dedicated chips which can execute SHA256 much=20 faster than the ARM M4, but i haven't seen any benchmarks on those yet. I= =20 think those kinds of hash accelerators, or FPGAs etc, will need to become= =20 standard for hardware wallets if they plan to use SLH-DSA signing (or=20 keygen). I don't know about ledger, because they apparently don't think=20 quantum is a serious risk :/=20 regards, conduition On Monday, December 8, 2025 at 4:58:18=E2=80=AFPM UTC-5 Greg Maxwell wrote: > On Mon, Dec 8, 2025 at 8:47=E2=80=AFPM 'Mikhail Kudinov' via Bitcoin Deve= lopment=20 > Mailing List wrote: > >> We should not forget that for Bitcoin, it is important that the size of= =20 >> the public key plus the size of the signature remains small. Hash-based= =20 >> schemes have one of the smallest sizes of public keys, which can be arou= nd=20 >> 256 bits. For comparison, ML-DSA pk+sig size is at least 3732 bytes. >> > > No scheme has such a limitation, because any scheme can use a hash of the= =20 > underlying primitive as the public key-- which Bitcoin has done since day= =20 > one. The correct figure of merit is the the size of the signature, pubke= y,=20 > and a hash combined or-- if the pubkey is under 500 bits or so, just the= =20 > size of the signature plus pubkey. > =20 >> >> Verification cost per byte is comparable to current Schnorr signatures,= =20 >> alleviating concerns about blockchain validation overhead.=20 >> > > Though hash based signatures don't really concern me much in validation= =20 > costs, I disagree with the premise of this statement. If the size was=20 > similar then I'd agree that cost per byte being similar was enough to mak= e=20 > validation costs not a concern, but the size is some 40 times larger and= =20 > 40x validation costs is certainly a concern unless the scheme is deployed= =20 > without an effective increase in block capacity-- and without a capacity= =20 > increase the utility of such large signatures is potentially pretty=20 > dubious. Even if a proposal doesn't itself include a capacity increase= =20 > one should be regarded as inevitable along with it, particularly because= =20 > just securing *your* coins against this attack won't do you any good if 9= 5%=20 > of all other coins get stolen by it-- so a performance analysis should=20 > anticipate needing the capacity for all of the transaction flow to use th= e=20 > scheme, even if that isn't the case for the initial usage. > > One of the key design decisions for Bitcoin is whether to rely exclusivel= y=20 >> on stateless schemes (where the secret key need not be updated for each= =20 >> signature) or whether stateful schemes could be viable. Stateful schemes= =20 >> introduce operational complexity in key management but can offer better= =20 >> performance. >> > > It's not an either/or, I believe. I think schemes with weakened stateless= =20 > security could be improved to ~full repeated use security via statefulnes= s=20 > (e.g. grinding the message to avoid revealing signatures that leak key=20 > material). There may be possibilities for other hybrids: an otherwise=20 > stateless wallet which is assumed to have visibility to its own confirmed= =20 > transactions. It may be that a 'few time secure' scheme could be adequat= e=20 > when coupled with best effort statefulness (e.g. blockchain visibility) = =20 > and a series composed schnorr signature (which means the brittleness of t= he=20 > hash signature only matters if the schnorr signature is broken). > > Statefulness is not a great assumption with how bitcoin private keys work= ,=20 > particularly for cold storage. Especially since key loss is usually the= =20 > greatest risk to coin possession and the best mechanism against key loss = is=20 > duplicate copies separately stored. Although correct usage of bitcoin= =20 > results in keys being single use or nearly so, it's a security footgun to= =20 > make a strong assumption. > > If we look at multi/distributed/threshold-signatures, we find that curren= t=20 >> approaches either don't give much gains compared to plain usage of multi= ple=20 >> signatures, or require a trusted dealer, which drastically limits the=20 >> use-cases.=20 >> > > There may be advantages there to using a threshold schnorr in series with= =20 > a single PQ scheme, in that case the security model is "a threshold of= =20 > participants must agree OR a participant must agree and have a successful= =20 > attack on the threshold schnorr signature". This may well be a reasonabl= e=20 > compromise considering the costs of multiple PQ keys-- particularly when= =20 > the participants are known entities and not e.g. an anonymous channel=20 > counterparty. > > 1) What are the concrete performance requirements across various hardware= ,=20 >> including low-power devices? >> > > I don't think it matters much if signing is slow on low power devices --= =20 > e.g. taking seconds per input. It would obviously matter to *some* users= =20 > but those users could use higher power signing devices. The minimum amou= nt=20 > of dynamic ram needed for signing (even at low performance) is probably= =20 > pretty important. > > 2) Should multiple schemes with different signature limits be standardize= d? >> 3) Is there value in supporting stateful schemes alongside stateless one= s? > > > Depends on their relative costs. Plain stateful (of the 'two signatures= =20 > breaks your security' sort) is a very concerning footgun with bad side=20 > effects (e.g. can't even bump fees) but even that could be attractive if= =20 > the size is much smaller. Having a totally free configuration is quite= =20 > bad for privacy, however, and of dubious value. I think that just havin= g=20 > two options, e.g. secure for 'few' and secure for 'many' (but no need for= =20 > 2^128) with both supporting but not requiring statefulness as a best effo= rt=20 > hail-mary protection against self-compromise might be interesting, but it= =20 > would depend on their relative performance. One possibility would be to= =20 > just always have both alternatives available (at a cost of 32 bytes) and= =20 > for the user to decide at signing time. =20 > > =20 > > > --=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/= 0e2402c5-d593-49ff-b002-5ab348b46964n%40googlegroups.com. ------=_Part_277675_652322138.1765256883134 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Great work Jonas and Mikhail, glad to see more eyes and ears surveying thes= e schemes and their potential. Also shameless plug for some of my prior work on related topics.

The post-quantum HD wallet derivation problem is one i've been= thinking about a lot lately. Due to the lack of algebraic structure in SLH= -DSA it's gonna be impossible to fully emulate BIP32 with that scheme alone= . I'm personally hoping that we'll find a way to derive child pubkeys using= lattices (ML-DSA) and/or isogenies (SQIsign), but I haven't heard of any s= olid proposals yet. Currently reading on isogeny crypto as that sounds like= a promising candidate.

If such a thing is possi= ble, then we could derive BIP360 tap trees containing a static SLH-DSA pubk= ey, alongside dynamically derived keys for a more structured algebraic PQ s= cheme like ML-DSA, and finally a regular EC BIP340 pubkey derived by regula= r BIP32. The idea being one could distribute a 'post quantum xpub' containi= ng a regular BIP32 key extended with PQ public keys. Wallets or 3rd parties= could derive child addresses which contain tap trees with one leaf per sig= ning scheme. Since SLH-DSA doesn't support unhardened derivation, the SLH-D= SA public key would have to be used as-is in every child leaf, without any = derivation (maybe with an extra pseudorandom nonce thrown in to avoid reusi= ng the same tap leaf hash in different TXs). Think of defining: CDKPub_slh(= spx_pubkey, chaincode, n) :=3D (spx_pubkey, HMAC(chaincode, n))
<= br />
Regarding smaller signatures: I used to be a big fan of SPH= INCS+C and SPHINCS-=CE=B1.= I asked Andreas Hulsing, the SPHINCS+ team lead, why weren't these obvious= ly better schemes standardized instead? he said NIST shied away from them b= ecause they complicated the implementation for little material benefit. The= re were also "political" considerations, owing to the fact that they were p= roposed late in the standardization competition's timeline. Obviously bitco= in is a different ballgame entirely, but the point is we should optimize wh= ere it matters most. IMO that means smaller parameter set(s). Even without = PoW compression, hybercubes, or other modern tricks to optimize SLH-DSA, we can make sigs much= smaller by just tweaking constants, and we can do so without=C2=A0l= osing compatibility with the NIST-compliant algorithm. So that idea has a b= ig +1 from me. NIST is in the process of standardizing smaller paramet= er sets but they have much higher signing/keygen perf overhead. If we w= ant smaller hash-based sigs, we should pick new parameter sets to standardi= ze in Bitcoin, covering different use cases, and use them with the standard= ized FIPS-205 algorithm. Agreeing on which=C2=A0parameter sets will = be hard though. See=C2=A0https://github.com/chrisfenner/slh-dsa-rls

<= div>I agree with Greg about the verification cost, you can't just consider = cycles/byte, you have to consider the cost of verifying entire blocks full = of these signatures. While my recent research showed that SLH-DSA signing a= nd keygen can be very effectively parallelized, verification is much harder= to parallelize. You have to parallelize generically across signatures in a= block (which can also be done with ECC, or any sig-verify algo for that ma= tter).=C2=A0

On statefulness: I once felt quite = strongly that we should have stateful WOTS on-chain as an opcode - WOTS is = pretty much the smallest hash-based signatures you can get. But talking wit= h Ethan and Hunter has since convinced me that stateless sigs are the only = way to go. There's just too many landmines and footguns to step on with sch= emes like WOTS, or even its big daddy XMSS, if you use them to sign non-det= erministic data statefully.=C2=A0

Finally, while= everyone (including me) is really excited about hash-based signatures beca= use we know and love and trust hash functions, in reality the performance, = functionality, and sig-size tradeoffs will lead to 99% of people using sche= mes with new assumptions like ML-DSA for everyday usage. Hash based sigs wi= ll be the worst-case scenario fallback, in case the more efficient schemes = like ML-DSA or SQIsign turn out to be cryptographically broken (a real poss= ibility, the feds have standardized broken schemes before after all).
=

> I don't think it matters much if signing is slow= on low power devices -- e.g. taking seconds per input.=C2=A0
It's far worse than that. Here are some benchmarks ru= n by Trezor on their Model T signing device. 75 seconds to create one S= LH-DSA-SHA2-128s signature. RAM requirements are quite low for SLH-DSA comp= ared to ML-DSA which is nice. Apparently some of their newer devices have d= edicated chips which can execute SHA256 much faster than the ARM M4, but i = haven't seen any benchmarks on those yet. I think those kinds of hash accel= erators, or FPGAs etc, will need to become standard for hardware wallets if= they plan to use SLH-DSA signing (or keygen). I don't know about ledger, b= ecause they apparently don't think quantum is a serious risk :/=C2=A0
=


regards,
conduition<= /div>

On Monday, December 8, 2025 at 4:58:18=E2=80=AFPM UTC-5 Greg M= axwell wrote:
On Mon, Dec 8, 2025 at 8:47=E2=80=AFPM &= #39;Mikhail Kudinov' via Bitcoin Development Mailing List <bitco...@googlegroups.com> wrote:<= /div>
We should not forget that for Bitcoin, it is = important that the size of the public key plus the size of the signature re= mains small. Hash-based schemes have one of the smallest sizes of public ke= ys, which can be around 256 bits. For comparison, ML-DSA pk+sig size is at = least 3732 bytes.

No scheme has such a limitation, because= any scheme can use a hash of the underlying primitive=C2=A0as the public k= ey-- which Bitcoin has done since day one.=C2=A0 The correct figure of meri= t is the the size of the signature, pubkey, and a hash combined=C2=A0 or-- = if the pubkey is under 500 bits or so, just the size of the signature plus = pubkey.
=C2=A0=
Verification cost per byt= e is comparable to current Schnorr signatures, alleviating concerns about b= lockchain validation overhead.=C2=A0

<= /div>
Though hash based sig= natures don't really concern me much in validation costs, I disagree wi= th the premise of this statement.=C2=A0 If the size was similar then I'= d agree that cost per byte being similar was enough to make validation cost= s not a concern, but the size is some 40 times larger and 40x validation co= sts is certainly a concern unless the scheme is deployed without an effecti= ve increase in block capacity-- and without a capacity increase the utility= of such large signatures is potentially pretty dubious.=C2=A0 =C2=A0Even i= f a proposal doesn't itself include a capacity increase one should be r= egarded as inevitable along with it,=C2=A0 particularly because just securi= ng *your* coins against this attack won't do you any good if 95% of all= other coins get stolen by it-- so a performance analysis should anticipate= needing the capacity for all of the transaction flow to use the scheme, ev= en if that isn't the case for the initial usage.

One of the key design decisions for Bitcoin is= whether to rely exclusively on stateless schemes (where the secret key nee= d not be updated for each signature) or whether stateful schemes could be v= iable. Stateful schemes introduce operational complexity in key management = but can offer better performance.

It's not an either/o= r, I believe. I think schemes with weakened=C2=A0stateless security could b= e improved to ~full repeated use security via statefulness (e.g. grinding t= he message to avoid revealing signatures that leak key material).=C2=A0 The= re may be possibilities for other hybrids: an otherwise stateless wallet wh= ich is assumed to have visibility to its own confirmed transactions.=C2=A0 = It may be that a 'few time secure' scheme could be adequate when co= upled with best effort statefulness (e.g. blockchain visibility)=C2=A0 and = a series composed schnorr signature (which means the brittleness of the has= h signature only matters if the schnorr signature is broken).
Statefulness is not a great assumption with how bitcoin private= keys work, particularly for cold storage.=C2=A0 =C2=A0Especially since key= loss is usually the greatest risk to coin possession and the best mechanis= m against key loss is duplicate copies separately stored.=C2=A0 =C2=A0Altho= ugh correct usage of bitcoin results in keys being single use or nearly so,= it's a security footgun to make a strong assumption.
=

If we look at multi/distributed/threshold= -signatures, we find that current approaches either don't give much gai= ns compared to plain usage of multiple signatures, or require a trusted dea= ler, which drastically limits the use-cases.=C2=A0
There m= ay be advantages there to using a threshold schnorr in series with a single= PQ scheme,=C2=A0 in that case the security model is "a threshold of p= articipants must agree OR a participant must agree and have a successful at= tack on the threshold schnorr signature".=C2=A0 This may well be a rea= sonable compromise considering the costs of multiple PQ keys-- particularly= when the participants are known entities and not e.g. an anonymous channel= counterparty.

1) What a= re the concrete performance requirements across various hardware, including= low-power devices?

I don't think it matters much if s= igning is slow on low power devices -- e.g. taking seconds per input.=C2=A0= It would obviously matter to *some* users but those users could use higher= power signing devices.=C2=A0 The minimum amount of dynamic ram needed for = signing (even at low performance) is probably pretty important.
=

2) Should multiple schemes with dif= ferent signature limits be standardized?
3) Is there value in supporting= stateful schemes alongside stateless ones?

Depends on their r= elative costs.=C2=A0 Plain stateful (of the 'two signatures breaks your= security' sort) is a very concerning footgun with bad side effects (e.= g. can't even bump fees) but even that could be attractive if the size = is much smaller.=C2=A0 =C2=A0 Having a totally free configuration is quite = bad for privacy, however, and of dubious value.=C2=A0 =C2=A0I think that ju= st having two options, e.g. secure for 'few' and secure for 'ma= ny' (but no need for 2^128) with both supporting but not requiring stat= efulness as a best effort hail-mary protection against self-compromise migh= t be interesting, but it would depend on their relative performance.=C2=A0 = One possibility=C2=A0would be to just always have both alternatives availab= le (at a cost of 32 bytes) and for the user to decide at signing time.=C2= =A0=C2=A0

=C2=A0


--
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/0e2402c5-d593-49ff-b002-5ab348b46964n%40googlegroups.com.
------=_Part_277675_652322138.1765256883134-- ------=_Part_277674_2015083683.1765256883134--