From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 08 Dec 2025 13:58:25 -0800 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 1vSjFQ-0004O8-Kf for bitcoindev@gnusha.org; Mon, 08 Dec 2025 13:58:25 -0800 Received: by mail-oa1-f62.google.com with SMTP id 586e51a60fabf-3e88192e178sf3268032fac.1 for ; Mon, 08 Dec 2025 13:58:24 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1765231098; cv=pass; d=google.com; s=arc-20240605; b=UOxfO8vx6d35AF2pswvLJQb0F50/pqsYpCpdyMgT5O5qjDYauGtwR8As8ouxAPKxtj Ipt53KnLdzLnyn3LipMmI/IF7R0ge6/QV2tUaugSmq37HpQ19LWmbSDewI8/GCk99/F7 xYJtyDUnmeGb3lU/UnvCLNfdCB92jxvk7rjYbFWFhIpo8F0UOid1UZS/9DWP3yuYarg+ +6zi+O1jfxM40hQCGkFtbSJkUXq5REec1ML+NgecVGpdItevnJVkTFsdodZnKUyK9R3L pOcQ9BhxGabppdqtQsij3CWaV3G4fhD3s1Md2tBkh93b6S7cbj3uC6VUjeA1o8VO7e62 nPcA== ARC-Message-Signature: i=2; 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=VX3zcuuU2WwZUPKIZgYakOTCSasstwqdjpTiN8X/uvI=; fh=tgrP5NWh9FvDItVyAd/LDSoFDOREfAvqJaNWzrhQTGI=; b=WYyOFoSRCY1foSoSDD3hwx4PUrSin4dqZYt7ab7fQHgA25udLjkZwrxAbtVFcDL5mP GKrBdaswhtHgQmISVQ0SRbUARD+h+PP3FkKwZoNcX1O3m+cSNL8Z9MAYK2YIkrDc2MJg lNS5HTT3TWENnmAk3jWXfIGmuG2NrH/keznVevmw21PaYOj0v0fHBY4ohEIwMfidut/A FAsYZXEUtm/VSvKSaS1+tR6A6+bnVn0kEXN26/Y3KWSRCdDw97Vb6sIlxfL5mU6xZK8Z IW/y+EQtJQR3jRsVLImn7Z3tsqKeGMqDYy6kMgQfnoHGSp7cDItzwEfUCZuNrcCRJXkG CiKw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=FygWonCR; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::434 as permitted sender) smtp.mailfrom=gmaxwell@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=20230601; t=1765231098; x=1765835898; 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=VX3zcuuU2WwZUPKIZgYakOTCSasstwqdjpTiN8X/uvI=; b=ComwkX5LE/EbQQyElq2q3XWgR5SpjAukxqF2MH4ZQTmnZ2XCBPrSQhCArQHDcRrgjc b+FOcdjohXvJvhwckcxbgo4t+5O4TtN0of50f13qyf68RhGVn+eGWscwlt+W/Kz3/qEI ZNie4Arv5fGfTXQBwl/wu2F5SBxeTICy3zr+GBuM0smUpkaNkICRBjjWnT//1esSUtxc OU2mAcffSJ4Lvthz1xVoRTX1A30US7qfLxNRZ9dKp105l64DlyXxUQEfnW2SDFLa3TCu UgmzQgsoH9hAOOPKI0O1gWe6lFK+cRk8gu4Ek+ivBeC0KDxiaLx7ewekFCJZTGrWsWlo USNw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765231098; x=1765835898; 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=VX3zcuuU2WwZUPKIZgYakOTCSasstwqdjpTiN8X/uvI=; b=RmKDqG8cdnMoglfOMSokc8GZC2d5Z/XH0whmG7890fsiMMK2fig9hsdOTvtntSbZGF wRmZVjRxPNCZaw5md6oY+NlivR592Et8j0Qez2Snypjnhx7hSq4ZP7NEwSann46AJ8cV vRNH7vTfBV/C7cHMBOlV0WVNQNonm4FP/kjonXUpH1OAN2Nkv2ucBFDFinTWlj0oAmjQ dIP2MXekFc8HU4iiR8SKGr94cq8lFKFLIAlGnfpICfYvxFyVy9GF7hWRUp/F01BXbGf6 gI0fu+WeIrBfWAmTUhCHw48Cp43HvrzPqTxd+mZC1Z0WGR6gA8Yqa7aYnBNnlP6giman bSJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765231098; x=1765835898; 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=VX3zcuuU2WwZUPKIZgYakOTCSasstwqdjpTiN8X/uvI=; b=IBd7EWY/I7CIf7BIT2barPgB0A9koM6iI5DkAyGDrRilrrw7tJdrtEUskd0wVnHsrQ f++Gs6HAC2ImNivxIKvVmxO34brXY42f2F8a1xle4GmIFtRKMD2tY56yICr43qCIdbkr W+3F0d7Q6P+uPVJ0rbcexI7E9LsNj6evirVC5XUlwIGR4rM90GxKKt77EC/uj0lMzk8G ZuwgoM3ZRFc52Ee+6Khd7xdBOWKb9WJDrXZnzHFu+VT8eGTt4/yPXkDzFec6wt0zp+8s 4F+iVfiwtkNmPyDslyfH2Tm2flxhe3g1NJ4huQIwJp8PtnVeN+bU4Lbd2OXnjoAzrkCw leDg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCXA72I1tW+YerMmoNDIV36hmeG/0xl5Q3LdgHC2ecAT4Zef4X23GsQLmAEHl6u8h/59H6w+WRCM7YLQ@gnusha.org X-Gm-Message-State: AOJu0YzbiHFqtt6ItMQY2xdgxo6VSm4ACVmC9RFXrwTdK/wwX4vdi3tn C0An7o5E8noHEkUdclijC3SmtqysqNJa1thawH3guEWqViQ4HZR4lMcC X-Google-Smtp-Source: AGHT+IFw1meI4dHd971LqhLKnpKE7oxeoKT0oWg+7TZEeT+J0G5biZmhroWGAPEQhkXinWgL3ckJSA== X-Received: by 2002:a05:6870:d623:b0:3e8:8e57:a7ab with SMTP id 586e51a60fabf-3f544156e1dmr4211151fac.54.1765231097931; Mon, 08 Dec 2025 13:58:17 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWa9Vx4yhzc4UUMV6DBeSTbqYgvZ4HPlkgpSEKQ/i1th9A==" Received: by 2002:a05:6871:7c17:b0:3d4:d703:74d7 with SMTP id 586e51a60fabf-3f508ac9c7dls2521087fac.0.-pod-prod-02-us; Mon, 08 Dec 2025 13:58:13 -0800 (PST) X-Received: by 2002:a05:6808:c16f:b0:451:551:c0b with SMTP id 5614622812f47-4539ded84a9mr3429762b6e.8.1765231092877; Mon, 08 Dec 2025 13:58:12 -0800 (PST) Received: by 2002:ae9:e315:0:b0:8b2:e00e:5a07 with SMTP id af79cd13be357-8b618792469ms85a; Mon, 8 Dec 2025 13:50:44 -0800 (PST) X-Received: by 2002:a05:622a:1452:b0:4ee:232e:4958 with SMTP id d75a77b69052e-4f03fdf4ae3mr141803011cf.21.1765230643723; Mon, 08 Dec 2025 13:50:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1765230643; cv=none; d=google.com; s=arc-20240605; b=SC9F/w0aUTHcuVwjmgp0eLFDAQoAW96NUpkZ8zqpr2jdNJLYDtCj9o6SbqSlUIlYgQ bVfhmp3ldAfEexSkXIo4HxkZI0dpaZV/OcrWy5AHeL5a19Q+ZaJ0MheHliUDVH9OD8qD GrQWlwKPKKc2wMO+Gd/ZlokrWPhmvKb3Fi9nC41k8vgaP9G39DdZRFPQbOlLol9MMpXj AlpezMwNVBa9N9qCP/T+ADCgHjRVXEFGuVU2ZPdHhes6NwSieyhyh5i2wz3R9hmFJ6lx Auv8toVk+2kjGADyMweTxzbdZ2h0Oz6X8/C5yTwBr+efVX3zoVeRC+LQ9UdVvP/d8Xr/ wLQQ== 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=CZrk6sSe/XB7pOkuTvLXGUPV2e1qeqxTR8HFmKEUnEM=; fh=/zmrS9FM2GAs10vo8ni5olLyTDY7XS+kGYSZSd0r2OQ=; b=SdsR6gZtGkfTD9DXHv1UCsAIlSWj1g1LjxiALPCPhBk/5aKl7zRMUYIfvF4xuR9sbL 0LNloAG8VWlgGw5fmtpTRvXL+EDDk6UQEEei1oPVmZmObhgxbo1En9iXEIqgkRuvLT5a IcAJ6tlP2a+OtTf50y4YmZao4mU4cjBQ2Y+BfvAoZT7086bphUs7/zZfm2gnJB4IrTXO 5NTgGHCIvCltZzadrQUSQVcvZmABWEfbx8SXiChIJIQskgENhf4Mw0a+MKbSADa7V/7G 59szVA+ByXBbjMNCfwb9+SvSxrGOKFprAwmZJVvcmPr8QCzFqhf7eJwHyl1z3xO9hEaf 8FqA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=FygWonCR; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::434 as permitted sender) smtp.mailfrom=gmaxwell@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com. [2607:f8b0:4864:20::434]) by gmr-mx.google.com with ESMTPS id 6a1803df08f44-88827ed3898si6367436d6.2.2025.12.08.13.50.43 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Dec 2025 13:50:43 -0800 (PST) Received-SPF: pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::434 as permitted sender) client-ip=2607:f8b0:4864:20::434; Received: by mail-pf1-x434.google.com with SMTP id d2e1a72fcca58-7b86e0d9615so8451525b3a.0 for ; Mon, 08 Dec 2025 13:50:43 -0800 (PST) X-Gm-Gg: ASbGncvT5bB34EuPV09ztR6ImSHMxSiWwyl0HPEpwkBScVlyn+/51AOQi55PeQsLfLH aJc4HtBx2d5LxMZddj9f4qdiYOVso7vPIQBwmH1ZcGCSai62OQLsLRQzHJdvqDTtJ0mdXspoW1h zT6/CbX1FAk/wwXBYrNCmRxr0R9l9abHdLXefca0RDUvxp1R7Lvtjw6T7K0c3TwN0xuag7txtBb abIiBlSBuU8U6eOTswZMbDmpQWwmRKUs07cEtVh6ybzHA9DKMHB/RhFeU9CwgLHKG8GY6NrNsHB 4J3u1++a1UxYUogPgsH/9SxMa9VctujU3SzaFP22niv5oitgFjE= X-Received: by 2002:a05:7022:1b05:b0:11a:b04b:3c2e with SMTP id a92af1059eb24-11e0329c23cmr5957994c88.29.1765230642888; Mon, 08 Dec 2025 13:50:42 -0800 (PST) MIME-Version: 1.0 References: <3e815d03-5e21-41ed-ba1a-4f9b2120a986n@googlegroups.com> In-Reply-To: <3e815d03-5e21-41ed-ba1a-4f9b2120a986n@googlegroups.com> From: Greg Maxwell Date: Mon, 8 Dec 2025 21:50:31 +0000 X-Gm-Features: AQt7F2oBbMsNAV5WAFygnS0tpHOfFaFaKKDDzEt3hTyrORdWMbTn86K8kyfLIB8 Message-ID: Subject: Re: [bitcoindev] Hash-Based Signatures for Bitcoin's Post-Quantum Future To: Mikhail Kudinov Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000006a82ea064577c9d3" X-Original-Sender: gmaxwell@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=FygWonCR; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::434 as permitted sender) smtp.mailfrom=gmaxwell@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 (/) --0000000000006a82ea064577c9d3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Dec 8, 2025 at 8:47=E2=80=AFPM 'Mikhail Kudinov' via Bitcoin Develo= pment Mailing List wrote: > We should not forget that for Bitcoin, it is important that the size of > the public key plus the size of the signature remains small. Hash-based > schemes have one of the smallest sizes of public keys, which can be aroun= d > 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 as the public key-- which Bitcoin has done since day one. The correct figure of merit is the the size of the signature, pubkey, and a hash combined or-- if the pubkey is under 500 bits or so, just the size of the signature plus pubkey. > > Verification cost per byte is comparable to current Schnorr signatures, > alleviating concerns about blockchain validation overhead. > Though hash based signatures don't really concern me much in validation costs, I disagree with the premise of this statement. If the size was similar then I'd agree that cost per byte being similar was enough to make validation costs not a concern, but the size is some 40 times larger and 40x validation costs is certainly a concern unless the scheme is deployed without an effective increase in block capacity-- and without a capacity increase the utility of such large signatures is potentially pretty dubious. Even if a proposal doesn't itself include a capacity increase one should be regarded as inevitable along with it, particularly because just securing *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, even 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 need not be updated for each > signature) or whether stateful schemes could be viable. Stateful schemes > introduce operational complexity in key management but can offer better > performance. > It's not an either/or, I believe. I think schemes with weakened stateless security could be improved to ~full repeated use security via statefulness (e.g. grinding the message to avoid revealing signatures that leak key material). There may be possibilities for other hybrids: an otherwise stateless wallet which is assumed to have visibility to its own confirmed transactions. It may be that a 'few time secure' scheme could be adequate when coupled with best effort statefulness (e.g. blockchain visibility) and a series composed schnorr signature (which means the brittleness of the hash 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. Especially since key loss is usually the greatest risk to coin possession and the best mechanism against key loss is duplicate copies separately stored. Although 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 gains compared to plain usage of multip= le > signatures, or require a trusted dealer, which drastically limits the > use-cases. > There may be advantages there to using a threshold schnorr in series with a single PQ scheme, in that case the security model is "a threshold of participants must agree OR a participant must agree and have a successful attack on the threshold schnorr signature". This may well be a reasonable 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 are the concrete performance requirements across various hardware, > including low-power devices? > I don't think it matters much if signing is slow on low power devices -- e.g. taking seconds per input. It would obviously matter to *some* users but those users could use higher power signing devices. The minimum amount of dynamic ram needed for signing (even at low performance) is probably pretty important. 2) Should multiple schemes with different signature limits be standardized? > 3) Is there value in supporting stateful schemes alongside stateless ones= ? Depends on their relative costs. 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. Having a totally free configuration is quite bad for privacy, however, and of dubious value. I think that just having two options, e.g. secure for 'few' and secure for 'many' (but no need for 2^128) with both supporting but not requiring statefulness as a best effort hail-mary protection against self-compromise might be interesting, but it would depend on their relative performance. One possibility would be to just always have both alternatives available (at a cost of 32 bytes) and for the user to decide at signing time. --=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/= CAAS2fgSrGz1-ShUfhx_-jZm_W__ZBquMLbVGQriCYS6khfV46Q%40mail.gmail.com. --0000000000006a82ea064577c9d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Dec 8, 2025 at 8:47=E2=80=AFPM &#= 39;Mikhail Kudinov' via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> wr= ote:
We should not forget that for Bitcoin, it= is important that the size of the public key plus the size of the signatur= e remains small. Hash-based schemes have one of the smallest sizes of publi= c keys, which can be around 256 bits. For comparison, ML-DSA pk+sig size is= at least 3732 bytes.

No scheme has suc= h a limitation, because any scheme can use a hash of the underlying primiti= ve=C2=A0as the public key-- which Bitcoin has done since day one.=C2=A0 The= correct figure of merit is the the size of the signature, pubkey, and a ha= sh 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 byte is comparable to current Schnor= r signatures, alleviating concerns about blockchain validation overhead.=C2= =A0

Though hash based signatures don= 9;t really concern me much in validation costs, I disagree with the premise= of this statement.=C2=A0 If the size was similar then I'd agree that c= ost per byte being similar was enough to make validation costs not a concer= n, but the size is some 40 times larger and 40x validation costs is certain= ly a concern unless the scheme is deployed without an effective increase in= block capacity-- and without a capacity increase the utility of such large= signatures is potentially pretty dubious.=C2=A0 =C2=A0Even if a proposal d= oesn't itself include a capacity increase one should be regarded as ine= vitable along with it,=C2=A0 particularly because just securing *your* coin= s against this attack won't do you any good if 95% of all other coins g= et stolen by it-- so a performance analysis should anticipate needing the c= apacity for all of the transaction flow to use the scheme, even if that isn= 't the case for the initial usage.

One of the key design decisions for Bitco= in is whether to rely exclusively on stateless schemes (where the secret ke= y need not be updated for each signature) or whether stateful schemes could= be viable. Stateful schemes introduce operational complexity in key manage= ment but can offer better performance.

= It's not an either/or, I believe. I think schemes with weakened=C2=A0st= ateless security could be improved to ~full repeated use security via state= fulness (e.g. grinding the message to avoid revealing signatures that leak = key material).=C2=A0 There may be possibilities for other hybrids: an other= wise stateless wallet which is assumed to have visibility to its own confir= med transactions.=C2=A0 It may be that a 'few time secure' scheme c= ould be adequate when coupled with best effort statefulness (e.g. blockchai= n visibility)=C2=A0 and a series composed schnorr signature (which means th= e brittleness of the hash signature only matters if the schnorr signature i= s 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 posses= sion and the best mechanism against key loss is duplicate copies separately= stored.=C2=A0 =C2=A0Although correct usage of bitcoin results in keys bein= g single use or nearly so, it's a security footgun to make a strong ass= umption.

If we look at multi/distributed/threshold-signatures, we find that curr= ent approaches either don't give much gains compared to plain usage of = multiple signatures, or require a trusted dealer, which drastically limits = the use-cases.=C2=A0

There may be advan= tages 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 participants= must agree OR a participant must agree and have a successful attack on the= threshold schnorr signature".=C2=A0 This may well be a reasonable com= promise considering the costs of multiple PQ keys-- particularly when the p= articipants are known entities and not e.g. an anonymous channel counterpar= ty.

1= ) What are the concrete performance requirements across various hardware, i= ncluding low-power devices?

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

2) Should multiple schemes with different signature limits be st= andardized?
3) Is there value in supporting stateful schemes alongside s= tateless ones?

Depends on their relative co= sts.=C2=A0 Plain stateful (of the 'two signatures breaks your security&= #39; 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 sm= aller.=C2=A0 =C2=A0 Having a totally free configuration is quite bad for pr= ivacy, however, and of dubious value.=C2=A0 =C2=A0I think that just having = two options, e.g. secure for 'few' and secure for 'many' (b= ut no need for 2^128) with both supporting but not requiring statefulness a= s a best effort hail-mary protection against self-compromise might be inter= esting, but it would depend on their relative performance.=C2=A0 One possib= ility=C2=A0would be to just always have both alternatives available (at a c= ost 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/ms= gid/bitcoindev/CAAS2fgSrGz1-ShUfhx_-jZm_W__ZBquMLbVGQriCYS6khfV46Q%40mail.g= mail.com.
--0000000000006a82ea064577c9d3--