path: root/95/b15c8fd5cb6929cddbfbf7d1dd630c943bca7a

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.