From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 15 Apr 2026 12:00:28 -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 1wD5TP-00016E-GT for bitcoindev@gnusha.org; Wed, 15 Apr 2026 12:00:28 -0700 Received: by mail-oo1-f56.google.com with SMTP id 006d021491bc7-6826de8e284sf1231579eaf.0 for ; Wed, 15 Apr 2026 12:00:26 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1776279621; cv=pass; d=google.com; s=arc-20240605; b=VQ0spg3vB1mUNYRHWKKCMiwGOj5zkPDuoL8279GwFrdT4hB+n5JbP5ugN4sYxojgXR jGI4dlMsEwptwoZ897hIOubqWBmAI4zcfe9pF0A41veUEcmsYxv50AXlcFL7RraVQzBg ZvatQf5CDyE8speRKo+obE3urm280LUMA4mWUEsu74gNSGqBlahkslHXlw0P4FO0HEXn 1XcqP6fo/dfbWQZKFkEOvfRjwY113P8naYYd/i/fN6IZ7V2oBEXSXeAR6c/kAcMM2pb7 FuatuMz0f+2tNHdN02Dj4W2ugfAjYP/UTQJLc4yIUhmRmyaQ2L+5jji8hX5i4s27NEWw 4Afw== ARC-Message-Signature: i=3; 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:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature; bh=Ufwbg+vr7MQEAh8gpov2gNXt+UYHZ7TIk+w/aJG9V5U=; fh=c37NaK8i/Z/b8o53YMhVOZnzEe5ka6z97VvEvmYRZR0=; b=DXJuAlmR6/ynCU613YGdgPpnDXVUiHUgErVCy2GQ1J90QQ9GyEYio2sjQ43KijPeRW OEVogB3PRUIWT8/3EdjaSyQoX0zFAdtqA46mBMKjWUY/ehvtqSkqP6ZKLVH0d2JF/SB2 cfFxn4q2fjHO43hbyBiGxHBeXIIjn3neUNOJRTJxLDx8GE12eHWfbEv6xl+YhfHvQEwe FmWA+4/sLiaVU6SATi/p8ntW1egUmvWqBtHI9WKq4flR5hqcs3kRmIl86gVafr3OH5Kg 3C20ZyEuKBSx4JCoL2gxfV9llRAX4wT2z56/c5EvBdrEgKk3cPTJl3FR9UrNSM7HubnU 50OQ==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@q32-com.20251104.gappssmtp.com header.s=20251104 header.b=Eh1hpQWN; arc=pass (i=1); spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::52a as permitted sender) smtp.mailfrom=earonesty@gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1776279621; x=1776884421; 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:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=Ufwbg+vr7MQEAh8gpov2gNXt+UYHZ7TIk+w/aJG9V5U=; b=of19nI8poyDzvCfKs0eyCx85+EGdMtyKU40ecFV72cJLKlJ3FrpImZhy5x8Ncdwzt6 SAW9kcqNISg8mBPxydRdTSlvd4EjK5TJQ0K/LciGGLwl8GYeENWqoLQ/E2/whg0g2P0A cZERxYlreSi4Xh2eqV77P/3xXunBtJ/spyXw0cc6cZ668lxKlRdrM8mID7/VKLzkI7HR p+hSsmgZ186Rz3IdXUoklqvdP4HosvckyQWxbRSknBvDpREU0SAj2DZcjPgb5VeKPipa +ELd1rDGtRr87s14srquzygzp0D1fNUkrocb5KOxD0TQhe7mCUBjWQ+2t5eg4UIxuhCz WJwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776279621; x=1776884421; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=Ufwbg+vr7MQEAh8gpov2gNXt+UYHZ7TIk+w/aJG9V5U=; b=C5bDC6z58LwRdKrGUsPstP5SAZg5DN3JZyaAhY9nE/OV20nOt4x+4dtB9nOKkOAfvl k3bh3NIgi70VQmR/1qFnDWDDmyho8Gg8KpeyR+WzMJlojSvNPQFzzx0M38ke9g2xam+U pDFcGBgcd11Nt8DW0O/Ia9n+nlbUmmxpi5QCs5p2auOqUODp3qDaknFc8M+Ttclsso7K 80XM9tg7CSUT/eTkWv1jh8b76U97DeBapAadU7VL2cryxXMJv15OsuKT6yE0wsMXnVaq 5VvXY5ULg6vmIUNZwq3U7zwBB3x7P6+PwvX5/M2K7WzRDzIzZYAUJEwubEOt7fFO0tVo osjQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AFNElJ8ud2Fpawi0/0IKlxAJGkRYIdcsurxP9s9ChTSB4cBOjFy2LlVJ9SVcw6kmEHmFxwxkq6eXFjO7DzFi@gnusha.org X-Gm-Message-State: AOJu0YwMKkjJhumkO2zAQMj4rnrglx8D5g6SgHMZySNqusXiDHXirRgb pr/tE45Q3RLFGLaSLkwil044vwj2n+JeSQD9v2uoRrEYLCO8baa+OxHA X-Received: by 2002:a4a:d197:0:b0:67e:20bf:2ea4 with SMTP id 006d021491bc7-693266705d1mr908908eaf.0.1776279620749; Wed, 15 Apr 2026 12:00:20 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiLNeEg/eSYCHHPlBaAF90FA21BjfsjdBiToHTr87Xmxdg==" Received: by 2002:a05:6820:1c8d:b0:67b:f5b9:99d8 with SMTP id 006d021491bc7-694375efb95ls47355eaf.0.-pod-prod-02-us; Wed, 15 Apr 2026 12:00:14 -0700 (PDT) X-Received: by 2002:a05:6808:e8b:b0:467:ee:7a2f with SMTP id 5614622812f47-4789fc08fdamr11349427b6e.28.1776279614778; Wed, 15 Apr 2026 12:00:14 -0700 (PDT) Received: by 2002:a05:6504:6193:10b0:2e5:dca6:8eb2 with SMTP id a1c4a302cd1d6-2f72dbc87d8msc7a; Wed, 15 Apr 2026 11:09:10 -0700 (PDT) X-Received: by 2002:a2e:ab83:0:b0:38d:eb82:d80f with SMTP id 38308e7fff4ca-38e4bb57379mr76833291fa.0.1776276548228; Wed, 15 Apr 2026 11:09:08 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776276548; cv=pass; d=google.com; s=arc-20240605; b=HBPz9KfMjUXgXuDqM+SPv66YqS5U095YSIkhat/U/h+T+qZuhQRnRRVeIvrVSs5MF3 HbJ298mKvE+f4U//niA5LkRPLn+Ds2s1JKc9qyuU7RV6VbD8XNWsVif0Hu3iL2tSi3mq dTwTTe4OVKkntgutu3gwUVmVgxgW2wHwIuVoYNBbSo/r/uumaZKwuFxr5Y4u2bJqiQ6Q EUbNs04PHs1bg1jeS8kvi6kceCriXB5ksuGBLCmjATlGbobe82DOYlc5jyFWyUIqD5ZO vyBVvQ2dTtFOPs9nBVg9cm4IwG8MgOyU8Mm+nyfqUgdcSWiokSUc2dTqnP8WQCvqjfFG RY4w== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=krICI8sw5qlASH44h8e+M6PCJQaYCxkQLhrFqQDqhdI=; fh=xW8bxyqQYHE1uH3XvdCMfZVppoYs0vQZCdqgnVz97es=; b=jEG1UtAqBYSjHH4nLedMhCTaWDOkefjXuw6Yi3JAWixXOkEvtxDR6xGdKJw4/9CJUc Fb3d0/uMq+P43Nrhe/Qu8mdrmHx8JJ/6RrqXVGOgTCKdjlWBHh9W/7MlprGEpYeTAfJJ /iYN33JW2c4dQJ3Y8oiDANLTEwBJA/aTT8PZ5zw+NMCW/LIU0BomggMEPFjZ5kfHlf0J eXrSwUFDPrh+E44Fo+ddoybod78Pkat2U/YgzOf5UZ5Pnu0fA3bMnA+jowx8sPzT/qQU WNJjoUZvmwLY7EX/uXm6onDk8OSwcFUb4yoiJPQaGRErQ6jD1oAGK3Do8vUwwHpYqs0B d6Jg==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@q32-com.20251104.gappssmtp.com header.s=20251104 header.b=Eh1hpQWN; arc=pass (i=1); spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::52a as permitted sender) smtp.mailfrom=earonesty@gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com. [2a00:1450:4864:20::52a]) by gmr-mx.google.com with ESMTPS id 38308e7fff4ca-38e9e891435si490301fa.0.2026.04.15.11.09.08 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Apr 2026 11:09:08 -0700 (PDT) Received-SPF: pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::52a as permitted sender) client-ip=2a00:1450:4864:20::52a; Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-671a901584eso4823339a12.0 for ; Wed, 15 Apr 2026 11:09:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776276547; cv=none; d=google.com; s=arc-20240605; b=V1wtdAC74BUmsh6StFuUSeP/CagikbzrdG0hvKRT67MHAzwrEtxrWQ3UjpLIdEgScM wV5c9kUaXR3254guoJ3/avOUrPoDNZihzQbHwtLjNjJlbbwFbutNK07avNWxc6FjLnUB m4ATddfMjdyiWUqhfIxaKvJ6ktxc10jb8yeoi2Lf17iYKXRuJRRHu4UmqBIbYjtooYCf 3PwbdEGbwRGDSLP4njEy2s9PyMm3pWsY88LEqKx02RLdDV2pPYftCLi3SU0j+XrhuL7N pQCOsaNa6cMXi487+2aDWuRV4iSUVGbimYGkWXoTGRd470I6EBTPz7O5FD8MW6Lee4H/ KMyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=krICI8sw5qlASH44h8e+M6PCJQaYCxkQLhrFqQDqhdI=; fh=xW8bxyqQYHE1uH3XvdCMfZVppoYs0vQZCdqgnVz97es=; b=kA+jkEz8e6RS9HjmZ5ZM540l72im4RhoUC+YslgGxij7gMfntoCHB9D96qPaiXBXQv CgieGwCLjDP0CuOPwFmUogr72ZflqntHbQQMJ4jywB7rheu8nYZs20SoX4FQu2GFxJ4/ fymDB5TY8B/BfFVnnKKKEfTqLPYI7inQxZOaOrGAsSVnMNT7SXHa7gtin8qq0U25txVb 8PT8GXBW+Dgpx5auDmh4i+MELMial/MUrV1KUCBYWYejlnLlPItOibYKjDzvT9V5V+KO D0SF7+8mdKU0+AqSzZFTlRvPyHSEMVCrM3MoB3iTi2Ti3qjLoIkUnIAQ6HTvlx+wG5bG bUtg==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: AeBDietG0eDYbsJQ/C28u9ynRRTua/xc12oPlrfd0IDUufRBSSFpuN331n7WSUQkoq1 qexZTLg41GxUqDhYnETesmAXbZfLXAhP6nhAGzVW13yEA0uS2uN9t9lC7ClOGJCBXPzktE393wR Szy+5oHo6sTi6qWyNrDJawzD2m349aIXHV8VkVqk3A/eN9AogyCWnPMMhoIOe+8ZxHNofoILmdn boDCZJ/kEjH7TxuO8ET23HkJVoHLYfVlccEaYn0FgmHl872RSTF8ENGTWT62Bs1U8aLgRSQZD3N MCkZCntKpDUJPzd7BmHeZQsMUEbipwAb4vgPXbuDAqoGYj1mCik1xv9gxA/fsskIQXjUgugGp15 fnKyWNQ0iO8M= X-Received: by 2002:a17:907:94d5:b0:b97:1d24:c004 with SMTP id a640c23a62f3a-b9d724960f5mr1449379566b.21.1776276547003; Wed, 15 Apr 2026 11:09:07 -0700 (PDT) MIME-Version: 1.0 References: <05E6D06B-1F72-48F6-B4F3-0225675BCC1F@mattcorallo.com> In-Reply-To: <05E6D06B-1F72-48F6-B4F3-0225675BCC1F@mattcorallo.com> From: Erik Aronesty Date: Wed, 15 Apr 2026 11:08:55 -0700 X-Gm-Features: AQROBzAnbeyGNlfGlVQ726qprRQbi9DnwomwA542A9RBDc7gjd9r6lbT5hp59w4 Message-ID: Subject: Re: [bitcoindev] PQC - What is our Goal, Even? To: Matt Corallo Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000009b73e7064f839c5a" X-Original-Sender: erik@q32.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@q32-com.20251104.gappssmtp.com header.s=20251104 header.b=Eh1hpQWN; arc=pass (i=1); spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::52a as permitted sender) smtp.mailfrom=earonesty@gmail.com; dara=pass header.i=@googlegroups.com 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.7 (/) --0000000000009b73e7064f839c5a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes I agree, Matt. People are definitely talking past each other. To me "safe coin maximization at the expense of decentralization and proof" seems like the completely wrong goal in almost every way. I would like you to bear in mind that there is no reasonable way to a certain that someone is the owner of a coin unless they show proof of that private key. I think we all can agree there. And that with the theoretical magical quantum computers compromising private keys they will be no distinction between a coin holder and an attack. There is no possible ZKP that can fix this. I think the fundamental thing we need to do is provide sovereign and active users the ability to protect their personal coins. Opting into this protection will occur as the interested users determine that it needs to occur. This is the only sure way to prevent a premature optimization for a computing paradigm that may never exist Maximizing sovereignty Is the entire purpose of a decentralized and peer-to-peer protocol. Having decentralization and sovereignty be a secondary goal is like ignoring freedom of speech and then pretending to be a democracy. On Wed, Apr 15, 2026, 9:52=E2=80=AFAM Matt Corallo wrote: > Its become obvious in recent discussions that a large part of the PQC > discussion has people coming at it from very different fundamental goals, > and as a result the conversations often talk past each other without maki= ng > real progress. So instead of doing that more I'd like to write down what = I > think the actual, short-term goal *is*, what it it is not. > > Fundamentally, it seems to me the most reasonable goal is that we should > be seeking to increase the number of coins which are reasonably likely to > be secured by the time a CRQC exists. Put another way, we should be seeki= ng > to minimize the chance that the Bitcoin community feels the need to fork = to > burn coins by reducing the number of coins which can be stolen to the > minimum number [1]. > > This naturally means focusing on the wallets which are the *least likely* > to migrate or otherwise get themselves in a safe spot. Focusing on those > who are the most likely to migrate does almost nothing to move the needle > on the total number of coins protected, nor, thus, on the probability of = a > future Bitcoin community feeling the need to burn coins. Sadly, this > probably means the "top wallets" that are generally terrible at adopting > Bitcoin standards. Wallets which are the top listing on app stores like > (currently in the top few in my app store): Bitcoin.com, Trust Wallet, > Coinbase Wallet, Blockchain.com, etc. These wallets generally use a singl= e > static address (because anything else confuses their users and they get > additional support tickets for it!) and put very little time into Bitcoin= , > focusing instead on other tokens and integrations. > > A few non-goals: > > * To ensure that advanced setups have the absolute best in post-quantum > security. I don't see how this moves the needle on the above goal, and in > fact in many cases detracts from the above goal. Of course if we can > accomplish this without detracting from the top-line goal above, great. > > * To ensure we have the best possible design for the signature scheme > bitcoin will be using in a world where a CRQC exists and we've gotten pas= t > the mess. We'll almost certainly know a lot more about the security of > various schemes and have more options for how to approach the problem by > the point we're dealing with the mess of a CRQC being imminent, so it see= ms > like a fools errand to try to predict what we should build for this. But > even if we know no more then than we do today, likely ending up with > hash-based signatures as the scheme everyone uses, we'll almost certainly > be having conversations about additional witness discounts or increased > block sizes to compensate for the sudden increase in transaction sizes. > Maybe we would decide against such an increase, but there's no question > such a conversation would happen and it would be premature to have it tod= ay. > > Matt > > [1] Of course I believe that the lost coin pool is large enough that the > Bitcoin community will, almost without question, fork to disable insecure > spend paths and burn some coins in the process, but reducing the number o= f > coins burned to the absolute minimum is of course best for everyone. > > -- > 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 > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/05E6D06B-1F72-48F6-B4F3-0225= 675BCC1F%40mattcorallo.com > . > --=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/= CAJowKgLKkSrzKGZAe2sSgCafjKx_U%2BoWz%2B-FxSb%2BAtppAayQXA%40mail.gmail.com. --0000000000009b73e7064f839c5a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes I agree, Matt.=C2=A0 People are definitely talking pa= st each other.=C2=A0 To me "safe coin maximization at the expense of d= ecentralization and proof" seems like the completely wrong goal in alm= ost every way.

I would like yo= u to bear in mind that there is no reasonable way to a certain that someone= is the owner of a coin unless they show proof of that private key.=C2=A0 I= think we all can agree there.

And that with the theoretical magical quantum computers compromising= private keys they will be no distinction between a coin holder and an atta= ck. There is no possible ZKP that can fix this.

I think the fundamental thing we need to do is provid= e sovereign and active users the ability to protect their personal coins.= =C2=A0 Opting into this protection will occur as the interested users deter= mine that it needs to occur.=C2=A0 This is the only sure way to prevent a p= remature optimization for a computing paradigm that may never exist=C2=A0

Maximizing sovereignty Is= the entire purpose of a decentralized and peer-to-peer protocol.

Having decentralization and sover= eignty be a secondary goal is like ignoring freedom of speech and then pret= ending to be a democracy.=C2=A0





On Wed, Apr 15, 2026, 9:52=E2=80=AFAM Matt Co= rallo <lf-lists@mattcorallo.= com> wrote:
Its become obvio= us in recent discussions that a large part of the PQC discussion has people= coming at it from very different fundamental goals, and as a result the co= nversations often talk past each other without making real progress. So ins= tead of doing that more I'd like to write down what I think the actual,= short-term goal *is*, what it it is not.

Fundamentally, it seems to me the most reasonable goal is that we should be= seeking to increase the number of coins which are reasonably likely to be = secured by the time a CRQC exists. Put another way, we should be seeking to= minimize the chance that the Bitcoin community feels the need to fork to b= urn coins by reducing the number of coins which can be stolen to the minimu= m number [1].

This naturally means focusing on the wallets which are the *least likely* t= o migrate or otherwise get themselves in a safe spot. Focusing on those who= are the most likely to migrate does almost nothing to move the needle on t= he total number of coins protected, nor, thus, on the probability of a futu= re Bitcoin community feeling the need to burn coins. Sadly, this probably m= eans the "top wallets" that are generally terrible at adopting Bi= tcoin standards. Wallets which are the top listing on app stores like (curr= ently in the top few in my app store): Bitcoin.com, Trust Wallet, Coinbase = Wallet, Blockchain.com, etc. These wallets generally use a single static ad= dress (because anything else confuses their users and they get additional s= upport tickets for it!) and put very little time into Bitcoin, focusing ins= tead on other tokens and integrations.

A few non-goals:

* To ensure that advanced setups have the absolute best in post-quantum sec= urity. I don't see how this moves the needle on the above goal, and in = fact in many cases detracts from the above goal. Of course if we can accomp= lish this without detracting from the top-line goal above, great.

* To ensure we have the best possible design for the signature scheme bitco= in will be using in a world where a CRQC exists and we've gotten past t= he mess. We'll almost certainly know a lot more about the security of v= arious schemes and have more options for how to approach the problem by the= point we're dealing with the mess of a CRQC being imminent, so it seem= s like a fools errand to try to predict what we should build for this. But = even if we know no more then than we do today, likely ending up with hash-b= ased signatures as the scheme everyone uses, we'll almost certainly be = having conversations about additional witness discounts or increased block = sizes to compensate for the sudden increase in transaction sizes. Maybe we = would decide against such an increase, but there's no question such a c= onversation would happen and it would be premature to have it today.

Matt

[1] Of course I believe that the lost coin pool is large enough that the Bi= tcoin community will, almost without question, fork to disable insecure spe= nd paths and burn some coins in the process, but reducing the number of coi= ns burned to the absolute minimum is of course best for everyone.

--
You received this message because you are subscribed to the Google Groups &= quot;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/b= itcoindev/05E6D06B-1F72-48F6-B4F3-0225675BCC1F%40mattcorallo.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.co= m/d/msgid/bitcoindev/CAJowKgLKkSrzKGZAe2sSgCafjKx_U%2BoWz%2B-FxSb%2BAtppAay= QXA%40mail.gmail.com.
--0000000000009b73e7064f839c5a--