From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 (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 To: "Antoine Riard" Cc: "Bitcoin Development Mailing List" 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> <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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.8 (/) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2024-06-16 19:31, Antoine Riard 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.