From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 14 Feb 2026 00:15:07 -0800 Received: from mail-oa1-f59.google.com ([209.85.160.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vrAny-0003nH-7X for bitcoindev@gnusha.org; Sat, 14 Feb 2026 00:15:07 -0800 Received: by mail-oa1-f59.google.com with SMTP id 586e51a60fabf-40ed978ce56sf12039286fac.1 for ; Sat, 14 Feb 2026 00:15:05 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1771056900; cv=pass; d=google.com; s=arc-20240605; b=IFaeKS0FP4iiasKv4XCQs6ki4pRJNEw6AbUNeEUHhbvHJgfwA52YDT56d8jTGWg3VV 43w1YLILtyxmRXgBtGi9Jt/yYBIwgLbLDPobsCzT0uAgJl8UcLkXmV+/jMldaYTu1tjE QCK0pVXfbxILgDCMgnCnArLd1AJWbLcK8Rdrol2J4jk1/oasObP/ZOoSfbvlV467tDsN jwDu6wGniP2OoCumBv8HmPuRVf7sPcJAu0LBa9j9+7IQFPXj7fts7b5ZoHwz262R7rKo /jrVsfaz0octxx69Wth+AIQ01EaZkZ2MazOCk6AzjPGjm/fMRMtx4604CV95y7U6sWgM 3S5Q== 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:reply-to:content-transfer-encoding :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=E/iQQYE91WqKGd+hiUC05GSWNsal/XCKD5ZRyfPoYIE=; fh=u83jAIJrec/PNEjD0wmnIdG8ReBMREIGl6meb5qBkss=; b=inbPHKkkTqpaF5gldgQSliLTzymhfmq86bkZ8PjOQNRVyx89YfL41IG3KgGdZD77Sv JoBdGFHM0/x6OTHBIc4Io9yUK+Z74M3UtZ/8pln/zfggpplQkgFow8mDp1hThBV1RpID hDVtkmsIXr2lHzausmmtIigHb80sYOvdXKFZoghqmndQ+mE55HGDTP9S0H3ohsKTQ3OK jN50Jy0NILYcUNKGwadLxr1QNjytUNPtvvg9rMgVjmiQ7m+a00ljBsbr3rVulMix8ViP BgOK0HANZjSN44JqyLfyFr+kF/Yl28pbT9JGxVnnNiecz1zJzdMibhg5+kqnvYalUBcZ 3XEA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=MhFKEcrY; spf=pass (google.com: domain of darosior@protonmail.com designates 109.224.244.122 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1771056900; x=1771661700; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender :content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:from:to:cc:subject :date:message-id:reply-to; bh=E/iQQYE91WqKGd+hiUC05GSWNsal/XCKD5ZRyfPoYIE=; b=fPgMaiFbI/qj7cbyMyHwiFrV0nYcM2KBCVRgw9Zqe++wXwZtjc4egM+Oq1uFXkwJOJ LAXjwo1Dcu7imYQwYqf0BnKJyBwxKW4j744O81868UTh9K++x1kDLxPIKo05Efw1sYua 8xUEZ2ZHy2KoRdau9SPM7qda7D/DQqiNKOWP7mxsd8B2TX+0ythK9XN8YIupx9QOueDc gvVJnYHbeILBjA4lh0DwQSzf/wP1YoqvvahHy/ImlVIdpNsbMc/IYtAdR1yrL5u2NCUA qdUX0ZOQDDVUsUhMmHIwaKT9gSDFq60Kx7OjDqSTpR/V/nOqLbb7xZsiTKt7W0EyP2BB 4uZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771056900; x=1771661700; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender :content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:x-beenthere :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=E/iQQYE91WqKGd+hiUC05GSWNsal/XCKD5ZRyfPoYIE=; b=mFPT5ySx0QpbbjwI3Qqgh1z4y7VzLZ7idxBcLp1Q9KOXt2ohRAa2GtonfAtqZIJgBY dnm4ekbWGv73rD2zlo9TPxLp1E9Ce3laIWFKv4/PDroVIeQIFA0xRoxVqN3B8QHlEPNb oDyO6w0BVLhPbPTnqbJTZVFetfL59lwkRH6LK9YHSJIuU26hkbz/QeMu8hXQac1BHbfU splkeJvB02M9s8QR7pJdCglB000oWcg9gafnkZyAzkMFxq6VtJSNuPw9jvWKgYWNFZRf zqQ+C/rjpdahPIPynxyKDvryRCpDMNgqDwVQdQ3QfW1FSgX/9DUO8AwbRmfmgbFoKT1d 525Q== X-Forwarded-Encrypted: i=2; AJvYcCXb1GN/u5w3edSo2CSBdm2Rmz+qYWk0aeLPAILmPVN1HqUB4bX5ycgTFTYvVqN76oqVHt/Aieuoul7i@gnusha.org X-Gm-Message-State: AOJu0YxWxe9goxR9A82KGbhnuviFXBEgqR/7WT4HhaeLPvsgqSxOvJpL MnR9faxrpatYTnOMqFB+14MB28XQaYl0adDykVUxejk9TmLJFNGsC7KV X-Received: by 2002:a05:6871:4308:b0:3ff:4ab3:941c with SMTP id 586e51a60fabf-40ef3e8f149mr2730834fac.40.1771056899687; Sat, 14 Feb 2026 00:14:59 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+HxIBJyRPGDCCHjmVU5fAzestZdUyjQla/1BEjP4ESbcg==" Received: by 2002:a05:6871:7bc6:b0:409:6e30:2d79 with SMTP id 586e51a60fabf-40eca34a61cls2545263fac.0.-pod-prod-07-us; Sat, 14 Feb 2026 00:14:55 -0800 (PST) X-Received: by 2002:a05:6808:6958:b0:45e:cbf6:31e3 with SMTP id 5614622812f47-4639f1dce8amr1687680b6e.42.1771056895347; Sat, 14 Feb 2026 00:14:55 -0800 (PST) Received: by 2002:a05:6808:2164:b0:463:a65d:b610 with SMTP id 5614622812f47-463a65db7b9msb6e; Fri, 13 Feb 2026 14:53:00 -0800 (PST) X-Received: by 2002:a05:6808:2f13:b0:45f:27e:5cb6 with SMTP id 5614622812f47-4639f06500fmr1895737b6e.19.1771023179756; Fri, 13 Feb 2026 14:52:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771023179; cv=none; d=google.com; s=arc-20240605; b=Purx1KYNeQaY7UKcMz1x2wrX95DWv3ed4KleG2XlmVkzeGfuDECSwr0UDcgcLko7wK RtmTith9H3H6mx8Sp6eZwFtRX5Ka0gqZbzmEu4b1nuA3OS26dhjybGqQfM1SX3W3962t LhPTKZY8TONX7FKIEIxN6IoqTvTcrfap6eUBoJk2JVQ7Ul2FfZHTBbaVQRIXIrwmQjEs mr5sRq7qmV0vT730QL/nbvWj5WkbDdbo+dlJEqROIQBd9iWatofOVIPskwOLEJXMDaPm 75MxvxQoBQWsQ1vzdwXFv+OPGz8YpKbNhpIhal6sSK8K5vO/tkspnJ1D3nVTkMGSgt8S HMcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:dkim-signature; bh=L6wJYYGrYiGSRGiwKuIzPIoDyX/QjsJSLrbO44UM5NQ=; fh=yqPa6DsFGpb4Mbwe0juFQ7VGAQVHWOmLFCyjtGfccmg=; b=JLEwsr38AeEXtMuAdJRwpESekW+B5RQ4kjCYW8MPtgi96TGXygymlGeLVAg+CRX+x5 aMKnyYCvzt7B1ZRHaLa4JHfJAeSBCl/lwWWbcGwRdYckKM8ULSBIX5ecGx75FaSy7Etu NdGzRvJMKx5Xe2tDisULi37VppE2IoVaX+Is/sVGVjSxwQydC9a51Cc7buXIoD1PANV4 HJemZ8iJ6yTHORRXJS3t5QV9cxwDdBTO0H/FPPU6XY7A0r5qju91zhi84B7gO856dWi8 IRdBnCgcd/WR5Y+TS/JsR+WpBC5m5uU6/+axmHAhNKryS5C4/p8FsJ3wkpFWU0ytx4rO ondQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=MhFKEcrY; spf=pass (google.com: domain of darosior@protonmail.com designates 109.224.244.122 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-244122.protonmail.ch (mail-244122.protonmail.ch. [109.224.244.122]) by gmr-mx.google.com with ESMTPS id 586e51a60fabf-40eaf083740si328939fac.4.2026.02.13.14.52.59 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Feb 2026 14:52:59 -0800 (PST) Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 109.224.244.122 as permitted sender) client-ip=109.224.244.122; Date: Fri, 13 Feb 2026 22:52:52 +0000 To: Light From: "'Antoine Poinsot' via Bitcoin Development Mailing List" Cc: bitcoindev@googlegroups.com Subject: Re: [bitcoindev] The limitations of cryptographic agility in Bitcoin Message-ID: In-Reply-To: <088b5efd-7ba5-48f1-97f6-eb5881f5fd14@app.fastmail.com> References: <088b5efd-7ba5-48f1-97f6-eb5881f5fd14@app.fastmail.com> Feedback-ID: 7060259:user:proton X-Pm-Message-ID: 7ec4a835aa42d3ff4d02cd4c9787442ac25141fa MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Original-Sender: darosior@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=MhFKEcrY; spf=pass (google.com: domain of darosior@protonmail.com designates 109.224.244.122 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: Antoine Poinsot Reply-To: Antoine Poinsot 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: -1.0 (-) Hi John, Without commenting on the (un)desirability of freezing vulnerable coins (i = largely share your concerns, but haven't yet formed an opinion of my own), i would like to sur= face one issue in part of your reasoning. You state: > A perhaps even more fundamental "collective assumption" of bitcoin users = is that "a redeem script > that was valid at the time that a UTXO was encumbered will always remain = valid". This is > fundamental to bitcoin's nature as p2p electronic cash. If users woke up = one day no longer able to > assume that their redeem scripts would remain valid, then they would not = be able to rely on > bitcoin to store value over time and the system would quickly collapse. T= hus, any proposal to > disable features in a way that freezes coins is a proposal to destroy bit= coin. That's quite the sweeping claim, but it's trivially incorrect, or it would = make any soft fork impossible. This is both disproven historically, since Bitcoin made previou= sly-valid redeem scripts invalid on at least 5 occasions (post Satoshi), and incompatible with many = soft fork proposal, including your own. As long as soft forks are tolerated, a degree of nuance needs to be introdu= ced to take into account reasonable expectations from users, and not disabling potentially-vulnerabl= e EC opcodes as opposed to upgrade hooks needs to be defended on its own merit rather than appealin= g to the destruction of Bitcoin. (And to be clear i think a strong case can be made in this regard,= this is not to be interpreted as an argument in favour of The Big Freeze.) Best, Antoine On Friday, February 13th, 2026 at 5:13 PM, Light w= rote: > Hi Pieter, >=20 > > A small note aside: you can argue that it is possible for people to > > store coins insecurely, like in an OP_TRUE script output, or with > > private keys that are made public. I don't think this possibility > > affects the point above, because it is not about what possibilities > > exist, but which approaches people are likely to / asked to adopt. > > Nobody is incentivized or encouraged to store coins in an OP_TRUE. >=20 > While it is true that "nobody is incentivized or encouraged to store coin= s in an OP_TRUE", I believe your argument is incomplete because it is missi= ng a more realistic mass-theft vector, which is that as of today approximat= ely 2.5 million BTC is held by less than two dozen centralized custodians.[= 1] These coins are at a real risk of theft, due to both private threat acto= rs e.g. thefts from MtGox, Bitfinex, and scores of others, as well as publi= c threat actors e.g. EO 6102.[2][3] >=20 > Despite this very real and large-scale theft risk, nobody is proposing th= at we freeze coins held on exchanges. And yet some people find this (freezi= ng coins) to be a reasonable response to the risk of cryptographic breaks (= approximately 6.5 millions coins at risk).[4][5] Curious! But I digress. >=20 > > This brings us to the question then how at all Bitcoin users can > > migrate to new cryptography, because we cannot assume that secp256k1 > > will last forever. And I think the answer is essentially that it > > requires the entire ecosystem to change their assumptions. This does > > not mean that adding a new opt-in cryptographic primitive is infeasible > > or a bad idea; it just means that adding FancySig as an option is > > changing the collective security assumption from "secp256k1 is secure" > > to "secp256k1 AND FancySig are secure" once FancySig gets adopted at > > scale, and the discussion about adding new primitives should be treated > > with the gravity that entails. And it means that disabling secp256k1 EC > > operations (or near-everyone migrating to FancySig, but I think that is > > unlikely) is the only way to change the collective security assumption > > from "secp256k1 AND FancySig are secure" to "FancySig is secure". > > > > Because of that, if CRQCs or other EC-breaks become reality, or just > > the fear about them becomes significant enough, I do believe that > > disabling EC opcodes will be necessary in any economically-relevant > > surviving chain, due to the millions of BTC that are unlikely to ever > > move. Note that I am *not* arguing that "Bitcoin" *will*, *should*, or > > even *can* do this, and I'm quite sure that the inherent confiscation > > required will make the result uninteresting to me personally. It may be > > that such disabling only happens in a fork that doesn't end up being > > called Bitcoin, or it may be that this happens only after a CRQC has > > been demonstrated to exist. Still, given a severe enough threat I think > > it is inevitable, and I think that this means we shouldn't worry too > > much about what happens in chains in which EC is not disabled while > > simultaneously EC is considered insecure: such chains will be worthless > > anyway. >=20 > I don't believe the predominant "collective security assumption" is that = "secp256k1 is secure". Everyone using bitcoin, going all the way back to th= e genesis block, has known (or should know) that secp256k1 is vulnerable to= a CRQC, and therefore secp256k1 is not unconditionally secure. So I would = rephrase the assumption to be that "secp256k1 is currently secure, and if i= t is ever at risk of being broken, there is a large incentive for a viable = alternative to be discovered, implemented, and adopted by anyone who is con= cerned about this risk". Note that this assumption does not, and cannot, pr= eclude the possibility that other users store their coins in insecure ways,= even en masse (as shown empirically by the above example of millions of co= ins held by centralized custodians). >=20 > An alternative where "secp256k1 OR FancySig is secure" seems strictly pre= ferable to me (assuming we have some reasonable degree of confidence in the= security of FancySig at the time of activation) than relying only on "secp= 256k1 is secure". >=20 > As an aside, I note that because it has been known since before bitcoin e= ven launched that secp256k1 is vulnerable to a CRQC, we cannot rule out the= possibility that the people who leave their coins in CRQC-vulnerable addre= sses -- even after QR addresses are made available -- aren't doing so inten= tionally, as a kind of bounty for developing a CRQC. Freezing these coins w= ould violate their intentions. This is just one example of the ethical prob= lems associated with such proposals. >=20 > A perhaps even more fundamental "collective assumption" of bitcoin users = is that "a redeem script that was valid at the time that a UTXO was encumbe= red will always remain valid". This is fundamental to bitcoin's nature as p= 2p electronic cash. If users woke up one day no longer able to assume that = their redeem scripts would remain valid, then they would not be able to rel= y on bitcoin to store value over time and the system would quickly collapse= . Thus, any proposal to disable features in a way that freezes coins is a p= roposal to destroy bitcoin. >=20 > Bitcoin can survive a temporary price dump, if that's what ends up happen= ing with vulnerable coins. Bitcoin cannot survive a violation of the fundam= ental assumption that redeem scripts for existing UTXOs will always remain = valid, and certainly not a violation at the scale that you describe. >=20 > Regards, > Light >=20 > [1] https://www.coinglass.com/Balance > [2] https://bitcointalk.org/index.php?topic=3D5090869.0 > [3] https://en.wikipedia.org/wiki/Executive_Order_6102 > [4] https://github.com/bitcoin/bips/pull/1895 > [5] https://youtu.be/a_B8BnwagEU&t=3D150 >=20 > On Fri, Feb 13, 2026, at 11:20 AM, Pieter Wuille wrote: > > Hi all, > > > > A thread was > > recently started on this list about cryptographic agility in Bitcoin. I > > believe there are important limitations around that idea, and wanted to > > offer my own perspective. It's more a philosophical consideration, and > > is not intended as an argument against (or for) any particular proposal > > today. > > > > The idea is giving users/wallets the ability to choose the > > cryptographic primitives used to protect their own coins, from a set of > > available primitives that may change over time. I think this ignores > > how important it is what *others do with their coins*. If others' coins > > lose value, for example due to fears about them becoming vulnerable to > > theft with cryptographic breakthroughs, so do your own due to > > fungibility, regardless of how well protected they are. > > > > As an extreme thought-experiment, imagine that tomorrow a new > > cryptographic signature scheme FancySig is published, with all the > > features that Bitcoin relies on today: small signatures, fast to > > verify, presumed post-quantum, BIP32-like derivation, taproot-like > > tweaking, multisignatures, thresholds, ... Further assume that within > > the next year or two, voices (A) start appearing arguing that such a > > scheme should be adopted, because it's the silver bullet the ecosystem > > has been waiting for. At the same time, another camp (B) may appear > > cautioning against this, because the scheme is new, hasn't stood the > > test of time, and isn't well-analyzed. These two camps may find > > themselves in a fundamental disagreement: > > > > =E2=80=A2 Camp (A), fearing an EC-break (CRQC or otherwise), wouldn't = just > > want FancySig as an option - they would want (feasible or not) that > > *near-everyone migrates to it*, because the prospect of millions of BTC > > in EC-vulnerable coins threatens their own hodling. > > =E2=80=A2 Camp (B), fearing the possibility that FancySig gets broken = soon, > > possibly even classically > > , > > don't want to just not use FancySig; they would want *near-nobody to > > migrate to it*, because the prospect of a potential break of FancySig > > threatens their own hodling. > > This is of course an extreme scenario, and in reality the divergence > > between camps may be much less incompatible, but I still think it's a > > good demonstration of the fact that *despite being a currency for > > enemies, Bitcoin essentially requires users to share trust assumptions > > in the cryptography, and its technology in general*. > > > > A small note aside: you can argue that it is possible for people to > > store coins insecurely, like in an OP_TRUE script output, or with > > private keys that are made public. I don't think this possibility > > affects the point above, because it is not about what possibilities > > exist, but which approaches people are likely to / asked to adopt. > > Nobody is incentivized or encouraged to store coins in an OP_TRUE. > > > > It is also good to ask what amounts are relevant here, to which I do > > not know the answer. Possibly, the prospect of 100k BTC becoming > > vulnerable to theft won't threaten the value of the other coins, while > > the prospect of 10M BTC becoming vulnerable may. Depending on where > > your belief about this lies, you may end up with very different > > conclusions. Still, to me it is clear that *some* threshold exists > > above which I would be uncomfortable with seeing that many coins move > > into an untrustworthy scheme, even if they are not my own coins. > > > > This brings us to the question then how at all Bitcoin users can > > migrate to new cryptography, because we cannot assume that secp256k1 > > will last forever. And I think the answer is essentially that it > > requires the entire ecosystem to change their assumptions. This does > > not mean that adding a new opt-in cryptographic primitive is infeasible > > or a bad idea; it just means that adding FancySig as an option is > > changing the collective security assumption from "secp256k1 is secure" > > to "secp256k1 AND FancySig are secure" once FancySig gets adopted at > > scale, and the discussion about adding new primitives should be treated > > with the gravity that entails. And it means that disabling secp256k1 EC > > operations (or near-everyone migrating to FancySig, but I think that is > > unlikely) is the only way to change the collective security assumption > > from "secp256k1 AND FancySig are secure" to "FancySig is secure". > > > > Because of that, if CRQCs or other EC-breaks become reality, or just > > the fear about them becomes significant enough, I do believe that > > disabling EC opcodes will be necessary in any economically-relevant > > surviving chain, due to the millions of BTC that are unlikely to ever > > move. Note that I am *not* arguing that "Bitcoin" *will*, *should*, or > > even *can* do this, and I'm quite sure that the inherent confiscation > > required will make the result uninteresting to me personally. It may be > > that such disabling only happens in a fork that doesn't end up being > > called Bitcoin, or it may be that this happens only after a CRQC has > > been demonstrated to exist. Still, given a severe enough threat I think > > it is inevitable, and I think that this means we shouldn't worry too > > much about what happens in chains in which EC is not disabled while > > simultaneously EC is considered insecure: such chains will be worthless > > anyway. > > > > -- > > Pieter > > > > > > > > -- > > 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/THqOJuI_s5C8B9jkklN73BB_Hz= b9SsiLM6BFp4zFP3zWQoRevKoLVspdwjwh8NxxYbXwv4v6ikpStguW-QEvef4WgBZ7AQDz00P0s= t91FMA%3D%40wuille.net > > . >=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= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/088b5efd-7ba5-48f1-97f6-eb5881f5fd14%40app.fastmail.com. >=20 --=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/= Jks1E9HcmXK_xrxh-yeqn-uTH6FVyGvVVowbDSr5h3C0-J_7s-8YKK4dlKO77YjQLXw8rean8p2= h6Feb72Qctky2xDLgxfZaJfFJiWwhWNg%3D%40protonmail.com.