path: root/89/0a9300c339987e544a432a69144af2cf7353e6

Delivery-date: Fri, 21 Feb 2025 02:18:29 -0800
Received: from mail-qt1-f189.google.com ([209.85.160.189])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBAABB2VF4G6QMGQEZ6D62BY@googlegroups.com>)
	id 1tlQ71-000074-Lc
	for bitcoindev@gnusha.org; Fri, 21 Feb 2025 02:18:28 -0800
Received: by mail-qt1-f189.google.com with SMTP id d75a77b69052e-47217c14be9sf56424691cf.1
        for <bitcoindev@gnusha.org>; Fri, 21 Feb 2025 02:18:27 -0800 (PST)
ARC-Seal: i=2; a=rsa-sha256; t=1740133101; cv=pass;
        d=google.com; s=arc-20240605;
        b=kqAAKE6O+ABMKPHLNNFYnqYNvyFu6PJyQo7fVymPuBdGqssK82XMNwIWY0dWun82zO
         /+RRwTPpEuKsc6+XAKPcgA+HuZZzCFZDpnk+uUBe4iBN8B/Wl0MNsn5WZEdBs+6suCl0
         B8SYB1O+g2VBJzVBFsGfiBG8JgIzeM5TPhJzL7Gc58nfz4CvE8BAbWw+PRSbHMs1AJdJ
         4/8g6JSgx0x1tY8oqvV2eMYw2tP1Kt+DH3O9flvgkM3UigvWNLPTLKCWjqA/gtVN5cDm
         Fv3U1mxB/vbm9KQb+agxOQzzS/xRuYr11qiRoAucy2mDIYP5CBKOvOUlThBii426/M2V
         dTrA==
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=vybh6y/G30N/gVZpoGloZRU+SgaqRl5opWYQgINSILI=;
        fh=0ZWx0DbLdM8xOv2l8+VR0+a73tIccKLHycOBl+xKN8w=;
        b=HMhuLg2QWQLjJsdJbLl+a8NREIbxDKgsONjs979SJ3edG2q6MGpX6Hjl4Ff65Dl8cY
         Jb5rVEl8hC55yjXSmOQG+5GRa6ZtKhcTECO9/hUUF3I7FZKCInvZzbylvrUxSR3jZiCu
         E8oS91QhgWEU2ZNMfEkXehsNlKWyYB4umqOY+NHiW9CMJYzAIbp3/oT/+MxEDrJo1cZH
         ES3HyANJObEPIu91PA8mX+7TFR6FfmxMkbf6C/1ACq9IvosMod7L/vlwHDHCXBJjr2rW
         SMh6sw/oO09IU0CvhM7RFDV+A8XjWI2zYkzGAvA0dC08XmHeRecfHL8VFI6ic/dIRctz
         KKOg==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@mattcorallo.com header.s=1740087662 header.b=lx7IRRUm;
       dkim=pass header.i=@clients.mail.as397444.net header.s=1740087665 header.b=FkFtYX5E;
       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=1740133101; x=1740737901; 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=vybh6y/G30N/gVZpoGloZRU+SgaqRl5opWYQgINSILI=;
        b=cv0RjKH9taDzovEPm3NhtbuWvDOn2dxHUbbSIRRlIjyeIiFyG+Kb7iYHJyPwo1Rz1C
         zRmqTt00fHN2hkKvyTNv4+w+CHo8UL0ulRz0Fp1mQx8+gEyazur1mc8dYblWkmyThK/X
         YMIIdw4ugRaFOdQfXC0f25L5fbe7qvsrknKHjfTwrJ+SaKESBn5OFz40OgmMY60UuXWD
         0KpXcDsq/+58o/oSH1p6hRQCIHw6FxIw1p3NFQQAnAn98i7U1y/rrwbc4IntMF3lMob7
         qKBq+B7DlsBGJn3TxEqACQnr9Imi+Ec/8nPqPTKlxXwSz0AUTs2hyUmSa3VY6FtrCu7z
         baLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1740133101; x=1740737901;
        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=vybh6y/G30N/gVZpoGloZRU+SgaqRl5opWYQgINSILI=;
        b=ilQJl5kDy1CAd5hD/PVnRi18epvCiUw8FPyDW5TwLIBHQgaiJb1Ue+unfbeXkgxRXj
         0Jk019MP7XtgFj80XbiEujSiTi7+0kNVK0kE6uiJqd510HMHI2FHkzq7gVF9I6ZyRlsR
         PyvpsEBukrowgkwFy+xEE/i+4rcgq6IiDeC0h0vppIOm5V4DUPcHP610Dri9zROlI7rq
         NBN8rFvrWfz8baHayfZQS65hKDmAb9x3vPeeQDQ/05NHtNo5ei+3TYi9oyXt9ldeBAVE
         h6ticFpYI5lrQ7l7DAr8VstjEhRdPIe6CkA3doUWD0sP2eiNW0o3YgLVMoUTQ4cH6RJc
         6hiQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCU47ingDM2QQQU009XklqNVLh3rDwAkBsRLzALU5NylVrOmgFW2wsMAETs2ZzVmbrylw3xsP1qCbhTT@gnusha.org
X-Gm-Message-State: AOJu0YxoH4whMv9rJkv+Ug1OffYrmiZvCv7oYHo4XVfhguO4vP6cL8oN
	K1lHu10l2cVMzD0PnB2PRCqpOUrsYb/1oPuev1sxRZrjrLjvHMnU
X-Google-Smtp-Source: AGHT+IFq4F9sWUFrSKATXRICSI+n2g4bjfDH/qyUEyTjXe3uvtnr3ivnnJAK7BT9nPNlCwJ75Yjudg==
X-Received: by 2002:ac8:5a15:0:b0:472:1601:c53d with SMTP id d75a77b69052e-47222953243mr35627091cf.36.1740133101371;
        Fri, 21 Feb 2025 02:18:21 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVFK4d1danmnUIlLg18+tEgfnl4+FdBSbJDi62X8KJPrlA==
Received: by 2002:ac8:45c5:0:b0:46b:2e03:7b85 with SMTP id d75a77b69052e-47214fcf268ls27199781cf.2.-pod-prod-04-us;
 Fri, 21 Feb 2025 02:18:17 -0800 (PST)
X-Forwarded-Encrypted: i=2; AJvYcCV+3/tTMOSmS64Sb43R4/8EH8e9qX3kpRpvZrVZugnh7OkPSxBNoLpMcGDSLQWMjpJfWhxU/hFa76XP@googlegroups.com
X-Received: by 2002:a05:620a:1a0a:b0:7c0:c175:e96d with SMTP id af79cd13be357-7c0ceee27b1mr335120985a.12.1740133097806;
        Fri, 21 Feb 2025 02:18:17 -0800 (PST)
Received: by 2002:a05:620a:229:b0:7c0:bbff:9f72 with SMTP id af79cd13be357-7c0c3017accms85a;
        Thu, 20 Feb 2025 14:11:33 -0800 (PST)
X-Forwarded-Encrypted: i=2; AJvYcCXiSfZfPHiHhHYp2H3ghKm5IeORQLlz+xBKj7LqLinntnPGq4LuQd55X4oWKFKhw1weMMnka8oGT9cn@googlegroups.com
X-Received: by 2002:a05:620a:4104:b0:7c0:b411:710c with SMTP id af79cd13be357-7c0cef72305mr122958685a.50.1740089493177;
        Thu, 20 Feb 2025 14:11:33 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1740089493; cv=none;
        d=google.com; s=arc-20240605;
        b=D+tYfopK/OwEdCZRiqHAPsQlCNaHZZdUL8kokMw0SuvAjjiR8TxUja8cfjLkS1YTbK
         frWUEM+aXgM78pUx9mL3g9DC11Wvzo3VV5wX/7Nc28FPpZiTxgGGLbBFdeKwdYZ+UGYw
         ma5IDHUUNE9LoxAa4oaCK75LS1vL8VzxnN0ODL6jBg7I7CxxJxLieoex05TEEnNrAq/b
         GtQ7iADvJ9IF5DegONCTiXcaNq/RDuX/yndN0WfPvR8lcvcFrwTjo4JRufBODF7WM6u5
         c9601JLSHurjqfavfj7JaW18QcCCy8AWiBmtNctY74TBMTtAmu8zw8LLiUPm+D6RLZ24
         ts/Q==
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=CmgmLUnsNFxRidXIQLyj9RNeyQ5DIfOkt5ZIQlSGsFg=;
        fh=hcqDlhfHQsGtLaEYlrnwkDWezRv3/z95KdJhX9TL5V4=;
        b=epyoe5xs4WxnRJ8HHDKYk5RXVAtwS3MsjmqoED+de9aiiqBnfq4LA0YgYFAyuqRoQJ
         gtpUf0pfzD1UdNxc+xyfl34TGG5AzD7oBWPKf5XZvxFKH827CBfJy94cYPkDK4IulFL0
         hDn7PoysLG7UQyRG4gYGxzEeyQ4YcAWF7VW02PMx2z8YcTJ5ft0nNPqPzpTC8wcYLJ1x
         C4o7AVvJJL0GTcAWnQqrNwQjQhzW7v2lnq78Rn/ja8ILtNxgePWC1ctCH+7Jc5XU+ch7
         OvwgQAF0tnSuKmMx/T55/vzRi0uROcpbBipgk2y+xQY3701IvkwirP57pCQ5iRBRnDiC
         XgLw==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@mattcorallo.com header.s=1740087662 header.b=lx7IRRUm;
       dkim=pass header.i=@clients.mail.as397444.net header.s=1740087665 header.b=FkFtYX5E;
       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 af79cd13be357-7c09bdd26f5si40043985a.4.2025.02.20.14.11.32
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Thu, 20 Feb 2025 14:11:33 -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 <lf-lists@mattcorallo.com>)
	id 1tlElX-0006KS-1X;
	Thu, 20 Feb 2025 22:11:31 +0000
Message-ID: <737fe7bb-4195-439f-87a9-b6fabd14eeea@mattcorallo.com>
Date: Thu, 20 Feb 2025 17:11:30 -0500
MIME-Version: 1.0
Subject: Re: [bitcoindev] P2QRH / BIP-360 Update
To: Hunter Beast <hunter@surmount.systems>,
 Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
References: <8797807d-e017-44e2-b419-803291779007n@googlegroups.com>
Content-Language: en-US
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <8797807d-e017-44e2-b419-803291779007n@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=1740087662 header.b=lx7IRRUm;
       dkim=pass header.i=@clients.mail.as397444.net header.s=1740087665
 header.b=FkFtYX5E;       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: <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 (/)

If we want to do something like this in the short to medium term, IMO we sh=
ould strip out all the=20
signature schemes that are anything more than quite straightforward in thei=
r security assumptions=20
(i.e. only keep hash-based signatures, maybe just SPHINCS+), only embed the=
m in a taproot leaf, and=20
call it a day.

BIP 32 compatibility isn't a really huge deal if we're talking about an "em=
ergency break glass"=20
kinda setup - most wallets are set up with a root key and can just embed th=
e same PQ pubkey in all=20
of their outputs. The privacy cost is only realized in a break glass case, =
and long before then=20
hopefully whatever we do today is replaced with something better, with the =
knowledge that we'll gain=20
on the way to "then". We'd still want to do it in an opcode so that we can =
do multisig, though.

Matt

On 2/19/25 10:40 AM, Hunter Beast wrote:
> Dear Bitcoin Dev Community,
>=20
>=20
> A bit over six months after introducing the P2QRH proposal (now BIP-360),=
 I'm writing to share=20
> significant developments and request additional feedback on our post-quan=
tum roadmap, and I'd also=20
> like to mention a potential P2TRH post-quantum mitigation strategy.
>=20
>=20
> First, now that there's a BIP number assigned, you can find the update BI=
P here:
>=20
> https://github.com/cryptoquick/bips/blob/p2qrh/bip-0360.mediawiki <https:=
//github.com/cryptoquick/=20
> bips/blob/p2qrh/bip-0360.mediawiki>
>=20
>=20
> The revised BIP-360 draft reflects substantial changes since initial publ=
ication, particularly=20
> regarding algorithm selection. While we originally considered SQIsign, it=
 has 15,000x slower=20
> verification compared to ECC [1]. If it takes 1 second to verify a fully =
ECC block, it would take 4=20
> hours to validate a block filled with SQIsign transactions. This has obvi=
ous and concerning DDoS=20
> implications.
>=20
>=20
> While it would take a long time to signmany thousands of SQIsign transact=
ions as well, the increased=20
> time needed to sign the transactions likely won=E2=80=99t affect the prac=
ticality of DDoS attacks-- another=20
> concern which has been brought to my attention. As such, I've decided to =
deprecate SQIsign from the BIP.
>=20
>=20
> It's worth mentioning because it was brought up in the PR, there's a new =
class of algorithms that=20
> support signature aggregation, but they generally result in signatures th=
at are still quite large.=20
> Chipmunk and RACCOON are good examples [2], [3]. I do expect that to impr=
ove with time. It might be=20
> worthwhile to shorten the list by making signature aggregation a requirem=
ent, so as not to regress=20
> too far from Schnorr signatures. That said, I think those capabilities sh=
ould be introduced in a=20
> separate BIP once they're more mature and worthwhile.
>=20
>=20
> Our current shortlist prioritizes FALCON for its signature aggregation po=
tential, with SPHINCS+ and=20
> CRYSTALS-Dilithium as secondary candidates. However, major technical chal=
lenges remain, particularly=20
> BIP-32 compatibility issues affecting xpub generation in watch-only walle=
ts, as detailed by=20
> conduition in another mailing list discussion [4], and also, how we shoul=
d handle multisig wallets.
>=20
>=20
> Additionally, I think it's worthwhile to restrict BIP-360 to NIST-approve=
d algorithms to maintain=20
> FIPS compliance. That's because HSMs such as those provided by Securosys =
already have support for=20
> all three algorithms [5], which is essential for secure deployment of fed=
erated L2 treasuries.
>=20
>=20
> Presently, for multisigs, we have a merkle tree configuration defined for=
 encumbering the output=20
> with multiple keys. While that's efficient, it's a novel construction. I'=
m not certain we should=20
> proceed with the merkle tree commitment scheme-- it needs more scrutiny. =
We could use a sort of P2SH=20
> approach, just modifying the semantics of OP_CHECKMULTISIG in a witness s=
cript to alias to public=20
> keys in the attestation. But that could introduce additional overhead in =
a signature scheme that=20
> already uses a lot more space. Without this, however, we do not yet have =
a way specified to indicate=20
> thresholds or a locking script for the attestation, as it is designed to =
be purposely limited, so as=20
> specified it is only capable of n/n multisig. I consider m/n multisigs to=
 be the single largest=20
> obvious omission in the spec right now. It definitely needs more thought =
and I'm open to=20
> suggestions. Perhaps two additional bytes at the top level of the SegWit =
v3 output hash could be=20
> provided to indicate PQC signature threshold and total, and those would b=
e hashed and committed to=20
> in the output, then provided in a field in the attestation once spent.
>=20
>=20
> While finalizing PQC selections, I've also drafted P2TRH as an interim so=
lution to secure Taproot=20
> keypath spends without disabling them, as Matthew Corallo proposes in the=
 aforementioned mailing=20
> list thread [4]. The P2TRH approach hashes public keys rather than exposi=
ng them directly,=20
> particularly benefiting:
>=20
>=20
> - MuSig2 Lightning channel implementations
>=20
> - FROST-based MPC vaults
>=20
> - High-value transactions using private pools that don't reveal the block=
 template
>=20
>=20
> For those interested, take a look at the draft BIP for P2TRH here: https:=
//github.com/cryptoquick/=20
> bips/blob/p2trh/bip-p2trh.mediawiki <https://github.com/cryptoquick/bips/=
blob/p2trh/bip-p2trh.mediawiki>
>=20
>=20
> I have my hands full with P2QRH advocacy and development and would prefer=
 to focus on that, but I=20
> wanted to introduce P2TRH in case that is attractive as the community's p=
referred solution-- at=20
> least for Taproot quantum security. The tradeoff is that it adds 8.25 vB =
of overhead per input, and=20
> key tweaking might have slightly less utility for some applications, and =
it also doesn't protect=20
> against short exposure quantum attacks as defined in BIP-360.
>=20
>=20
> Returning to P2QRH and what's needed to push it across the finish line...
>=20
>=20
> I still need to finish the test vectors. I'm implementing these using a f=
ork of rust-bitcoin and=20
> modeling them after Steven Roose's work on BIP-346. I've been told that's=
 not a blocker for merging=20
> the draft, but if it isn't merged by the time I'm finished, hopefully tha=
t will provide some=20
> additional impetus behind it.
>=20
>=20
> One concern Murch brought up is that introducing four new algorithms into=
 the network was too many--=20
> adding too much complexity to the network and to wallets and other applic=
ations-- and I agree.
>=20
>=20
> Hopefully this is addressed to some degree by removing SQIsign (especiall=
y in its current state=20
> lacking implementation maturity), and will help push the BIP below a cert=
ain complexity threshold,=20
> making it somewhat easier to review.
>=20
> I think it's still important to include multiple signature algorithm opti=
ons for users to select=20
> their desired level of security. It's not 100% certain that all of these =
algorithms will remain=20
> quantum resistant for all time, so redundancy here is=E2=80=A6 key.
>=20
>=20
> Another concern is that NIST level V is overkill. I have less conviction =
on this since secp256k1=20
> technically has 128 bits of security due to Pollard's rho attacks. But if=
 the intention was for 256=20
> bits of security, should level V security be the default? It's difficult =
for me to say. Perhaps both=20
> level V and level I implementations could be included, but this would be =
a deviation from the BIP as=20
> presently specified, which defaults to level V security. The disadvantage=
 of including level I=20
> support for each algorithm is that it essentially doubles the complexity =
of libbitcoinpqc.
>=20
>=20
> Ultimately, I hope the default of NIST V and selection of 3 mature NIST-a=
pproved algorithms=20
> demonstrate a focused, polished, and conservative proposal.
>=20
>=20
> At this point, the major call to action I would like to highlight is simp=
ly the need for more=20
> feedback from the community. Please review and provide feedback here: htt=
ps://github.com/bitcoin/=20
> bips/pull/1670 <https://github.com/bitcoin/bips/pull/1670>
>=20
>=20
> I look forward to feedback and opinions on P2QRH and P2TRH.
>=20
>=20
> P.S. I'll be advocating for BIP-360 at OP_NEXT in VA, btc++ in Austin, Co=
nsensus in Toronto, and BTC=20
> 25 in Las Vegas, and later this year, TABConf in Atlanta.
>=20
>=20
>=20
> [1] https://pqshield.github.io/nist-sigs-zoo
>=20
> [2] https://eprint.iacr.org/2023/1820.pdf
>=20
> [3] https://eprint.iacr.org/2024/1291.pdf
>=20
> [4] https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/7uu4dZNgAwAJ
>=20
> [5] https://docs.securosys.com/tsb/Tutorials/Post-Quantum-Cryptography/pq=
c-release-overview
>=20
>=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 <mailto:bitcoindev+unsubscribe@go=
oglegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoinde=
v/8797807d-e017-44e2-=20
> b419-803291779007n%40googlegroups.com <https://groups.google.com/d/msgid/=
bitcoindev/8797807d-=20
> e017-44e2-b419-803291779007n%40googlegroups.com?utm_medium=3Demail&utm_so=
urce=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/=
737fe7bb-4195-439f-87a9-b6fabd14eeea%40mattcorallo.com.