From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 19 Apr 2026 18:46:42 -0700 Received: from mail-oo1-f60.google.com ([209.85.161.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wEdii-0004Cr-Uy for bitcoindev@gnusha.org; Sun, 19 Apr 2026 18:46:42 -0700 Received: by mail-oo1-f60.google.com with SMTP id 006d021491bc7-68bf09fdb30sf2036098eaf.3 for ; Sun, 19 Apr 2026 18:46:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1776649594; x=1777254394; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=gUZByHl4T+a/8A6XuWreA/VMmdEY1vrIscUitTwJav8=; b=tmxR8c6uaY2EX/VI3k5Ty/VC+4Ph7CBsUd9hxSMAABruNMh9GQYtKlwEOg+jKGuHF7 x6mE+gFX6KzCVbp5yvKig8uLQp5lI2s6xKSYK1wDehrEhw1DGm4JpNHmZQgyexdZhgk5 j4Yq1IyHQDYW8SAU1ol4ThuGKTcbMvdZo6deRRy7uCJOE8s5xnYrteAlhVTTzR0u1/Hn iMBTTME5xO67R+UwdW9I76d3/nBHnfN1lAO7eibzG/4OR8V0O6Fj1Sv53SrZPs7eyeNP iUD/bQ/Z63dG5sqAJrtCaxUcDrT1fpfvx5+pN6jXgyvm2wYw49FdX1VS+a9qXWs+Lk4p Ro4g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776649594; x=1777254394; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=gUZByHl4T+a/8A6XuWreA/VMmdEY1vrIscUitTwJav8=; b=Ntr5SRtuwqcXHwdAhFIn3mbL2Cs0rwl75mJfq0czMsEhzEdwO3VjZ3pXGlzPlLpCOE Yx1c++LYvOWwaCKC+pB1imvPntie1VbVfZs4Wim+vNgshEIO6xfCjfR4q97pf6L8XMJW BkFWkj3K57K5vZPmIv3K1D579LbWIC6oOVQaqcNN+3UmWMP1baWaSUdDFE7XxIM+cYWH LWAZUETwIK2KaFl3Gt8fG8u3PtaesnxSk+MfwNs7qYNTPPI+iiQCi8dVmmVH7y7CyqaA stVvv2IOfP3RY1lVQ6W1S9YUaJUK4n+dVaeXt82yR0temI3DqY0y6Pohmon93o0RreMe 0idw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776649595; x=1777254395; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=gUZByHl4T+a/8A6XuWreA/VMmdEY1vrIscUitTwJav8=; b=USHfyR+yELCq28Rr3AAbR4kN1h2KBPP0QZdywd5ScjpFkot0bqcHjmjqauWyAFBfZ/ JKF0/8aa6fOme/8N5g5xj7WPAYaE+nHO1k0OnZMdSkObQ2kQRCEkWJnZg/YlRcL+uNw1 +HjuAVKg0bJK9L+C5uGSYZsruGQAeQUElAtX+dev8oO8SZG9a1Y5McnFsiNSsgQdlxQb xNGD/7XncZmh1AsOWcXFr9IqDew/Cd1qrsfeGg2U+E1MkdnxOadODNqEOMlT3snnwTzz tgORUDX0ZwqO8baBOEOboup9QAVMDy+y11i9HKBFv0zaU9Q4+1ZOXefEQ2oPT4hykTrM dorg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ9rs6QZhTtys+W5ZFVdhIYAS1PW4jOq8lqCmbOlORmW3m6AgcbFk9gu3x4tBTzOPYV/rioMqWAZ2mwu@gnusha.org X-Gm-Message-State: AOJu0Yy1mPrxvPIckrt59/5nD30zKrp652KCwZN/uKhJWJhGzJuze9Ct 7LI5wZddDdWmbyfFb9g4BZABZ9QaxsCKWufGFFR3sVcJcB8mhCHXAPkN X-Received: by 2002:a05:6820:8c3:b0:68a:19ca:1d8a with SMTP id 006d021491bc7-69462e216d0mr5948038eaf.12.1776649594495; Sun, 19 Apr 2026 18:46:34 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiKAdRC6yyFc2r0jWELaAmsOm3FHOhDXU+uIQE34TARj7Q==" Received: by 2002:a05:6870:648c:b0:41c:6ad4:3efb with SMTP id 586e51a60fabf-4280c60891cls1895232fac.1.-pod-prod-08-us; Sun, 19 Apr 2026 18:46:29 -0700 (PDT) X-Received: by 2002:a05:6808:4fe6:b0:467:2a6e:ada8 with SMTP id 5614622812f47-4799c9b035amr5799358b6e.25.1776649589098; Sun, 19 Apr 2026 18:46:29 -0700 (PDT) Received: by 2002:a05:690c:920d:b0:7b3:13f7:5f3a with SMTP id 00721157ae682-7b9ed96da01ms7b3; Sun, 19 Apr 2026 18:37:26 -0700 (PDT) X-Received: by 2002:a05:690c:4992:b0:7b3:edc7:9b8f with SMTP id 00721157ae682-7b9eccec11amr120682287b3.0.1776649045395; Sun, 19 Apr 2026 18:37:25 -0700 (PDT) Date: Sun, 19 Apr 2026 18:37:24 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: Subject: [bitcoindev] Re: PQC - What is our Goal, Even? MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_41996_1920318813.1776649044800" X-Original-Sender: antoine.riard@gmail.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.5 (/) ------=_Part_41996_1920318813.1776649044800 Content-Type: multipart/alternative; boundary="----=_Part_41997_1971299907.1776649044800" ------=_Part_41997_1971299907.1776649044800 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, > [1] Of course I believe that the lost coin pool is large enough that the= =20 Bitcoin community will, almost > without question, fork to disable insecure spend paths and burn some=20 coins in the process, but reducing > the number of coins burned to the absolute minimum is of course best for= =20 everyone. I think at this stage the bitcoin community is something like tens of=20 millions of human beings spread all over the world and coming from a multitude of horizons. I would take=20 the bet that if you go to ask them one by one they have would have no real idea about quantum risks, and= =20 about the "freeze or not freeze" controversy they would at best shrug at you. So using "totalizing"= =20 socioligcal abstractions like the "Bitcoin community" and rough guessing Pythia of Delphi-like what= =20 this "community" wishes can only look a bit presumptuous to me... The whole sale pitch of bitcoin for almost two decades, the one that people= =20 have argued at meetups, conferences, online forums, in the media, in documentaries, on IRC, twitch,= =20 even in long-form blog post [0] has been unconfiscatable and censorship-resistant money. Now, we= =20 would take the exact opposite viewpoint and go to evangelize that *actually* your coins could be now=20 massively confiscated or their spend usage be censored at the protocol-level...All in the name of loosely= =20 defined reasons and risks...? Sadly, I'm not smart enough to get it here. Cutting through cheap rhetoric, the way the original post is framed can=20 only lead to confusion and misunderstanding. By saying first the goal should be to increase the number of coins which=20 are going to be reasonably secure by the time of a CQRC exists, if it exist one day, period, and then=20 immediately it goes to reformulate the goal as diminishing the likeliness there is a wish among some community=20 stakeholders to freeze non-upgraded coins to finally say that the goal should be to prioritize the migrations= =20 of the structures of wallet the less likely to migrate. It's all very confusing and at the end a reader cannot say if the thesis=20 defended is: - a) to prioritize consensus upgrades to allow coins owners to migrate=20 their stacks to PQ safe schemes - b) to prioritize the discussion on "freeze or not freeze", its legitimacy= =20 or not among protocol experts - c) to prioritize the migration of wallet structures / services that might= =20 be slow to upgrade to PQ safe schemes About a), it sounds to me reasonable to care about the CQRC risk. After=20 all, the latest Nobel prize in physics was awarded for works on the foundations of quantum computing.= =20 It might turn all like the ether in the history of physics (i.e vaporware), though so far we're far to= =20 have reached a scientific consensus on the subject [1]. While adding PQ safe schemes at the consensus= =20 level is obviously coming with a price in term of implementation complexity, it's at least something=20 tangible one can argue for or against. We can then go to discuss all the varieties with EC-and-PQ safe schemes=20 [2], though notably going to argue on EC-and-PQ one has to assume that EC spend paths are never=20 completely disabled. About b), in my humble opinion, any argumentation that some coins must be= =20 "freeze" on the "price" is a chimera. As far as I know, none of the bitcoin "technical experts" supporting a=20 "freeze" is sitting on the board of the FED, the ECB, the PBOC or the BOJ, so there is no way trying to make=20 hand wawy estimation on a given price level as there is no leverage on the demand (or the mere global offer of=20 fiat money for a fixed amount of bitcoin). Speaking about technical risks on the long-term viability of the network,= =20 realistically I don't see them. Of course, one deep pocketed attacker could leverage the gains from CQRC exploitation= =20 to mount some categories of attacks against L2s [3], though motivated attackers can already gather the bitcoin amount= =20 sufficient to launch that kind of attacks. And I don't see attacks they could trigger on the base-layer, where they=20 would hold a significant asymmetrical advantage. If some are upset by the "no freeze" position, they're always free to go to= =20 launch their native PQ safe chain. About c) it's not very our responsibility that some platforms and services= =20 are more focus to chase the latest token mirages or whatever the ico of the day. All we can do is offering=20 convenient PQ safe cryptograpghic schemes and interface at the consensus levels, the earlier we can reasonably=20 deliver on, all consensus caveats apply and go to do the reasonable work of technical advocacy to explain how such=20 schemes are working, somehow. If they're too busy to care about upgrading their technical stack despite the numerous= =20 warnings on the subject, let's them burn. We're not religious missionaries and it's not our role to go to=20 morally reform their high time preferences economical incentives. Now, I do not wish to sound too much dismissive for the services operators= =20 and plateforms that have massive amounts of coins to manage, and for which the quantum risk and any price=20 fluctuation could be a real worry. My answer to this worry is you're free to go to buy paper insurance=20 coverage in the odds tof massive CQRC exploitations happening 10 or 20 years down the road. Top insurance=20 companies in the world are already able to insure one hundreds in the year earthquake or flood, political risks and= =20 civil unrests so it should be okay for them to go to insure a one hundred year quantum risk affecting=20 centralized services...[4] If we take the CQRC threat seriously, at least deserving some mitigation=20 work, personally I prefer to scratch my head on isogenies and lattices for practical schemes, rather than=20 wasting ourselvces with the "freeze" non-sense. The Poinsot take in the other thread calling to disentangle the two topics= =20 sounds a reasonable and balance viewpoint to me. At least that's my humble 2 sats. Best, Antoine OTS hash: 0b266a6f42311bc42c701073e243f69a2ae8ce2ac9b895efcf49f0dd36ec1a07 [0] https://bluematt.bitcoin.ninja/page9/ [1] A contrario, no scientific yet has got a Noble Prize for demonstrating= =20 the impossibility of a QC [2] In the case there is a cryptanalytic wreckage of the PQ safe but not=20 the EC one [3] https://ariard.github.io/sigsoverflow.html [4] And if you prefer the more cypherpunk way, it's likely you can achieve= =20 the same with some bitvm constructions, if it holds it's expressivity and security guarantees Le Wednesday, April 15, 2026 =C3=A0 5:51:57=E2=80=AFPM UTC+1, Matt Corallo = a =C3=A9crit : > Its become obvious in recent discussions that a large part of the PQC=20 > discussion has people coming at it from very different fundamental goals,= =20 > and as a result the conversations often talk past each other without maki= ng=20 > real progress. So instead of doing that more I'd like to write down what = I=20 > 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= =20 > be seeking to increase the number of coins which are reasonably likely to= =20 > be secured by the time a CRQC exists. Put another way, we should be seeki= ng=20 > to minimize the chance that the Bitcoin community feels the need to fork = to=20 > burn coins by reducing the number of coins which can be stolen to the=20 > minimum number [1]. > > This naturally means focusing on the wallets which are the *least likely*= =20 > to migrate or otherwise get themselves in a safe spot. Focusing on those= =20 > who are the most likely to migrate does almost nothing to move the needle= =20 > on the total number of coins protected, nor, thus, on the probability of = a=20 > future Bitcoin community feeling the need to burn coins. Sadly, this=20 > probably means the "top wallets" that are generally terrible at adopting= =20 > Bitcoin standards. Wallets which are the top listing on app stores like= =20 > (currently in the top few in my app store): Bitcoin.com, Trust Wallet,=20 > Coinbase Wallet, Blockchain.com, etc. These wallets generally use a singl= e=20 > static address (because anything else confuses their users and they get= =20 > additional support tickets for it!) and put very little time into Bitcoin= ,=20 > focusing instead on other tokens and integrations. > > A few non-goals: > > * To ensure that advanced setups have the absolute best in post-quantum= =20 > security. I don't see how this moves the needle on the above goal, and in= =20 > fact in many cases detracts from the above goal. Of course if we can=20 > accomplish this without detracting from the top-line goal above, great. > > * To ensure we have the best possible design for the signature scheme=20 > bitcoin will be using in a world where a CRQC exists and we've gotten pas= t=20 > the mess. We'll almost certainly know a lot more about the security of=20 > various schemes and have more options for how to approach the problem by= =20 > the point we're dealing with the mess of a CRQC being imminent, so it see= ms=20 > like a fools errand to try to predict what we should build for this. But= =20 > even if we know no more then than we do today, likely ending up with=20 > hash-based signatures as the scheme everyone uses, we'll almost certainly= =20 > be having conversations about additional witness discounts or increased= =20 > block sizes to compensate for the sudden increase in transaction sizes.= =20 > Maybe we would decide against such an increase, but there's no question= =20 > 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= =20 > Bitcoin community will, almost without question, fork to disable insecure= =20 > spend paths and burn some coins in the process, but reducing the number o= f=20 > coins burned to the absolute minimum is of course best for everyone. > --=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/= a146e52b-aac8-4fb9-8bcf-4cc9e58176a0n%40googlegroups.com. ------=_Part_41997_1971299907.1776649044800 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi,

> [1] Of course I believe that the lost coin pool is larg= e 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 of coins burned to the absolute minimum i= s of course best for everyone.

I think at this stage the bitcoin= community is something like tens of millions of human beings spread
a= ll over the world and coming from a multitude of horizons. I would take the= bet that if you go to ask
them one by one they have would have no rea= l idea about quantum risks, and about the "freeze or not
freeze" contr= oversy they would at best shrug at you. So using "totalizing" socioligcal a= bstractions
like the "Bitcoin community" and rough guessing Pythia of = Delphi-like what this "community" wishes
can only look a bit presumptu= ous to me...

The whole sale pitch of bitcoin for almost two deca= des, the one that people have argued at meetups,
conferences, online f= orums, in the media, in documentaries, on IRC, twitch, even in long-form bl= og
post [0] has been unconfiscatable and censorship-resistant money. N= ow, we would take the exact opposite
viewpoint and go to evangelize th= at *actually* your coins could be now massively confiscated or their
s= pend usage be censored at the protocol-level...All in the name of loosely d= efined reasons and risks...?
Sadly, I'm not smart enough to get it her= e.

Cutting through cheap rhetoric, the way the original post is = framed can only lead to confusion and misunderstanding.
By saying firs= t the goal should be to increase the number of coins which are going to be = reasonably secure
by the time of a CQRC exists, if it exist one day, p= eriod, and then immediately it goes to reformulate the
goal as diminis= hing the likeliness there is a wish among some community stakeholders to fr= eeze non-upgraded
coins to finally say that the goal should be to prio= ritize the migrations of the structures of wallet the less
likely to m= igrate.

It's all very confusing and at the end a reader cannot s= ay if the thesis defended is:
- a) to prioritize consensus upgrades to= allow coins owners to migrate their stacks to PQ safe schemes
- b) to= prioritize the discussion on "freeze or not freeze", its legitimacy or not= among protocol experts
- c) to prioritize the migration of wallet str= uctures / services that might be slow to upgrade to PQ safe schemes
About a), it sounds to me reasonable to care about the CQRC risk. After= all, the latest Nobel prize
in physics was awarded for works on the f= oundations of quantum computing. It might turn all like the
ether in t= he history of physics (i.e vaporware), though so far we're far to have reac= hed a scientific
consensus on the subject [1]. While adding PQ safe sc= hemes at the consensus level is obviously coming with
a price in term = of implementation complexity, it's at least something tangible one can argu= e for or against.
We can then go to discuss all the varieties with EC-= and-PQ safe schemes [2], though notably going to
argue on EC-and-PQ on= e has to assume that EC spend paths are never completely disabled.
About b), in my humble opinion, any argumentation that some coins must b= e "freeze" on the "price" is a chimera.
As far as I know, none of the = bitcoin "technical experts" supporting a "freeze" is sitting on the board o= f
the FED, the ECB, the PBOC or the BOJ, so there is no way trying to = make hand wawy estimation on a given price
level as there is no levera= ge on the demand (or the mere global offer of fiat money for a fixed amount= of bitcoin).

Speaking about technical risks on the long-term vi= ability of the network, realistically I don't see them. Of course,
one= deep pocketed attacker could leverage the gains from CQRC exploitation to = mount some categories of attacks against
L2s [3], though motivated att= ackers can already gather the bitcoin amount sufficient to launch that kind= of attacks.
And I don't see attacks they could trigger on the base-la= yer, where they would hold a significant asymmetrical advantage.
If so= me are upset by the "no freeze" position, they're always free to go to laun= ch their native PQ safe chain.

About c) it's not very our respon= sibility that some platforms and services are more focus to chase the lates= t
token mirages or whatever the ico of the day. All we can do is offer= ing convenient PQ safe cryptograpghic schemes
and interface at the con= sensus levels, the earlier we can reasonably deliver on, all consensus cave= ats apply and
go to do the reasonable work of technical advocacy to ex= plain how such schemes are working, somehow. If they're
too busy to ca= re about upgrading their technical stack despite the numerous warnings on t= he subject, let's them
burn. We're not religious missionaries and it's= not our role to go to morally reform their high time preferences
econ= omical incentives.

Now, I do not wish to sound too much dismissi= ve for the services operators and plateforms that have massive
amounts= of coins to manage, and for which the quantum risk and any price fluctuati= on could be a real worry.
My answer to this worry is you're free to go= to buy paper insurance coverage in the odds tof massive CQRC
exploita= tions happening 10 or 20 years down the road. Top insurance companies in th= e world are already able
to insure one hundreds in the year earthquake= or flood, political risks and civil unrests so it should be
okay for = them to go to insure a one hundred year quantum risk affecting centralized = services...[4]

If we take the CQRC threat seriously, at least de= serving some mitigation work, personally I prefer to scratch
my head o= n isogenies and lattices for practical schemes, rather than wasting ourselv= ces with the "freeze" non-sense.
The Poinsot take in the other thread = calling to disentangle the two topics sounds a reasonable and balance viewp= oint
to me.

At least that's my humble 2 sats.

Be= st,
Antoine
OTS hash: 0b266a6f42311bc42c701073e243f69a2ae8ce2ac9b= 895efcf49f0dd36ec1a07

[0] https://bluematt.bitcoin.ninja/page9/<= br />[1] A contrario, no scientific yet has got a Noble Prize for demonstra= ting the impossibility of a QC
[2] In the case there is a cryptanalyti= c wreckage of the PQ safe but not the EC one
[3] https://ariard.github= .io/sigsoverflow.html
[4] And if you prefer the more cypherpunk way, i= t's likely you can achieve the same with some bitvm constructions,
if = it holds it's expressivity and security guarantees

Le Wednesday, April 15= , 2026 =C3=A0 5:51:57=E2=80=AFPM UTC+1, Matt Corallo a =C3=A9crit=C2=A0:
Its become obvi= ous in recent discussions that a large part of the PQC discussion has peopl= e coming at it from very different fundamental goals, and as a result the c= onversations often talk past each other without making real progress. So in= stead 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 shoul= d 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 seekin= g 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 mi= nimum number [1].

This naturally means focusing on the wallets which are the *least likel= y* 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 probab= ly means the "top wallets" that are generally terrible at adoptin= g 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, Coinb= ase Wallet, Blockchain.com, etc. These wallets generally use a single stati= c address (because anything else confuses their users and they get addition= al 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 ac= complish this without detracting from the top-line goal above, great.

* To ensure we have the best possible design for the signature scheme b= itcoin will be using in a world where a CRQC exists and we've gotten pa= st 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 = seems 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 ha= sh-based signatures as the scheme everyone uses, we'll almost certainly= be having conversations about additional witness discounts or increased bl= ock 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 today.

Matt

[1] Of course I believe that the lost coin pool is large enough that th= e Bitcoin community will, almost without question, fork to disable insecure= spend paths and burn some coins in the process, but reducing the number of= coins 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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/a146e52b-aac8-4fb9-8bcf-4cc9e58176a0n%40googlegroups.com.
------=_Part_41997_1971299907.1776649044800-- ------=_Part_41996_1920318813.1776649044800--