diff options
| author | Matt Corallo <lf-lists@mattcorallo.com> | 2024-12-15 20:40:51 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@googlegroups.com> | 2024-12-15 17:53:20 -0800 |
| commit | 94567912d17978d195c77fc6ab19f1ca729d557a (patch) | |
| tree | 46cdc418f40436e1a57093d335a780c8cc55a8ba | |
| parent | 091346c79e97de3b5af2c28d7447b2d03909d088 (diff) | |
| download | pi-bitcoindev-94567912d17978d195c77fc6ab19f1ca729d557a.tar.gz pi-bitcoindev-94567912d17978d195c77fc6ab19f1ca729d557a.zip | |
Re: [bitcoindev] Trivial QC signatures with clean upgrade path
| -rw-r--r-- | a4/5fe8e83dfa83497ebfd946dc9c254e3c4f9454 | 389 |
1 files changed, 389 insertions, 0 deletions
diff --git a/a4/5fe8e83dfa83497ebfd946dc9c254e3c4f9454 b/a4/5fe8e83dfa83497ebfd946dc9c254e3c4f9454 new file mode 100644 index 000000000..4454d1522 --- /dev/null +++ b/a4/5fe8e83dfa83497ebfd946dc9c254e3c4f9454 @@ -0,0 +1,389 @@ +Delivery-date: Sun, 15 Dec 2024 17:53:20 -0800 +Received: from mail-ot1-f57.google.com ([209.85.210.57]) + by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 + (Exim 4.94.2) + (envelope-from <bitcoindev+bncBAABBB4Q725AMGQEFJL7FIY@googlegroups.com>) + id 1tN0IR-000450-NM + for bitcoindev@gnusha.org; Sun, 15 Dec 2024 17:53:20 -0800 +Received: by mail-ot1-f57.google.com with SMTP id 46e09a7af769-71e19cbf163sf2349593a34.1 + for <bitcoindev@gnusha.org>; Sun, 15 Dec 2024 17:53:19 -0800 (PST) +ARC-Seal: i=2; a=rsa-sha256; t=1734313993; cv=pass; + d=google.com; s=arc-20240605; + b=Ez0a+kTRArvuuGbiLeEp597tehMS3eM5bQizOSykYQ/Ohj1dk5vnytHIo6/nh+jxOc + T0k/un5wNzGLF4EdlrLM5l71kTK4aTn9Px/lpr+fJCxZ8C5ePgH9pmLwhbojZYetlyUt + Iro5ObAecrq5XNcoWsYwOGOGSHwThd9yKcn94GfF9kVTkfd+mA8cJAKGy+YZxuypzHfR + jYanIk6Lj0AJgcrnmoQxerKySF4Wi/YYP3gu11lpQDM0Ad/jIL3oyRCiKJbIdpQYMYFQ + J3I7pIwJmZ+pW+eTi9GiVsE1+YeHBSt8FaMg7xOfKPy66WZWfGyM0dBLem9ED2IsOrzj + TxsA== +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=g6pwOUShLF5mshiibm/+FEK+DSAPBJ8dE8yXcSHw8pE=; + fh=9OH8plYifeHhO77XjUn8Klgwp8FXCnxRl72EM4G27Wg=; + b=gDLoMifJ7rFdAho295h26oKOg6SCPYshYgWV2NvZ8uZT29FRtTJpc6peGdVRCS5HUy + NJhnYcheSaoSWnSDpjyqzz2GxTJRAu4HYAeuwQq1hsxG1mhU9l6wAaZ6MMuwZUYdBF8e + xgWeyIfvznivGbVmKw9OKv7RRvnfFRSo6gJ/7ECuEzZ19UB7a31TWsximbInB9BvnIMi + Q2dZV2tsyj0tAP0pFVNJithYnZCZy7zJ7HFR3PJirwwB2xcW5Dzy5h9a/VpOLy3BW/Hh + /k2K2KAX9CdaY7rxh8b+1t4Z3iPtjKGMGvrC3CVmsHSClB5PpgwbtTLkwX1gpuxju+oW + 0niQ==; + darn=gnusha.org +ARC-Authentication-Results: i=2; gmr-mx.google.com; + dkim=pass header.i=@mattcorallo.com header.s=1734312062 header.b=yEFTETwE; + dkim=pass header.i=@clients.mail.as397444.net header.s=1734312064 header.b="cFZ/3t81"; + spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.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=1734313993; x=1734918793; 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=g6pwOUShLF5mshiibm/+FEK+DSAPBJ8dE8yXcSHw8pE=; + b=W4Hq8dts9TbrzrbhNvFn1sS+fbVrCuUbVBcv0kie90qB0l9kgcO2yBm+BoQnLhqK8m + PFHOEgbXPRWkDSukaFGhmYizByEXG30LYUG49cTCSOeKPBLH08PbXTq6WzWahp5OKBKU + +HYV23gx7AxP+ncTQCIwWWZuWfQtEes8+xNzVIMBsz5AL0nUgCz0eIEv/er3b5NrHSNo + eWukpW4kaeUXbaDiXHHB4R7hzl5dlkU3yifq1NvuteGlagrHkVU6S88WDiV41uyWb4m+ + lT1a9qoIGvoA0N4+SzJRwbK/ZyFD+LUvcd4C6X7dJVkXLdvhRXaSlByLWp2ldc1/pspY + piUA== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20230601; t=1734313993; x=1734918793; + 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=g6pwOUShLF5mshiibm/+FEK+DSAPBJ8dE8yXcSHw8pE=; + b=uxad6DmQzTNTszVPAUlP8DbNxm4JmR0FV+PpaTwHWG4J35Qyzw7QFbumSyeDNu38yg + ExU4vM1tKuymI5B16oANqKkFps5snVSgScy2RcMACZawP2CQhQTBEBnJYSPiiGcmkyce + Pn2e7UXffK7T74Dcr+Oy72sdoTD11GmvoqR5X4YssoYqXjJHd+fy0z5IOWJRzbD0fuiG + sSjCxWlX1QQoDkgQFXespSSj6KhbvFO8PpHH6aTzXtkdaEwUe1SPwMDVWtm1V7O0j6+i + d/HrpYmMvB+FqJhR/+kbTbm9NiVY3VfPNo1zcoKMiO9OJ41T333ifB/Dq6TbfWoLsI4D + yf9w== +Sender: bitcoindev@googlegroups.com +X-Forwarded-Encrypted: i=2; AJvYcCWme76QsOI6flyhUxwLM18t43GmucqYSrya0YeMr/gbBCSsnfNRqkVQmkRP/zniWVLFPEQXK1GI+M6E@gnusha.org +X-Gm-Message-State: AOJu0YxFZ4mhFfZLFBgZvZZG1PwOsC8rn06EsKd4YmnbuZ6dc+AOnbL0 + jKj6xwdcCOquuoZKjVRcdKLqQuGjnYSxvSsWWVJ/2mUiD2fO/XeD +X-Google-Smtp-Source: AGHT+IE0LzAP6KfIE/YuegWXPxG7FqSp+lTNwGZ9zpGrGkW+dtO/JM+2QMuOXebvWm2+mw7/zaWU3w== +X-Received: by 2002:a05:6830:658a:b0:718:41b8:5d6d with SMTP id 46e09a7af769-71e3b924401mr5522400a34.24.1734313993173; + Sun, 15 Dec 2024 17:53:13 -0800 (PST) +X-BeenThere: bitcoindev@googlegroups.com +Received: by 2002:a4a:a84c:0:b0:5eb:5d64:a13a with SMTP id 006d021491bc7-5f32be36c91ls750377eaf.1.-pod-prod-08-us; + Sun, 15 Dec 2024 17:53:10 -0800 (PST) +X-Forwarded-Encrypted: i=2; AJvYcCXZ+maaCGNy/e3CklTtv5jh7sYYVqFEUBf5QfFlXoF1jRRE559hNukx11wdqGc7IL06gfhgJB4EJmkO@googlegroups.com +X-Received: by 2002:a05:6808:189e:b0:3e7:b9be:5267 with SMTP id 5614622812f47-3eba67f9605mr6651122b6e.6.1734313990766; + Sun, 15 Dec 2024 17:53:10 -0800 (PST) +Received: by 2002:a05:6808:87:b0:3eb:6ba8:8c6b with SMTP id 5614622812f47-3eba557dc6dmsb6e; + Sun, 15 Dec 2024 17:40:56 -0800 (PST) +X-Forwarded-Encrypted: i=2; AJvYcCWc98PuY63aN4O50tsqHd70u+sbl4PicY7Cj8O9NaXm+xCmthrBaQXBkQYslT2dntxd5jXwTD+O9+q8@googlegroups.com +X-Received: by 2002:a17:90b:388f:b0:2ee:f687:6adb with SMTP id 98e67ed59e1d1-2f28fb50333mr15585748a91.3.1734313255662; + Sun, 15 Dec 2024 17:40:55 -0800 (PST) +ARC-Seal: i=1; a=rsa-sha256; t=1734313255; cv=none; + d=google.com; s=arc-20240605; + b=ejhyU/P5ZE5CrITaUvzIxprvVhprFRBwZzbUtcaYFqyvAFJ0GEElUfFT+UhBS1wrWE + 34skAqnZNNuLZSzogBJq7Tqs0XE9HArU4DfHI2kMpDlAJaYMf7xdUwqlIqseTF5SnC8D + IG/XcM82/GRvxh1KGieyBzqbVSFmjwgdJGWXkj8PpMorVngT5t6VY2sNF+/5zy3SpED2 + wRsIiZwzyQqDgl5+m+xM0xj9D/ZqT8pbODmsYan4eRd5V0NdMpALjTsfSUPoAmTqQ/33 + Ftb5YcioISgurcbaV5s7MI/RWkOGvw3M2MTsR8Npu/igQdG/5IQOLII9Be2eSOUF5Dny + nqjA== +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=u5/Ww3vDB/Zj9GqKrr3UZiPpOtkPmUlWrpqKsty2npo=; + fh=L0c4C+rtLEgXu6eXDLK0k1+sjJVRuWCPwVfzB6xEq2s=; + b=T0ABzesN5++719YdbQ7BNZhFmjnqNQC+OENlgwp4nLtXrcOSSSPl2+q/cyVyvmZ1Kr + VH3RuvWoiuj7LnGXiSafp1cWiMi2uhCRnr6cyci5axsY4rPDm17p9VCcigkSk0pLxQBO + xydaksaCDThWtdWT2zI51HINPhoROblD6opMkcXkXJvpnedLVkC+iUszEbd9vrlYXtgd + jGC8cwtn9sP49MY2M/yCKtJ94BugJKx7QPzkw3OHusGlTpN6rD3/lC+8eUW2dWyXKfVd + FSR9KDIay+7ogLrDIrTtJfTXNn9kAj4iLrstFng4bQ5D1SQCOZuqLUkdbuZyp6Cavmxy + S9Qw==; + dara=google.com +ARC-Authentication-Results: i=1; gmr-mx.google.com; + dkim=pass header.i=@mattcorallo.com header.s=1734312062 header.b=yEFTETwE; + dkim=pass header.i=@clients.mail.as397444.net header.s=1734312064 header.b="cFZ/3t81"; + spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.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. [69.59.18.99]) + by gmr-mx.google.com with ESMTPS id 98e67ed59e1d1-2f2a1c41874si165719a91.0.2024.12.15.17.40.55 + for <bitcoindev@googlegroups.com> + (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); + Sun, 15 Dec 2024 17:40:55 -0800 (PST) +Received-SPF: pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) client-ip=69.59.18.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 1tN06P-006gC9-26; + Mon, 16 Dec 2024 01:40:53 +0000 +Message-ID: <2272e122-c252-48a4-989f-dcedfaadf9cd@mattcorallo.com> +Date: Sun, 15 Dec 2024 20:40:51 -0500 +MIME-Version: 1.0 +Subject: Re: [bitcoindev] Trivial QC signatures with clean upgrade path +To: Weikeng Chen <weikeng.chen@l2iterative.com>, + Bitcoin Development Mailing List <bitcoindev@googlegroups.com> +References: <c2684826-6c93-419b-9a96-c0f0a791c9ac@mattcorallo.com> + <52f3bfc0-9446-4400-bf7a-7e38e5777c56@dashjr.org> + <3b50081e-1a00-4d18-aee3-1cefde230a78n@googlegroups.com> +Content-Language: en-US +From: Matt Corallo <lf-lists@mattcorallo.com> +In-Reply-To: <3b50081e-1a00-4d18-aee3-1cefde230a78n@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=1734312062 header.b=yEFTETwE; + dkim=pass header.i=@clients.mail.as397444.net header.s=1734312064 + header.b="cFZ/3t81"; spf=pass (google.com: domain of + lf-lists@mattcorallo.com designates 69.59.18.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 (/) + +Please see the assumptions list in the OP: + + > (e) its not worth waiting on OP_CAT and the other more general script op= +code additions for this,=20 +as those seem stuck in bikeshed hell, not to mention questions around MEVil= + and Bitcoin's future=20 +abound. Further, doing this via dedicated opcode simplifies wallet adoption= +, which is likely to=20 +struggle already given the additional workload for wallet developers for no= + immediate user-facing=20 +features. + +As Luke notes, wallets should probably just start implementing this today a= +gainst a standard=20 +SPHINCS+ implementation. By the time they're ready to ship someone can pick= + a few constants for the=20 +"standard" and we won't have to discuss it further until/unless we get a QC= +. + +On 12/15/24 8:30 PM, Weikeng Chen wrote: +> I actually think this is a good reason to open OP_CAT because its ability= + to do general-purpose=20 +> covenants allow different parties to experiment their own PQ signature al= +gorithms before the Bitcoin=20 +> core settles on one of them (which I believe would take longer). +> OP_CTV does not enable it. It just needs to be a full transaction hash an= +d the ability to=20 +> reconstruct it. +>=20 +> If we think we will be able to add QC signatures in 3 years, then we don'= +t need to do that. +> But if we don't think it is easy to settle down on one QC signature, then= + it is better to let=20 +> everyone make their own decisions on PQ solutions. +>=20 +> It is okay to start with some less efficient but provably post-quantum al= +gorithm, for example,=20 +> Winternitz signatures in BitVM. +> With OP_CAT, the public key can be reduced into a single hash, 32 bytes. = +The signature would still=20 +> be 1KB. This is not too different from other PQ proposals. +> Verifying a Winternitz signature costs about 4KB in Bitcoin script. A maj= +or limitation of Winternitz=20 +> signatures is that it is one-time, and therefore the keys need to be prot= +ected in a very careful way. +>=20 +> Although this is still expensive and would better be handled by a native = +opcode, at least=20 +> MicroStrategy and institutions as well as many individuals can move their= + "long-term" wallet for=20 +> Bitcoin into PQ ones and provide enough time for Bitcoin core to decide o= +n a post-quantum algorithm,=20 +> ideally when one of them get mainstream adoption (e.g., replaced ECDSA an= +d RSA in web browsers). +>=20 +> Nevertheless, the major issue right now with PQ is only P2WSH can be "pos= +t-quantum" while P2TR is=20 +> not post-quantum. It may be necessary to have a P2TR new version where th= +e key route is removed=20 +> (script-only) or replaced with a PQ signature. +>=20 +> On Monday, December 16, 2024 at 8:01:55=E2=80=AFAM UTC+8 Luke Dashjr wrot= +e: +>=20 +> One thing to add: the post-QC script path does not require a softfork= + to +> commit to, as long as it is well-defined. So wallets could begin +> implementing this fallback immediately, without waiting for _any_ +> softfork activation, as soon as the spec is final. They _would_ need = +to +> guard the post-QC script as if it were itself a private key, which co= +uld +> be an issue for hardware wallets - but I suspect there's probably a w= +ay +> around that too... +>=20 +> On 12/15/24 4:42 PM, Matt Corallo wrote: +> > There's been a few rough ideas for QC robustness in the signature +> > scheme over Bitcoin transactions over the past many years, but man= +y of +> > them have a number of fairly major drawbacks. +> > +> > First, some base assumptions: +> > +> > (a) QCs that can break EC will take a while (probably closer to a +> > decade or two than a few years). This lines up with NSA and other +> > recommendations. We have time to upgrade, but we might consider ha= +ving +> > an option today for wallets to get QC security later. +> > (b) Its entirely possible that fundamental scaling constraints wil= +l +> > emerge and QCs that break EC simply won't ever be reality. We migh= +t +> > not want to bet on this, but its possible. +> > (c) We'll get some reasonable warning before QCs are there - QC +> > development requires immense resources, so much so that only a few +> > organizations in the world can afford to hire the talent required = +and +> > fund the lab. This type of development has and will likely continu= +e to +> > lead to announcements as progress continues, and we'll have a few +> > years warning as QCs get closer and closer. +> > (d) post-QC security assumptions (like Lattices and obviously +> > Supersingular Elliptic Curve Isogeny) are insufficient to secure c= +oins +> > today, and are bad candidates for inclusion in Bitcoin's consensus= + due +> > to the likelihood of future cryptography research. This implies th= +e +> > only candidates for post-QC signature security in Bitcoin's consen= +sus +> > today are hash-based signatures (basically SPHINCS/SPHINCS+). +> > (e) its not worth waiting on OP_CAT and the other more general scr= +ipt +> > opcode additions for this, as those seem stuck in bikeshed hell, n= +ot +> > to mention questions around MEVil and Bitcoin's future abound. +> > Further, doing this via dedicated opcode simplifies wallet adoptio= +n, +> > which is likely to struggle already given the additional workload = +for +> > wallet developers for no immediate user-facing features. +> > +> > +> > Given these assumptions, it seems ill-advised for wallets today to +> > start locking funds up in a way where they need to pay the on-chai= +n +> > footprint cost to get post-QC security for their transactions *tod= +ay*, +> > but given upgrade cycles in Bitcoin it also seems ill-advised to n= +ot +> > have some option for wallets to have "emergency" paths. +> > +> > Luckily, taproot provides a great way to build such a scheme! Beca= +use +> > taproot script-path spends are strongly-bound (the taproot script-= +path +> > hash t includes the internal key in its hash), a future QC could +> > determine the associated private key and script-path merkle root, = +but +> > it cannot forge an alternative script-path merkle-root. +> > +> > This provides a compelling hook for post-QC security - with the si= +mple +> > addition of an OP_SPHINCS (or equivalent post-QC non-one-time-use +> > (i.e. not Lamport/Winternitz) signature verification opcode, +> > functioning in much the same was OP_CHECKSIG works today), wallets +> > simply need to construct their taproot outputs to always contain a +> > script-path alternative spending condition. When QCs are becoming = +a +> > reality, key-path taproot spends could be disabled via soft-fork, +> > forcing spends to be done using the QC-secure path. +> > +> > This scheme obviously has the major drawback of non-upgraded funds +> > confiscation at the time of QC existence, but: +> > +> > (a) we could instead require explicit opt-in for this scheme. This= + has +> > the drawback of yet another on-chain fingerprint and would require= + a +> > new scriptPubKey format (but keeping the existing bech32m address +> > format, hopefully most wallets support that without any code chang= +es +> > today). Of course if we do, substantial quantities of Bitcoin whic= +h +> > are unlikely to ever be spent could lead to supply shock, severely +> > damaging Bitcoin's utility in other ways, +> > (b) alternatively, we could allow key-path spends for wallets whic= +h +> > prove the script-path is a NUMS point (via some new keypath+proof +> > spend variant). I doubt many wallets today bother committing to a = +NUMS +> > point for their taproot output pubkeys, so this would break existi= +ng +> > wallets, but it would allow for an opt-out scheme. +> > +> > This scheme has the incredibly nice property of not bloating exist= +ing +> > use-cases nearly at all (just one extra taproot script-path branch= +, +> > but that's not a huge deal generally). +> > +> > There's a few things to bike-shed on here, though - first of all +> > whether to require opt-in or provide an opt-out and secondly wheth= +er +> > to also fail any script-paths that hit an ECDSA signature validati= +on +> > (probably yes?). +> > +> > I assume this has been written up elsewhere but I couldn't find it= +. +> > Most of this is due to not_nothingmuch, I'm just writing it up her= +e +> > and taking credit for it. +> > +> > This doesn't address the questions around PoW in a post-QC world, = +of +> > course, but that likely isn't something that can be answered until= + we +> > see more practical limitations of QCs (eg what is the minimal late= +ncy +> > of a QC gate? If its particularly low, can we simply complexify +> > Bitcoin's PoW hash function in order to delay QC results far past = +when +> > traditional hardware is able to mine a block?) +> > +> > Matt +> > +>=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/3b50081e-1a00-4d18-=20 +> aee3-1cefde230a78n%40googlegroups.com <https://groups.google.com/d/msgid/= +=20 +> bitcoindev/3b50081e-1a00-4d18-aee3-1cefde230a78n%40googlegroups.com?utm_m= +edium=3Demail&utm_source=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/= +2272e122-c252-48a4-989f-dcedfaadf9cd%40mattcorallo.com. + |