From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 27 Feb 2025 18:41:15 -0800 Received: from mail-oo1-f57.google.com ([209.85.161.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tnqJN-0004qj-Oa for bitcoindev@gnusha.org; Thu, 27 Feb 2025 18:41:15 -0800 Received: by mail-oo1-f57.google.com with SMTP id 006d021491bc7-5fcf2505ee7sf1744734eaf.0 for ; Thu, 27 Feb 2025 18:41:13 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1740710468; cv=pass; d=google.com; s=arc-20240605; b=dYnXsqz+3a2cCExZQ0OtO4BpRVHuUhdrLSU64KgfD7sDKrMvtRQTCx2j/69SBpSMjz SWCxbyAVqxg/qf0MBVS1qFhQTfUPPAg6jm13Es4PK7BdBlDgBTYfkX34oTsbTf4zdanp Zf7LMKksnqJmuaTKIohqnbHKsf6NojyLu7eGeItoHgsvXkzj9GFJv5YZeZ0N/GEXQ9wV ytUXOj/vSeF2ZfNDaj50KFpUPH9zK+XVx1WE1zFNM90rdp6RuhUaqyo9b6QhDMEueUA4 I1NBqZYaqtaxDbRRBKMYE4N/uwP/Pb0q23Nubki49sRzJfMYTfXh4+PSD7/VUeOryjTs 0RiA== 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:content-transfer-encoding :in-reply-to:from:content-language:references:to:subject :mime-version:date:message-id:sender:dkim-signature; bh=O5qEtPozExPjl+q7xBE2d15BQgmXDQ64KQBxjoLsHlw=; fh=W06NSZMj5JwFrvyR0fGvME8v8Wkt3aam2+MxEZLQ+Bo=; b=J/5Ih9f7G6c7tYhZkoxoLdUli5aHvkDpfIZZ1gzmGB6xcBSwpDoZO6pXhKF2dH1jcM ddVkApbZgs919dbakk/aoOsGjSWD1Pe9rXUaaA8eviJeHZjYb4ZXuORMgiIDVfxFJOJG RB+6R+iXMc+VVSW8VuzwtwGgDnD83vuneji22qJahix3eBPMdfBIq0hmfI+bLZY/wEEp 25mPRVyxwTpOyzNon/OhfEqvIu67BHCbR99sH4YWgjA1iTytVlg0YASEgdlyHcHCes54 sKmFCJShRwxV0NnZlvH6x/6oiaxQ8rUphrn1xH8ZSLH2VlgxJpnVv0Rd4P4zK+yEWlCo wb1g==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1740595262 header.b=jfVGfC7X; dkim=pass header.i=@clients.mail.as397444.net header.s=1740595265 header.b=hWtyFmlA; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1740710468; x=1741315268; 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:content-transfer-encoding:in-reply-to:from :content-language:references:to:subject:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=O5qEtPozExPjl+q7xBE2d15BQgmXDQ64KQBxjoLsHlw=; b=Gdw+ISnZOQIVdVUqNnqgs+FItqSx64pz89xj3IJIlSC0IE25rQ7Be6NtVJ64eZUXMa 2US7tAo9BOA0LHWStcuSxPp/zrzzikwHZ1yqf70XSUq/oyCsSV71U2vhPlBwwZK5Ee0/ A0tE+VAEAc8QXt+wEkk4RRxem1cGdXbMvtWj4hmaqDUws/FgdH2VYsssvEj9OYY3nagY s+5bSeI0IouvSnlTwy9SORk1AaS+IrLN80Pp+3l4joyiLjwIPSzy4i+w8nfmbPVJ3JzU DakaUF5SasQ/32SKH8/+XjmN4wGmog3rNoE1sTf+pX0PIUiFRvadsdDXLQLS5etv/qTV OV5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740710468; x=1741315268; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:in-reply-to:from :content-language:references:to:subject:mime-version:date:message-id :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date :message-id:reply-to; bh=O5qEtPozExPjl+q7xBE2d15BQgmXDQ64KQBxjoLsHlw=; b=cwTSH2eEvoF/l2V5ik3k6HpMDjgYiHqrJBmdPCVR/KMCU3Py5tAZrri5Tl71rmeJNY p79n0vDtR0L/RIa1A7sjTtA1zm2jnPDcWeSm8OQouO1hoYJIfy8WnE67D1cfTdntfuSw ZLrk5MhJTc/RWDFBmkFjbOY17PcoDT3lpCvlW/9lBvMSBuWBNmNDHU1s+0rO96JtOAst Y4+auqzEhO9txiUS6S4TqVCNG1kpZ7UZ/1rUVw6CdGLt/QCgxyqLGfdrjr1zz7kCNVsN JuO3oUhYVeVSiXK5tBN4lSWeVkdV7+Wr+wolP05LqrYksa2/Ky7aCHc91fTA3BHl7kjc DLTw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCXCIWBVmwtQWli4U4xJr3GsThDTC26wh3c+duwK7lJR2EbQrXUbSRZMAVbL2zxSbYrEL0BgTQ8jwPVi@gnusha.org X-Gm-Message-State: AOJu0YxD60MHjjQbVQ09AeZslhsnMHN6TiMNMsefBAN4u824VWUB7ZJb iRhrPgI07q8J0yebGbBqaW1ZibVZSvFQkH1tdhQP33wcxtB5v+hV X-Google-Smtp-Source: AGHT+IGCSHqLsVGZ3pP1fisDtKk41X4QnpHdvzM69c5IjCzh6b1PI4VUGxGMf9PQyPPeDKxUeIRCZQ== X-Received: by 2002:a05:6820:2217:b0:5fc:e323:785e with SMTP id 006d021491bc7-5feb360c2c2mr853997eaf.5.1740710467922; Thu, 27 Feb 2025 18:41:07 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVGvkJUWnH2OUJKoGADTkEQ/8I2KGPiWlz/x2XuglNgBCw== Received: by 2002:a4a:e798:0:b0:5fc:f152:166a with SMTP id 006d021491bc7-5fea93386c1ls772393eaf.1.-pod-prod-07-us; Thu, 27 Feb 2025 18:41:04 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCVZUj/TDqnTUIdFU7O1zh2WQdS1G3jH94olaYgUp+mRbJ5FFGUAGGteddJcmBWOQ1HQtQ04Y1A9a/lr@googlegroups.com X-Received: by 2002:a05:6808:f8f:b0:3f4:cae:d5bd with SMTP id 5614622812f47-3f558556c78mr1072488b6e.20.1740710464531; Thu, 27 Feb 2025 18:41:04 -0800 (PST) Received: by 2002:a05:6808:424a:b0:3f4:4b9:4605 with SMTP id 5614622812f47-3f54e6a996dmsb6e; Wed, 26 Feb 2025 11:02:07 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCXZB6HkZZTb6lRJrwA7EAlkz+aTklVDlw28KHnMfWgfgCrzvLqQrCRPDGWq7TGaK1seEjeqh43uChFS@googlegroups.com X-Received: by 2002:a05:6a21:999c:b0:1e1:aef4:9ce8 with SMTP id adf61e73a8af0-1f10ae2e320mr8370514637.28.1740596526623; Wed, 26 Feb 2025 11:02:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1740596526; cv=none; d=google.com; s=arc-20240605; b=ZRe6dYOSXnVHYvfDB4+Iw9yYu1gxpd8M3aUmr0Ae5VWPdOFCqaay851MmCPW8syLNw Dpt1oN+Ok+jlh+Fd5LTj+W/snqiBUkRkJ/8nq/D4TBP3w1z0WboGIRNuie5Og6qahaS/ 477aAnxWRkKrUiBhFB3CPQklT6Cz1yiLLoaQC3A0bUH9ERBegX/L9dzDuijIq2mgMHG+ zLYoMQZ81fC3i4/lkr8CfnjaV4wWUuESPIlL6LJWW6zw1tdnqYjJxOOZlsW4iABDAB0a E+xQEoGuDhe/ulpk8oWZAHN/GaFHUdwPa3ehzaWRapkDQi2pEDDaKrVAW6X263bXXmj2 IJ3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:mime-version:date:message-id:dkim-signature :dkim-signature; bh=/qDqiN7/R8NyDSnAVKaxkEuspVrnghYhI0sAw8oY+oM=; fh=hcqDlhfHQsGtLaEYlrnwkDWezRv3/z95KdJhX9TL5V4=; b=JXIEpQYhNuu+c7J23JAP7QGfQsnWqxDzlxH/DQnOqyZ3ccRDSyQ+pTilcgxhdZHYmA tSOtBFGaA7lzpY1mq6sWNMS06rbX7D3uFcye0NV1yEpaxBCAYdnsNA3D7kqgBiDS36/6 5VK5IMbWxUefzJwVSt48c+Ztfgjxugg6H4ljzUWSi5gTnvp76JWOWhQAqNlIHv59lguR kK3oa1craqOiCgeeovhI/AAY+tYmuIBApIStJ9I3hH+n4n0QPY+Yr/K5qk4Wn6YSXuc5 7o5XhRLyr3jYwBVkKNE79jHCkWv8ggrshL47mxTNOr8N/1XmZAxxKYpWR5U4Khg0nAdS syZQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1740595262 header.b=jfVGfC7X; dkim=pass header.i=@clients.mail.as397444.net header.s=1740595265 header.b=hWtyFmlA; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com Received: from mail.as397444.net (mail.as397444.net. [2620:6e:a000:1::99]) by gmr-mx.google.com with ESMTPS id 41be03b00d2f7-aeda4a7a791si202972a12.0.2025.02.26.11.02.06 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Feb 2025 11:02:06 -0800 (PST) Received-SPF: pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::99 as permitted sender) client-ip=2620:6e:a000:1::99; X-DKIM-Note: Keys used to sign are likely public at X-DKIM-Note: https://as397444.net/dkim/mattcorallo.com and X-DKIM-Note: https://as397444.net/dkim/clients.mail.as397444.net X-DKIM-Note: For more info, see https://as397444.net/dkim/ Received: by mail.as397444.net with esmtpsa (TLS1.3) (Exim) (envelope-from ) id 1tnMfT-0015YQ-2q; Wed, 26 Feb 2025 19:02:04 +0000 Message-ID: <2e0fc337-3603-4a22-8056-59cf7e21aa43@mattcorallo.com> Date: Wed, 26 Feb 2025 14:02:02 -0500 MIME-Version: 1.0 Subject: Re: [bitcoindev] P2QRH / BIP-360 Update To: Hunter Beast , Bitcoin Development Mailing List References: <8797807d-e017-44e2-b419-803291779007n@googlegroups.com> <737fe7bb-4195-439f-87a9-b6fabd14eeea@mattcorallo.com> <866ee206-4a4e-4cd6-9de3-fa2fa35e2230n@googlegroups.com> Content-Language: en-US From: Matt Corallo In-Reply-To: <866ee206-4a4e-4cd6-9de3-fa2fa35e2230n@googlegroups.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Original-Sender: lf-lists@mattcorallo.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1740595262 header.b=jfVGfC7X; dkim=pass header.i=@clients.mail.as397444.net header.s=1740595265 header.b=hWtyFmlA; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.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.8 (/) I think you're approaching this from the wrong stance. If our goal is to "make bitcoin Quantum-secure", its gonna take a decade fo= r the state of PQ=20 research to build something that's ready for us to "just switch to". I don'= t buy that there's a=20 world where we get serious about adding something lattice-based to Bitcoin = for a longggg time (I'm=20 not sure I've ever heard a serious cryptographer suggest that lattice-based= systems are a good idea,=20 rather than "a good thing to layer on top of a traditional non-PQC scheme")= . In the short-term, the only (remotely-practical) thing we can do is add som= ething that we have high=20 confidence will still be secure in two decades (which basically is only has= h-based schemes) and get=20 wallets to include it in their taproot outputs. That gives wallets created = today the possibility of=20 being robust in a QC world, but, indeed, it would require tough decisions i= n the future. If your view is that Bitcoin would simply be fine if we didn't confiscate a= ny coins in response to a=20 practical QC stealing 5% of total supply, I'm not really convinced, but we = can also make it a=20 version-2 segwit output ("taproot but a future softfork can freely freeze t= he keypath spends") if=20 you really feel strongly. TBH the whole "would we confiscate if the time comes" question I think simp= ly cannot be answered=20 today because it depends very, very much on specific details (eg lets say w= e did the above proposal=20 and its been around for 30 years and ~all wallets support it, that's a very= very different world=20 from, for example, deploying some PQC scheme under threat where a QC could = realistically steal coins=20 in five years). The only thing we can really do today is create the option = in the future, we cannot=20 decide for the future what to do. Matt On 2/23/25 3:33 PM, Hunter Beast wrote: > Hi Matt, >=20 > The only problem with that approach is that SLH-DSA signatures are quite = large. NIST has also=20 > approved ML-DSA and FN-DSA, which, while both are based on lattice crypto= graphy, they're not only=20 > standardized, but becoming widely supported. One consideration is hardwar= e acceleration, and I=20 > believe those three algorithms will have the best chance of having hardwa= re implementations as PQC=20 > extensions are added to CPUs and SoCs. >=20 > As for gating P2TR, the problem with that approach is that keypath spends= would need to be disabled=20 > and that has a confiscatory effect that I'm seeking to avoid in this BIP. >=20 > An additional opcode should not be necessary if multisig capability is bu= ilt into the attestation. >=20 > I agree with your statement on full BIP-32 compatibility. BIP-360 is just= a starting point, and=20 > maybe you're right, it's best thought of as a "break glass" implementatio= n. It's not ideal, it's=20 > full of compromises, not everyone is 100% happy with it, and that's proba= bly okay, because bitcoin=20 > isn't perfect-- but it doesn't have to be in order to work. >=20 > Thank you for your thoughts. >=20 > Hunter >=20 > On Friday, February 21, 2025 at 3:18:21=E2=80=AFAM UTC-7 Matt Corallo wro= te: >=20 > If we want to do something like this in the short to medium term, IMO= we should strip out all the > signature schemes that are anything more than quite straightforward i= n their security assumptions > (i.e. only keep hash-based signatures, maybe just SPHINCS+), only emb= ed them in a taproot leaf, and > call it a day. >=20 > BIP 32 compatibility isn't a really huge deal if we're talking about = an "emergency break glass" > kinda setup - most wallets are set up with a root key and can just em= bed the same PQ pubkey in all > of their outputs. The privacy cost is only realized in a break glass = case, and long before then > hopefully whatever we do today is replaced with something better, wit= h the knowledge that we'll > gain > on the way to "then". We'd still want to do it in an opcode so that w= e can do multisig, though. >=20 > Matt >=20 > On 2/19/25 10:40 AM, Hunter Beast wrote: > > Dear Bitcoin Dev Community, > > > > > > A bit over six months after introducing the P2QRH proposal (now BI= P-360), I'm writing to share > > significant developments and request additional feedback on our po= st-quantum roadmap, and I'd > also > > like to mention a potential P2TRH post-quantum mitigation strategy= . > > > > > > First, now that there's a BIP number assigned, you can find the up= date BIP here: > > > > https://github.com/cryptoquick/bips/blob/p2qrh/bip-0360.mediawiki = cryptoquick/bips/blob/p2qrh/bip-0360.mediawiki> github.com/cryptoquick/> > > bips/blob/p2qrh/bip-0360.mediawiki> > > > > > > The revised BIP-360 draft reflects substantial changes since initi= al publication, particularly > > regarding algorithm selection. While we originally considered SQIs= ign, it has 15,000x slower > > verification compared to ECC [1]. If it takes 1 second to verify a= fully ECC block, it would > take 4 > > hours to validate a block filled with SQIsign transactions. This h= as obvious and concerning DDoS > > implications. > > > > > > While it would take a long time to signmany thousands of SQIsign t= ransactions as well, the > increased > > time needed to sign the transactions likely won=E2=80=99t affect t= he practicality of DDoS attacks-- > another > > concern which has been brought to my attention. As such, I've deci= ded to deprecate SQIsign > from the BIP. > > > > > > It's worth mentioning because it was brought up in the PR, there's= a new class of algorithms > that > > support signature aggregation, but they generally result in signat= ures that are still quite > large. > > Chipmunk and RACCOON are good examples [2], [3]. I do expect that = to improve with time. It > might be > > worthwhile to shorten the list by making signature aggregation a r= equirement, so as not to > regress > > too far from Schnorr signatures. That said, I think those capabili= ties should be introduced in a > > separate BIP once they're more mature and worthwhile. > > > > > > Our current shortlist prioritizes FALCON for its signature aggrega= tion potential, with > SPHINCS+ and > > CRYSTALS-Dilithium as secondary candidates. However, major technic= al challenges remain, > particularly > > BIP-32 compatibility issues affecting xpub generation in watch-onl= y wallets, as detailed by > > conduition in another mailing list discussion [4], and also, how w= e should handle multisig > wallets. > > > > > > Additionally, I think it's worthwhile to restrict BIP-360 to NIST-= approved algorithms to > maintain > > FIPS compliance. That's because HSMs such as those provided by Sec= urosys already have support > for > > all three algorithms [5], which is essential for secure deployment= of federated L2 treasuries. > > > > > > Presently, for multisigs, we have a merkle tree configuration defi= ned for encumbering the output > > with multiple keys. While that's efficient, it's a novel construct= ion. I'm not certain we should > > proceed with the merkle tree commitment scheme-- it needs more scr= utiny. We could use a sort > of P2SH > > approach, just modifying the semantics of OP_CHECKMULTISIG in a wi= tness script to alias to > public > > keys in the attestation. But that could introduce additional overh= ead in a signature scheme that > > already uses a lot more space. Without this, however, we do not ye= t have a way specified to > indicate > > thresholds or a locking script for the attestation, as it is desig= ned to be purposely > limited, so as > > specified it is only capable of n/n multisig. I consider m/n multi= sigs to be the single largest > > obvious omission in the spec right now. It definitely needs more t= hought and I'm open to > > suggestions. Perhaps two additional bytes at the top level of the = SegWit v3 output hash could be > > provided to indicate PQC signature threshold and total, and those = would be hashed and > committed to > > in the output, then provided in a field in the attestation once sp= ent. > > > > > > While finalizing PQC selections, I've also drafted P2TRH as an int= erim solution to secure > Taproot > > keypath spends without disabling them, as Matthew Corallo proposes= in the aforementioned mailing > > list thread [4]. The P2TRH approach hashes public keys rather than= exposing them directly, > > particularly benefiting: > > > > > > - MuSig2 Lightning channel implementations > > > > - FROST-based MPC vaults > > > > - High-value transactions using private pools that don't reveal th= e block template > > > > > > For those interested, take a look at the draft BIP for P2TRH here:= https://github.com/ > cryptoquick/ > > bips/blob/p2trh/bip-p2trh.mediawiki p2trh.mediawiki > > > > > > > I have my hands full with P2QRH advocacy and development and would= prefer to focus on that, > but I > > wanted to introduce P2TRH in case that is attractive as the commun= ity's preferred solution-- at > > least for Taproot quantum security. The tradeoff is that it adds 8= .25 vB of overhead per > input, and > > key tweaking might have slightly less utility for some application= s, and it also doesn't protect > > against short exposure quantum attacks as defined in BIP-360. > > > > > > Returning to P2QRH and what's needed to push it across the finish = line... > > > > > > I still need to finish the test vectors. I'm implementing these us= ing a fork of rust-bitcoin and > > modeling them after Steven Roose's work on BIP-346. I've been told= that's not a blocker for > merging > > the draft, but if it isn't merged by the time I'm finished, hopefu= lly that will provide some > > additional impetus behind it. > > > > > > One concern Murch brought up is that introducing four new algorith= ms into the network was too > many-- > > adding too much complexity to the network and to wallets and other= applications-- and I agree. > > > > > > Hopefully this is addressed to some degree by removing SQIsign (es= pecially in its current state > > lacking implementation maturity), and will help push the BIP below= a certain complexity > threshold, > > making it somewhat easier to review. > > > > I think it's still important to include multiple signature algorit= hm options for users to select > > their desired level of security. It's not 100% certain that all of= these algorithms will remain > > quantum resistant for all time, so redundancy here is=E2=80=A6 key= . > > > > > > Another concern is that NIST level V is overkill. I have less conv= iction on this since secp256k1 > > technically has 128 bits of security due to Pollard's rho attacks.= But if the intention was > for 256 > > bits of security, should level V security be the default? It's dif= ficult for me to say. > Perhaps both > > level V and level I implementations could be included, but this wo= uld be a deviation from the > BIP as > > presently specified, which defaults to level V security. The disad= vantage of including level I > > support for each algorithm is that it essentially doubles the comp= lexity of libbitcoinpqc. > > > > > > Ultimately, I hope the default of NIST V and selection of 3 mature= NIST-approved algorithms > > demonstrate a focused, polished, and conservative proposal. > > > > > > At this point, the major call to action I would like to highlight = is simply the need for more > > feedback from the community. Please review and provide feedback he= re: https://github.com/ > bitcoin/ > > bips/pull/1670 pull/1670>> > > > > > > I look forward to feedback and opinions on P2QRH and P2TRH. > > > > > > P.S. I'll be advocating for BIP-360 at OP_NEXT in VA, btc++ in Aus= tin, Consensus in Toronto, > and BTC > > 25 in Las Vegas, and later this year, TABConf in Atlanta. > > > > > > > > [1] https://pqshield.github.io/nist-sigs-zoo > > > > [2] https://eprint.iacr.org/2023/1820.pdf > > > > [3] https://eprint.iacr.org/2024/1291.pdf > > > > [4] https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/7uu4dZN= gAwAJ groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/7uu4dZNgAwAJ> > > > > [5] https://docs.securosys.com/tsb/Tutorials/Post-Quantum-Cryptogr= aphy/pqc-release-overview > > > > > > > -- > > 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+...@googlegroups.com . > > To view this discussion visit https://groups.google.com/d/msgid/bi= tcoindev/8797807d- > e017-44e2- > > b419-803291779007n%40googlegroups.com = d/msgid/bitcoindev/8797807d- > > e017-44e2-b419-803291779007n%40googlegroups.com?utm_medium=3Demail= &utm_source=3Dfooter > >. >=20 > --=20 > You received this message because you are subscribed to the Google Groups= "Bitcoin Development=20 > Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= email to=20 > bitcoindev+unsubscribe@googlegroups.com . > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/866ee206-4a4e-4cd6-9de3-=20 > fa2fa35e2230n%40googlegroups.com bitcoindev/866ee206-4a4e-4cd6-9de3-fa2fa35e2230n%40googlegroups.com?utm_m= edium=3Demail&utm_source=3Dfooter>. --=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/= 2e0fc337-3603-4a22-8056-59cf7e21aa43%40mattcorallo.com.