summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorhunter <hunter@surmount.systems>2024-06-17 14:27:26 -0600
committerbitcoindev <bitcoindev@googlegroups.com>2024-06-17 15:25:32 -0700
commitbea9543595a1cd03c029bd426e0a3c6e0c3f8502 (patch)
treef2724cf97211632d5563c82c01d37f6eb5674517
parentf43afa7ee03ec92851350458deeccd7915771184 (diff)
downloadpi-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/b15c8fd5cb6929cddbfbf7d1dd630c943bca7a373
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.
+