diff options
author | hunter <hunter@surmount.systems> | 2024-06-17 14:27:26 -0600 |
---|---|---|
committer | bitcoindev <bitcoindev@googlegroups.com> | 2024-06-17 15:25:32 -0700 |
commit | bea9543595a1cd03c029bd426e0a3c6e0c3f8502 (patch) | |
tree | f2724cf97211632d5563c82c01d37f6eb5674517 | |
parent | f43afa7ee03ec92851350458deeccd7915771184 (diff) | |
download | pi-bitcoindev-bea9543595a1cd03c029bd426e0a3c6e0c3f8502.tar.gz pi-bitcoindev-bea9543595a1cd03c029bd426e0a3c6e0c3f8502.zip |
Re: [bitcoindev] Re: Proposing a P2QRH BIP towards a quantum resistant soft fork
-rw-r--r-- | 95/b15c8fd5cb6929cddbfbf7d1dd630c943bca7a | 373 |
1 files changed, 373 insertions, 0 deletions
diff --git a/95/b15c8fd5cb6929cddbfbf7d1dd630c943bca7a b/95/b15c8fd5cb6929cddbfbf7d1dd630c943bca7a new file mode 100644 index 000000000..52270d3d5 --- /dev/null +++ b/95/b15c8fd5cb6929cddbfbf7d1dd630c943bca7a @@ -0,0 +1,373 @@ +Delivery-date: Mon, 17 Jun 2024 15:25:32 -0700 +Received: from mail-oo1-f56.google.com ([209.85.161.56]) + by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 + (Exim 4.94.2) + (envelope-from <bitcoindev+bncBD3YNWFH7IHBBU7PYKZQMGQERCHF7MQ@googlegroups.com>) + id 1sJKn5-0001NY-DH + for bitcoindev@gnusha.org; Mon, 17 Jun 2024 15:25:32 -0700 +Received: by mail-oo1-f56.google.com with SMTP id 006d021491bc7-5bdab2e0eb1sf4483272eaf.2 + for <bitcoindev@gnusha.org>; Mon, 17 Jun 2024 15:25:31 -0700 (PDT) +ARC-Seal: i=2; a=rsa-sha256; t=1718663125; cv=pass; + d=google.com; s=arc-20160816; + b=pBxOY/GPzzBYt1c58zIk3gtdBEvE+olzojhzOEYqZ4JVmXT8jwnokdSzoxyMVGwW4w + 25hrlC1Og7TLZd+51JhMUUeIZjVE13sD6WOdlPqLtt52ICdlDUNhNohG5mDVoZwIblzK + 0sziNFHSIUacA2td3rlnQAXpGdXwhTVNqbtXExlVvgRaA8jgWPNmI0FXnAguycCBBGlq + Km1pHa0+P2f7KMHVMbEPyOa04t+g3OsGxz5eF4XT8v7JLKKYazOGaT7iNx2e9oZ7+LUl + ZcGaNiS5sprP+8/A92V5YQsc4B1mWHPP3mp4+LWZJtTPwzPPQAXvXmtljxUjBq6L1RdR + CY+Q== +ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; + h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post + :list-id:mailing-list:precedence:content-disposition + :content-transfer-encoding:mime-version:subject:references + :in-reply-to:message-id:cc:to:from:date:sender:dkim-signature; + bh=vgCYADfxcAJIvyZq0vfMDG0NKuZTAcLrG/TjXJoMT+8=; + fh=Cxc/O8T7ElfW8yOOWW3qUA1a/MKtKBGKOs6y0T9oTe4=; + b=UoEF9WbcKtXHBcXQd3AXJNAXTl+pugW7zkHE5YIytg4uerDgn3FtSITPGpkG+OacRY + EHnuju1CT+YaiAS2e/VMQrGGYS6hMeLgvfl9Vtjmtsth7nMS4cO4s0dvcIyjK4FSplvh + ibqSAsFO7pj41pbOgiFegIjVhKxauHFDhlA6fo/VCZsC3HgvCprvnCqgHEcLCDCRgkt/ + f2RKweoXpeQmzeffsvP8Vr780uBxQe3nNyMXQQSIz0tz0IFqvevwKJJoszXS7yOuz1rs + znOCGRMeQmCMq+d115lkaFiW18IzfvWAD1YCD0RNs2Bb/2b/mWjdFw8/WS/STeO71gbQ + BU+Q==; + darn=gnusha.org +ARC-Authentication-Results: i=2; gmr-mx.google.com; + dkim=pass header.i=@surmount.systems header.s=_dkim header.b="YXWWK/Lm"; + spf=pass (google.com: domain of hunter@surmount.systems designates 8.46.89.33 as permitted sender) smtp.mailfrom=hunter@surmount.systems; + dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=surmount.systems +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=googlegroups.com; s=20230601; t=1718663125; x=1719267925; 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-disposition:content-transfer-encoding + :mime-version:subject:references:in-reply-to:message-id:cc:to:from + :date:sender:from:to:cc:subject:date:message-id:reply-to; + bh=vgCYADfxcAJIvyZq0vfMDG0NKuZTAcLrG/TjXJoMT+8=; + b=p/Epn6lvVflui6dmfU5P/e2oruvcL+3/okuP8do/oPUs37XIq2UiP0vxRaJLCYrNES + jjBAtDEmSj+tg/comAut5PrixtCjhjiWRswORc55h6MRlJaBOdRSePk1T4BlpraZI0tZ + aJc5EVs/m5kc7a39q+LnjbKfVTmh69czP66B2fzkfWSl83qp9HxEPr7hVR85PdpMGSUg + N/2gtOW6K7kmW7LpkElqLXLyaxoYDIDQSmAzKUQxmRw2mUHCvoEzhhkjKrMAFd+d2u6k + 2Omr5oi8Nr85VMqmbr7Ej6Ig+5pi+D97zQgKPgEE2vpuOS2icVEkjVufSgwN86GTN0RM + U/Qg== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20230601; t=1718663125; x=1719267925; + h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post + :list-id:mailing-list:precedence:x-original-authentication-results + :x-original-sender:content-disposition:content-transfer-encoding + :mime-version:subject:references:in-reply-to:message-id:cc:to:from + :date:x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date + :message-id:reply-to; + bh=vgCYADfxcAJIvyZq0vfMDG0NKuZTAcLrG/TjXJoMT+8=; + b=Ibrw2si0ZQS34bvCmGYrgvg8Ejh/39IMxlfZXsNsmnxALfCyXrJxLzamIr9U2ho8+5 + 5Fy0f2BC2kb6uon6Oi5LQ8KOPfq8dOHx+Hgc+fq8Z7KRqXWLHmBZb/qX8pN6gWUDVGSI + FkUTh9bi+LFSx/HPl0kr/6nXubu41L7EW2pt/0NmcKoAU3E8DlqnD3zQDZcLcbHgARYs + YT9OA5VY3+V/Dyu49tMEk8pmV/4OTqOBYfStkWy6TbQ4Xkg4O1R5XZwM10CJ5zlsIdjp + FPXRb8r0jjBdz7/vq5nO4hEdXHhGhf77/j75P/95i+YDtqmEeFfctirK9zEBRaGHeW9Q + TkdQ== +Sender: bitcoindev@googlegroups.com +X-Forwarded-Encrypted: i=2; AJvYcCVNYIvWzPd4y9V+c1kzvYOojvEHciEFlnWbkG+uL6DzqUkzl79tvIcyIZoz/PgYIvipF5ckksYW9c4QtrDjZY0NQzztDwQ= +X-Gm-Message-State: AOJu0YxlPD9ceJLGxQ8tCiWXO2BgX6L3u13spph595dfnPqGk/sWZpdT + Lemee3ZameiR0xkS/+MgLrXF+4WakC3yfnsvyEr8W8q8QZoWdY4D +X-Google-Smtp-Source: AGHT+IFvq12oxFrfinMz1KCI9rigxI59XYGb1U5ClWygnWZCiju7rVpYlyWzWCJZ31vLub2ukyUb5A== +X-Received: by 2002:a05:6820:545:b0:5ba:8884:4138 with SMTP id 006d021491bc7-5bdadc70d1cmr11259171eaf.7.1718663124884; + Mon, 17 Jun 2024 15:25:24 -0700 (PDT) +X-BeenThere: bitcoindev@googlegroups.com +Received: by 2002:a4a:5843:0:b0:5ba:68cc:8c40 with SMTP id 006d021491bc7-5bcc3e371ecls4809033eaf.2.-pod-prod-09-us; + Mon, 17 Jun 2024 15:25:23 -0700 (PDT) +X-Received: by 2002:a05:6830:44a7:b0:6f1:42c9:2a1a with SMTP id 46e09a7af769-6fb93dced50mr60461a34.5.1718663122952; + Mon, 17 Jun 2024 15:25:22 -0700 (PDT) +Received: by 2002:a05:6808:185:b0:3d1:c9f2:f6fb with SMTP id 5614622812f47-3d24ed711admsb6e; + Mon, 17 Jun 2024 13:27:31 -0700 (PDT) +X-Received: by 2002:a17:90a:5794:b0:2c4:e333:35f3 with SMTP id 98e67ed59e1d1-2c4e333379dmr8535317a91.6.1718656050146; + Mon, 17 Jun 2024 13:27:30 -0700 (PDT) +ARC-Seal: i=1; a=rsa-sha256; t=1718656050; cv=none; + d=google.com; s=arc-20160816; + b=F69k/0QuGj6YINzf9OHW6av78ksb1qNoMrXWrOyLT3OURBISMFBjmPmYOs5qr2lQ1k + +oKALY4lzLMMFyWhIoqq69N+9uKM+FChfM1msZICpyYAR7LQX/fsCmr7f/eXuTlHJmP2 + c9gEmn8zaFFdFtCp60hVqc73EGzw8bVbNt2KUerhugeOKsKxJFCKbiRDJrVkIyp+/M1a + NnCET40H+feaBOi4H+HDK85o/hgrOXG8Vt/VSZReg1UjCoyWMAcs361JIckHFrEAZBye + nobZHW/3hsLVXookPPflk44ckceJb2cS3okNx4igfPrMQUjBEAUW+Z6Cp/TPG8PEVfSC + 1QbQ== +ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; + h=content-disposition:content-transfer-encoding:mime-version:subject + :references:in-reply-to:message-id:cc:to:from:date:dkim-signature; + bh=P4O1TWvuicZJIeTK4mmQs+fPEPmG255ldjIwZBVTRoc=; + fh=3VSGXgxsCWogVTFHGBSRHB1w+i/txFjcQxwNlqY3jZo=; + b=02SoHUG7bwmPAq93qdhWRsnhVd1EEo+IX+fdwOQ+vtNrXnwUNf/hQ6NwXX+XjuRMTc + mI22d4c7ODqMGuCIGLDjwyRCkLGdCOCAR/+PRuqL+oVQF6OvTN6AgXRry4UTjUGd2OMJ + KYHXtwn5UUWvu1d/gLxtn0aCWSlwnw7fxEme8fZpRnNEPaijcLDt3A0Y50XN92grcRQN + Mz5nBpsSjCXkf65/cSjCppb1h9IM7BVHXRQyJF52omSxFVA5ErFXoIJOAFTfKKa7Zb1N + A6+Fm6LfDSHT3ZfgdXJ1yBTcM8hcqUVC4O/apgX+VrK4i/bFG5fIdkn4FAZKmKNdP4IW + TkfA==; + dara=google.com +ARC-Authentication-Results: i=1; gmr-mx.google.com; + dkim=pass header.i=@surmount.systems header.s=_dkim header.b="YXWWK/Lm"; + spf=pass (google.com: domain of hunter@surmount.systems designates 8.46.89.33 as permitted sender) smtp.mailfrom=hunter@surmount.systems; + dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=surmount.systems +Received: from mail.cryptoquick.com ([8.46.89.33]) + by gmr-mx.google.com with ESMTPS id 98e67ed59e1d1-2c70d5f281esi2706a91.1.2024.06.17.13.27.29 + for <bitcoindev@googlegroups.com> + (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); + Mon, 17 Jun 2024 13:27:29 -0700 (PDT) +Received-SPF: pass (google.com: domain of hunter@surmount.systems designates 8.46.89.33 as permitted sender) client-ip=8.46.89.33; +Received: from DS3018xs (localhost [127.0.0.1]) + by mail.cryptoquick.com (Postfix) with ESMTPA id 7A4638595902; + Mon, 17 Jun 2024 14:27:28 -0600 (MDT) +Date: Mon, 17 Jun 2024 14:27:26 -0600 +From: hunter <hunter@surmount.systems> +To: "Antoine Riard" <antoine.riard@gmail.com> +Cc: "Bitcoin Development Mailing List" <bitcoindev@googlegroups.com> +Message-ID: <2cbd432f-ca19-4481-93c5-3b0f7cdea1cb@DS3018xs> +In-Reply-To: <87b4e402-39d8-46b0-8269-4f81fa501627n@googlegroups.com> +References: <62fd28ab-e8b5-4cfc-b5ae-0d5a033af057n@googlegroups.com> + <b3561407-483e-46cd-b5e9-d6d48f8dca93n@googlegroups.com> + <d78f5dc4-a72d-4da4-8a24-105963155e4dn@googlegroups.com> + <87b4e402-39d8-46b0-8269-4f81fa501627n@googlegroups.com> +Subject: Re: [bitcoindev] Re: Proposing a P2QRH BIP towards a quantum + resistant soft fork +MIME-Version: 1.0 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable +Content-Disposition: inline +X-Synology-MCP-Status: no +X-Synology-Spam-Status: score=0.399, required 5, ARC_NA 0, T_SCC_BODY_TEXT_LINE 0, __NOT_A_PERSON 0, URIBL_BLOCKED 0, FROM_HAS_DN 0, FREEMAIL_ENVRCPT 0, TO_MATCH_ENVRCPT_ALL 0, TAGGED_RCPT 0, __THREADED 0, MIME_GOOD -0.1, TO_DN_ALL 0, __URI_ONLY_MSGID_MALF 0, RCPT_COUNT_TWO 0, FREEMAIL_TO 0, RCVD_COUNT_ZERO 0, FROM_EQ_ENVFROM 0, MID_RHS_NOT_FQDN 0.5, MIME_TRACE 0, __NOT_SPOOFED 0, __BODY_URI_ONLY 0, NO_RECEIVED -0.001 +X-Synology-Spam-Flag: no +X-Synology-Virus-Status: no +X-Original-Sender: hunter@surmount.systems +X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass + header.i=@surmount.systems header.s=_dkim header.b="YXWWK/Lm"; spf=pass + (google.com: domain of hunter@surmount.systems designates 8.46.89.33 as + permitted sender) smtp.mailfrom=hunter@surmount.systems; dmarc=pass + (p=NONE sp=NONE dis=NONE) header.from=surmount.systems +Precedence: list +Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com +List-ID: <bitcoindev.googlegroups.com> +X-Google-Group-Id: 786775582512 +List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com> +List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com> +List-Archive: <https://groups.google.com/group/bitcoindev +List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com> +List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>, + <https://groups.google.com/group/bitcoindev/subscribe> +X-Spam-Score: -0.8 (/) + + +-----BEGIN PGP SIGNED MESSAGE----- +Hash: SHA256 + +On 2024-06-16 19:31, Antoine Riard <antoine.riard@gmail.com> wrote: + +> +> Hi Hunter Beast,I think any post-quantum upgrade signature algorithm upgr= +ade proposal would grandly benefit to haveShor's based practical attacks fa= +r more defined in the Bitcoin context. As soon you start to talk aboutquant= +um computers there is no such thing as a "quantum computer" though a wide a= +rray of architecturesbased on a range of technologies to encode qubits on n= +anoscale physical properties. +> +Good point. I can write a section in the BIP Motivation or Security section= + about how an attack might take place practically, and the potential urgenc= +y of such an attack. +=C2=A0 +I was thinking of focusing on the IBM Quantum System Two, mention how it ca= +n be scaled, and that although it might be quite limited, if running Shor's= + variant for a sufficient amount of time, above a certain minimum threshold= + of qubits, it might be capable of decrypting the key to an address within = +one year. I base this on the estimate provided in a study by the Sussex Cen= +tre for Quantum Technologies, et. al [1]. They provide two figures, 317M qu= +bits to decrypt in one hour, 13M qubits to decrypt in one day. It would see= +m it scales roughly linearly, and so extrapolating it further, 36,000 qubit= +s would be needed to decrypt an address within one year. However, the IBM H= +eron QPU=C2=A0turned out to have a gate time 100x less than was estimated i= +n 2022, and so it might be possible to make do with even fewer qubits still= + within that timeframe. With only 360 qubits, barring algorithmic overhead = +such as for circuit memory, it might be possible to=C2=A0decrypt a single a= +ddress within a year. That might sound like a lot, but being able to=C2=A0a= +ccomplish that=C2=A0at all would be significant, almost like a Chicago Pile= + moment, proving something in practice that was previously only thought the= +oretically possible for the past 3 decades. And it's only downhill from the= +re... +> +> This is not certain that any Shor's algorithm variant works smoothly inde= +pendently of the quantum computerarchitecture considered (e.g gate frequenc= +y, gate infidelity, cooling energy consumption) and I think it'san interest= +ing open game-theory problem if you can concentrate a sufficiant amount of = +energy before anycoin owner moves them in consequence (e.g seeing a quantum= + break in the mempool and reacting with a counter-spend). +> +It should be noted that P2PK keys still hold millions of bitcoin, and those= + encode the entire public key for everyone to see for all time. Thus, early= + QC attacks won't need to consider the=C2=A0complexities of the mempool. +> +> In my opinion, one of the last time the subject was addressed on the mail= +ing list, the description of the state of the quantum computer field was no= +t realistic and get into risk characterization hyperbole talking about "sup= +er-exponential rate" (when indeed there is no empirical realization=C2=A0th= +at distinct theoretical advance on quantum capabilities=C2=A0can be combine= +d with each other) [1]. +> +I think it's time to revisit these discussions given IBM's progress. They'v= +e published a two videos in particular that are worth watching; their keyno= +te from December of last year [2], and their roadmap update from just last = +month [3]. +> +> On your proposal, there is an immediate observation which comes to mind, = +namely why not using one of the algorithm(dilthium, sphincs+, falcon) which= + has been through the 3 rounds of NIST cryptanalysis. Apart of the signatur= +e size,which sounds to be smaller, in a network of full-nodes any PQ signat= +ure algorithm should have reasonable verificationperformances. +> +I'm supportive of this consideration. FALCON might be a good substitute, an= +d maybe it can be upgraded to HAWK for even better performance depending on= + how much time there is. According to the BIP, FALCON signatures are ~10x l= +arger than Schnorr signatures, so this will of course make the transaction = +more expensive, but we also must remember, these signatures will be going i= +nto the witness, which already receives a 4x discount. Perhaps the discount= + could be increased further someday to fit more transactions into blocks, b= +ut this will also likely result in more inscriptions filling unused space a= +lso, which permanently increases the burden of running an archive node. Due= + to the controversy such a change could bring, I would rather any increases= + in the witness discount be excluded from future activation discussions, so= + as to be considered separately, even if it pertains to an increase in P2QR= +H transaction size. +=C2=A0 +Do you think it's worth reworking the BIP to use FALCON signatures? I've on= +ly done a deep dive into SQIsign and SPHINCS+, and I will acknowledge the r= +eadiness levels between those two are presently worlds apart. +=C2=A0 +Also, do you think it's of any concern to use HASH160 instead of HASH256 in= + the output script? I think it's fine for a cryptographic commitment since = +it's simply a hash of a hash (MD160 of SHA-256). +> +> Lastly, there is a practical defensive technique that can be implemented = +today by coin owners to protect in face ofhyptothetical quantum adversaries= +. Namely setting spending scripts to request an artificially inflated witne= +ss stack,as the cost has to be burden by the spender. I think one can easil= +y do that with OP_DUP and OP_GREATERTHAN and a bitof stack shuffling. While= + the efficiency of this technique is limited by the max consensus size of t= +he script stack(`MAX_STACK_SIZE`) and the max consensus size of stack eleme= +nt (`MAX_SCRIPT_ELEMENT_SIZE`), this adds an additional"scarce coins" pre-r= +equirement on the quantum adversarise to succeed. Shor's algorithm is only = +defined under theclassic ressources of computational complexity, time and s= +pace. +> +I'm not sure I fully understand this, but even more practically, as mention= +ed in the BIP, value can simply be kept in P2WPKH outputs, ideally with a v= +alue of fewer than 50 coins per address, and when funds ever need to be spe= +nt, the transaction is signed and submitted out of band to a trusted mining= + pool, ideally one that does KYC, so it's known which individual miners get= + to see the public key before it's mined. It's not perfect, since this reli= +es on exogenous security assumptions, which is why P2QRH is proposed. +> +> Best,Antoine +> [1]=C2=A0https://freicoin.substack.com/p/why-im-against-taproot +> +=C2=A0 +I'm grateful you took the time to review the BIP and offer your detailed in= +sights. +=C2=A0 +[1] =E2=80=9CThe impact of hardware specifications on reaching quantum adva= +ntage in the fault tolerant regime,=E2=80=9D 2022=C2=A0-=C2=A0https://pubs.= +aip.org/avs/aqs/article/4/1/013801/2835275/The-impact-of-hardware-specifica= +tions-on-reaching +[2]=C2=A0https://www.youtube.com/watch?v=3DDe2IlWji8Ck +[3]=C2=A0https://www.youtube.com/watch?v=3Dd5aIx79OTps +=C2=A0 +> +> +> Le vendredi 14 juin 2024 =C3=A0 15:30:54 UTC+1, Hunter Beast a =C3=A9crit= +=C2=A0: +> +> > Good points. I like your suggestion for a SPHINCS+, just due to how mat= +ure it is in comparison to SQIsign. It's already in its third round and has= + several standards-compliant implementations, and it has an actual specific= +ation rather than just a research paper. One thing to consider is that NIST= +-I round 3 signatures are 982 bytes in size, according to what I was able t= +o find in the documents hosted by the SPHINCS website. +> > https://web.archive.org/web/20230711000109if_/http://sphincs.org/data/s= +phincs+-round3-submission-nist.zip +> > =C2=A0 +> > One way to handle this is to introduce this as a separate address type = +than SQIsign. That won't require OP_CAT, and I do want to keep this soft fo= +rk limited in scope. If SQIsign does become significantly broken, in this h= +opefully far future scenario, I might be supportive of an increase in the w= +itness discount. +> > =C2=A0 +> > Also, I've made some additional changes based on your feedback on X. Yo= +u can review them here if you so wish: +> > https://github.com/cryptoquick/bips/pull/5/files?short_path=3D917a32a#d= +iff-917a32a71b69bf62d7c85dfb13d520a0340a30a2889b015b82d36411ed45e754 +> > +> > +> > On Friday, June 14, 2024 at 8:15:29=E2=80=AFAM UTC-6 Pierre-Luc Dallair= +e-Demers wrote: +> > > SQIsign is blockchain friendly but also very new, I would recommend a= +dding a hash-based backup key in case an attack on SQIsign is found in the = +future (recall that SIDH broke over the span of a weekend=C2=A0https://epri= +nt.iacr.org/2022/975.pdf). +> > > Backup keys can be added in the form of a Merkle tree where one branc= +h would contain the SQIsign public key and the other the public key of the = +recovery hash-based scheme. For most transactions it would only add one bit= + to specify the SQIsign branch. +> > > The hash-based method could be Sphincs+, which is standardized by NIS= +T but requires adding extra code, or Lamport, which is not standardized but= + can be verified on-chain with OP-CAT. +> > > +> > > On Sunday, June 9, 2024 at 12:07:16=E2=80=AFp.m. UTC-4 Hunter Beast w= +rote: +> > > > The motivation for this BIP is to provide a concrete proposal for a= +dding quantum resistance to Bitcoin. We will need to pick a signature algor= +ithm, implement it, and have it ready in event of quantum emergency. There = +will be time to adopt it. Importantly, this first step is a more substantiv= +e answer to those with concerns beyond, "quantum computers may pose a threa= +t, but we likely don't have to worry about that for a long time". Bitcoin d= +evelopment and activation is slow, so it's important that those with low ti= +me preference start discussing this as a serious possibility sooner rather = +than later. This is meant to be the first in a series of BIPs regarding a = +hypothetical "QuBit" soft fork. The BIP is intended to propose concrete sol= +utions, even if they're early and incomplete, so that Bitcoin developers ar= +e aware of the existence of these solutions and their potential. This is j= +ust a rough draft and not the finished BIP. I'd like to validate the approa= +ch and hear if I should continue working on it, whether serious changes are= + needed, or if this truly isn't a worthwhile endeavor right now. +> > > > =C2=A0 +> > > > The BIP can be found here: +> > > > https://github.com/cryptoquick/bips/blob/p2qrh/bip-p2qrh.mediawiki +> > > > =C2=A0 +> > > > Thank you for your time. +> > > > =C2=A0 +> > > > +> > > +> > > +> > +> > +> +> +> -- You received this message because you are subscribed to a topic in the= + Google Groups "Bitcoin Development Mailing List" group. To unsubscribe fro= +m this topic, visit https://groups.google.com/d/topic/bitcoindev/Aee8xKuIC2= +s/unsubscribe. To unsubscribe from this group and all its topics, send an e= +mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on= + the web visit https://groups.google.com/d/msgid/bitcoindev/87b4e402-39d8-4= +6b0-8269-4f81fa501627n%40googlegroups.com. + +-----BEGIN PGP SIGNATURE----- +Version: OpenPGP.js v4.10.3 +Comment: https://openpgpjs.org + +wsBcBAEBCAAGBQJmcJwuAAoJEDEPCKe+At0hjhkIAIdM7QN9hAO0z+KO7Bwe +JT45XyusJmDG1gJbLZtb+SfuE1X5PFDHNTLSNliJWsOImxFCiBPnlXhYQ4B/ +8gST3rqplUwkdYr52E5uMxTTq9YaXTako4PNb8d7XfraIwDKXAJF+5Skf4f9 +bQUYMieBAFSEXCmluirQymB+hUoaze60Whd07hhpzbGSwK4DdSXltufkyCDE +tJUforNWm8X25ABTSNDh3+if5V/wJuix/u8GJyMHKucaEAO01ki2oyusq2rt +Xe6ysUieclusFFdQAs4PfYxhzXTf5XeAbFga/qxrVtbt7q2nUkYklqteT2pp +mH/DU20HMBeGVSrISrvsmLw=3D +=3D+wat +-----END PGP SIGNATURE----- + +--=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 on the web visit https://groups.google.com/d/msgid/= +bitcoindev/2cbd432f-ca19-4481-93c5-3b0f7cdea1cb%40DS3018xs. + |