From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 15 Apr 2026 00:55:52 -0700 Received: from mail-oa1-f56.google.com ([209.85.160.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 1wCv6F-0002KT-Fk for bitcoindev@gnusha.org; Wed, 15 Apr 2026 00:55:52 -0700 Received: by mail-oa1-f56.google.com with SMTP id 586e51a60fabf-41c08879ba3sf12095092fac.0 for ; Wed, 15 Apr 2026 00:55:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1776239745; x=1776844545; 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=e7WGJY+kEzCl7PMRtGGgIsxi2yv4/09XOfTvNJZBAGM=; b=n/9VmdLjcVHtNzwETaYFtgo6MuvR/Atr1TXXRlGBQcLoLBcFI6PD+V7W4fgQYJQOFk kWthUn/rQ9P6gK4d+1h9JQ1+mpA7RFOPvqupMrHdBZwqEjZWJQGs9YbhS2fc2pRnvczy PS/5FYox7vb79c9JVxfbGzsi9VJZE7wLd+Nl2JHXTCPv/fFfVjYERWzzOJ8XJlVPdujw E115rXpDtqQWYiRVIlANkp6GLaI7JW0fsjpI/wwP09EM+risWkCmJmmYaxzFj94tsgRI SxlY+6JkXPLnYQViJ2rmzAgcXwPAxPOsJA3IgPe86IcwT+VxXMTtn6UryZXhUB4TiQuV E4XA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776239745; x=1776844545; 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=e7WGJY+kEzCl7PMRtGGgIsxi2yv4/09XOfTvNJZBAGM=; b=MSR/DxpdKCgR7e3TYFJMnsg/rLxYbakKEAZb/wvyPaLBk5VFFl/eAHDWHwYUeLt1SL 5CcJmxJMFphD9eXWmUFiF+8U1Qksy11hLveLXH37dY8gz5P+yNzLF5akrBnS+pvk3H3Q 79Y6pfGU7TKkzXAFGOnclTWXrxEG1auDRTCDQ7qHwx6riHbxX9bZX6MCMLD9pSNIhm0Z t9Mq5ruDF6PBob2RCLVEdtIjKickai3miMwoetN/6gW0gk3hcVvbNofs2KHHHaD4xBmR ioOFdWv+iBZ/qMCdSEcVe1LSQakF69DzGHcRs3vaHLhs2+GITCSnT4hHnWwmYxWo/mWW UMjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776239745; x=1776844545; 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=e7WGJY+kEzCl7PMRtGGgIsxi2yv4/09XOfTvNJZBAGM=; b=rTOuZB/II87GWXjbLJtlyN+WmtiYzxhSS+ZlfoZ0LTczzwVBazIEfOvSYX0dspOvd2 bpNVPUk0ZPi9eQoHDxMO3W76s0TCYhegPjHZIC16aCrg5zkzauCZBdYCOKg4Hfv6Yisb s4/neSZj7XqpMvt6D+vkIdnF0oMH3gh0jC1xjIfalq6YkSedC/SRBW15kqjXg2juYZ1A jvYA7WthGBWXEHD2TzEpXGVtq0gUz4vN20Za84x0/E8kfRt396Ah5U7IX0vJ+E9yzzn4 YHiUSceWCIWE6RpyyrpF6yEeyl3NMHItDj/B3W2ke1cLHcaVoALHtkk9ngqTZ9iJWdOd q8Bw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ/83szZXQvgxE09CWNmU8H6E6nXpJYTL+Blr3jKaKNWvchDCMA4Vd6JGbbKjC9qI7qUbngrATuUCMhv@gnusha.org X-Gm-Message-State: AOJu0YxyT9DnG9XOE7z2cwh6WijeV5Uu1NDiJAe86a+Aj6hWnbpvDZQy mOd5p/mdHOJWmhL6Jm+rhbCNGszGS4/lRYL5e0VMjvxEsrjqv/oAXlgZ X-Received: by 2002:a4a:db93:0:b0:689:30ab:84e5 with SMTP id 006d021491bc7-68a6b830ca1mr9139188eaf.42.1776239745003; Wed, 15 Apr 2026 00:55:45 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiKJmyPX+zqgb9bT2JFDDvkScHymmuTb7Lyiut8+1yjoLg==" Received: by 2002:a05:6870:4d6:b0:423:73f9:2b3 with SMTP id 586e51a60fabf-4246f02f3c6ls129912fac.1.-pod-prod-00-us-canary; Wed, 15 Apr 2026 00:55:40 -0700 (PDT) X-Received: by 2002:a05:6808:4fe5:b0:45f:103c:2483 with SMTP id 5614622812f47-478b9b54f4cmr8732513b6e.23.1776239739922; Wed, 15 Apr 2026 00:55:39 -0700 (PDT) Received: by 2002:a05:690c:45ca:b0:7b3:9cd7:9641 with SMTP id 00721157ae682-7b70de5be94ms7b3; Tue, 14 Apr 2026 21:27:26 -0700 (PDT) X-Received: by 2002:a05:690c:397:b0:7a4:e4e5:390f with SMTP id 00721157ae682-7adee64055emr215904707b3.21.1776227246053; Tue, 14 Apr 2026 21:27:26 -0700 (PDT) Date: Tue, 14 Apr 2026 21:27:25 -0700 (PDT) From: Alex To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: Subject: Re: [bitcoindev] Deactivating ECDSA/Schnorr MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_159674_1263816765.1776227245665" X-Original-Sender: alexhultman@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_159674_1263816765.1776227245665 Content-Type: multipart/alternative; boundary="----=_Part_159675_1338194539.1776227245665" ------=_Part_159675_1338194539.1776227245665 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The leading "platform" for PQC is BIP360 and many invalidly assume its=20 disabling of key spend path means "deactivating Schnorr". That's NOT what= =20 the BIP does: * A new wallet address is ADDED (you optionally pay to it). Its existence= =20 does not freeze your coins in other wallets. * BIP360 disables key spend path; that is not actually disabling Schnorr it= =20 just moves Schnorr spends to script spend path. * In BIP360 you can still spend using Schnorr, you just need a few extra=20 bytes in the transaction since you now call upon an explicit OP-code rather= =20 than implicit key spend path. BIP360 just moves from always exposing your Schnorr public key, to only=20 exposing it if you actually choose to use it (that's why BIP360 is called= =20 Pay2MerkleRoot; it hides unused script leafs - and that is the key to=20 seamless transition from Schnorr to ) onsdag 15 april 2026 kl. 00:17:05 UTC+2 skrev Erik Aronesty: > ethereum is the best example of why "available but not enforced" is the= =20 > only path forward. > > it was wrong to claw-back those funds, especially since we don't even kno= w=20 > if someone *paid to access that key*. maybe vitalik and friend sold the= =20 > dao to someone in a drunken fit and then changed-his-mind > > being the arbitrator of "whether something was hacked" vs "whether it was= =20 > staged" is the role bitcoin can never be in. > > instead, we provide tools. and people can choose to use them or not use= =20 > them > > no amount of starks can help if someone steals my private key... it's my= =20 > word against theirs. quantum computing is irrelevant as the mechanism he= re. > > > > > > > On Tue, Apr 14, 2026 at 1:25=E2=80=AFPM conduition w= rote: > >> Hi Erik, >> >> Deactivating ECDSA/Schnorr based schemes should not be discussed=20 >> seriously. >> ... >> The worst possible thing we could do is confiscate everybody's coin and= =20 >> move to a NISD approved algorithm on the say so of large government fund= ed=20 >> organizations. >> >> >> You seem to be under the impression that a confiscatory soft fork would= =20 >> completely lock and freeze any and every coin that isn't on a PQ-safe=20 >> address. If so, you are mistaken. I don't think anyone would ever be so= =20 >> foolish as to deploy a soft fork that disables ECC spending without=20 >> introducing some set of rescue protocols to complement legacy ECC=20 >> spending rules.=20 >> >> I'd urge you not to think of such a fork as "disabling" ECC spending,=20 >> because that is not the entire picture. Instead think of it as=20 >> "restricting" ECC spending to a tighter set of rules which a quantum=20 >> attacker should not be able to abuse. Laolu's recent work on building=20 >> concrete BIP32 STARKs=20 >> is one such=20 >> awesome example of a tool which can do this - It works today and it cove= rs=20 >> every BIP32 wallet, even those with exposed pubkeys and xpubs. Though=20 >> personally I prefer commit/reveal for better scaling. >> >> There will probably be some non-zero subset of the UTXO set (whose=20 >> holders are alive and still have their keys) that cannot meet these=20 >> stricter conditions to satisfy the rescue protocol, and so cannot migrat= e.=20 >> These coins would indeed be confiscated. There is research needed to=20 >> quantify this, and it depends a lot on what rescue protocols can be=20 >> invented between now and Q-day, and on how many UTXOs we can reliably sa= y=20 >> are or aren't covered by each protocol. Today, we can confidently say th= at=20 >> any address derived via BIP32, or any hashed address which has an unexpo= sed=20 >> public key, can be rescued. Others are open problems. >> >> There is simply no credible way you can convince somebody who is=20 >> sovereign that their encryption algorithm is broken aside from breaking = it. >> >> >> I suspect many Bitcoiners agree, which is why any confiscatory soft fork= =20 >> which restricts ECC spending will probably only be triggered *after* a= =20 >> CRQC has been demonstrated concretely, e.g. by breaking the NUMS point, = or=20 >> spending satoshi's coins, or with a ZK-STARK that shows they *could* hav= e=20 >> spent satoshi's coins, or whatever canary mechanism we might dream up an= d=20 >> agree on. >> >> Personally I'd prefer to trigger it earlier rather than later, because w= e=20 >> have no reason to expect a CRQC to cooperate with our canary system, but= I=20 >> realize that might be a hard pill to swallow, so a canary would be a dec= ent=20 >> compromise as long as the community has the option to push a panic butto= n=20 >> and force-trigger the upgrade through majority hashrate consensus later,= to=20 >> cover the case of an adversarial CRQC who sidesteps our canary. >> >> Bitcoin is not a nanny state. >> "oh no someone might break satoshi's keys" >> Let them. if satoshi's 50 Bitcoin stash keys serve to be the bounty that= =20 >> propels humanity to a future of limitless unbounded magical computing th= at=20 >> is not a problem we need to solve right now. >> The worst possible thing we could do is confiscate everybody's coin and= =20 >> move to a NISD approved algorithm on the say so of large government fund= ed=20 >> organizations. >> >> That sounds dystopian at best. >> >> >> I appreciate your code-is-law purism, but there is an exception to every= =20 >> rule. >> >> Ethereum's DAO hack shows us what happens to those who commit to such=20 >> uncompromising fervor. Ethereum's devs had committed to code-is-law, and= =20 >> then faced a similar situation where a large fraction of their supply (o= ne=20 >> third of it, if my sources are correct) was at risk of immediate theft, = and=20 >> they could either stick to their principles and do nothing, or intervene= =20 >> and hard fork. The interventionist chain turned into ETH and the purist= =20 >> chain turned into ETC. Today, ETH is far more economically relevant than= =20 >> ETC, because their community recognized that *cruelty is not the ethical= =20 >> response to tragedy.* Users prefer not losing their coins to attackers,= =20 >> basically. They prefer to use technologies whose devs take steps to prev= ent=20 >> that sort of thing. ETC meanwhile has suffered a slow death, as devs and= =20 >> users migrate to greener pastures.=20 >> >> Their situation rhymes with ours, but is very different too. We can see= =20 >> our threat (CRQCs) coming from years away, and can prepare today to avoi= d=20 >> the need for a hard fork. So in a way, our prospects are more optimistic= ,=20 >> but our problem is also far harder to engineer around. It's not just a= =20 >> single bug we need to fix. It's the fact that our entire supply is=20 >> currently resting on a shaky assumption (the ECDLP is hard). When and if= =20 >> that assumption breaks, some significant fraction of coins will also be = at=20 >> risk, and we will be put to the same choice as the ETH devs were: Do we= =20 >> intervene and compromise our principles to reduce the fallout, or do we = do=20 >> nothing?=20 >> >> Personally, I think we should learn from the history of the ETH DAO hack= ,=20 >> and make the same choice the ETH devs did: intervene. We have options to= =20 >> mitigate the confiscatory effects of intervention, and we can do it with= out=20 >> a hard-fork. While I doubt the appetite exists to deploy any of this stu= ff=20 >> today, I suspect it will be someday when the threat looms larger. >> >> >> regards, >> conduition >> On Tuesday, April 14th, 2026 at 1:51 PM, Erik Aronesty = =20 >> wrote: >> >> Deactivating ECDSA/Schnorr based schemes should not be discussed=20 >> seriously.=20 >> >> You give people alternatives, yes. I'm a big fan of quantum optionality.= =20 >> >> But we cannot have a forced vaccination situation.=20 >> >> >> There is simply no credible way you can convince somebody who is=20 >> sovereign that their encryption algorithm is broken aside from breaking = it.=20 >> >> People can send to bad keys today. >> >> There are lots of op codes that let people shoot themselves in the foot= =20 >> >> Bitcoin is not a nanny state. >> >> "oh no someone might break satoshi's keys"=20 >> >> Let them. if satoshi's 50 Bitcoin stash keys serve to be the bounty that= =20 >> propels humanity to a future of limitless unbounded magical computing th= at=20 >> is not a problem we need to solve right now.=20 >> >> The worst possible thing we could do is confiscate everybody's coin and= =20 >> move to a NISD approved algorithm on the say so of large government fund= ed=20 >> organizations. >> >> That sounds dystopian at best.=20 >> >> >> >> >> >> >> >> --=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/CAJowKgJcGTvkzjkRN3cd8LRkfa= zWycSp8p6oOd5D5dtEYRaB1w%40mail.gmail.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/= a058151d-3134-47e5-96c7-3f79f6dab5b2n%40googlegroups.com. ------=_Part_159675_1338194539.1776227245665 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The leading "platform" for PQC is BIP360 and many invalidly assume its disa= bling of key spend path means "deactivating Schnorr". That's NOT what the B= IP does:

* A new wallet address is ADDED (you optional= ly pay to it). Its existence does not freeze your coins in other wallets.
* BIP360 disables key spend path; that is not actually disabling S= chnorr it just moves Schnorr=C2=A0spends to script spend path.
* = In BIP360 you can still spend using Schnorr,=C2=A0you just need a few extra= bytes in the transaction since you now call upon an explicit OP-code rathe= r than implicit key spend path.

BIP360 just move= s from always exposing your Schnorr public key, to only exposing it if you = actually choose to use it (that's why BIP360 is called Pay2MerkleRoot; it h= ides unused script leafs - and that is the key to seamless transition from = Schnorr to <insert whatever PQC that will be added later on>)
onsdag 15 a= pril 2026 kl. 00:17:05 UTC+2 skrev Erik Aronesty:
ethereum is the best = example of why "available but not enforced" is the only path forw= ard.

it was wrong to claw-back those funds, especially since we don&= #39;t even know if someone *paid to access that key*.=C2=A0 maybe vitalik= =C2=A0and friend sold the dao to someone in a drunken fit and then changed-= his-mind

being the arbitrator of "whether something was hacked&= quot; vs "whether it was staged" is the role=C2=A0bitcoin can nev= er be in.

instead, we provide tools.=C2=A0 =C2=A0and people can choo= se to use them or not use them

no amount of starks can help if someo= ne steals my private key... it's my word against theirs.=C2=A0 quantum = computing is irrelevant as the mechanism here.






On Tu= e, Apr 14, 2026 at 1:25=E2=80=AFPM conduition <condu...@proton.me> wrote:
Hi Erik,

<= /div>
Deactivating ECDSA/Schnorr based schemes should not be d= iscussed seriously.
...
The worst p= ossible thing we could do is confiscate everybody's coin and move to a = NISD approved algorithm on the say so of large government funded organizati= ons.

<= span style=3D"font-family:Arial,sans-serif">You seem to be under the impres= sion that a confiscatory soft fork would completely lock and freeze any and= every coin that isn't on a PQ-safe address. If so, you are mistaken.= =C2=A0I don't think anyone would ever be so foolish as to deploy a soft for= k that disables ECC spending without introducing=C2=A0some set of rescue protoc= ols to complement=C2=A0legacy ECC spending rules.
<= br>
I'd u= rge you not to think of such a fork as "disabling" ECC spending, = because that is not the entire picture. Instead think of it as "restri= cting" ECC spending to a tighter set of rules which a quantum attacker= should not be able to abuse.=C2=A0Laolu's recent work on building concrete BIP32 STARKs=C2=A0is one such awesome example of= a tool which can do this - It works today and it covers every BIP32 wallet= , even those with exposed pubkeys and xpubs. Though personally I prefer com= mit/reveal for better scaling.
<= div>
There will probably be some non-zero subset of the UTXO set (whose holder= s are alive and still have their keys) that cannot meet these stricter cond= itions to satisfy the rescue protocol, and so cannot migrate. These coins w= ould indeed be confiscated. There is research needed to quantify this, and = it depends a lot on what rescue protocols can be invented between now and Q= -day, and on how many UTXOs we can reliably say are or aren't covered b= y each protocol. Today, we can confidently say that any address derived via= BIP32, or any hashed address which has an unexposed public key, can be res= cued. Others are open problems.

There is simply no cr= edible way you can convince somebody who is sovereign that their encryption= algorithm is broken aside from breaking it.
<= div style=3D"font-family:Arial,sans-serif;font-size:14px">
I suspect many Bitcoiners agree, which is why any con= fiscatory soft fork which restricts ECC spending will probably only be trig= gered after=C2=A0a CRQC has been demons= trated concretely, e.g. by breaking the NUMS point, or spending satoshi'= ;s coins, or with a ZK-STARK that shows they could=C2=A0have spent satoshi's coins, or whatever canary mechani= sm we might dream up and agree on.

Personally I'd prefer to= trigger it earlier rather than later, because we have no reason to expect = a CRQC to cooperate with our canary system, but I realize that might be a h= ard pill to swallow, so a canary would be a decent compromise as long as th= e community has the option to push a panic button and force-trigger the upg= rade through majority hashrate consensus later, to cover the case of an adv= ersarial CRQC who sidesteps our canary.

Bitcoin is not a= nanny state.
"= ;oh no someone might break satoshi's keys"
Let them. if satoshi's 50 Bitcoi= n stash keys serve to be the bounty that propels humanity to a future of li= mitless unbounded magical computing that is not a problem we need to solve = right now.
Th= e worst possible thing we could do is confiscate everybody's coin and m= ove to a NISD approved algorithm on the say so of large government funded o= rganizations.
Th= at sounds dystopian at best.

I appreciate your code-is-law purism, but there is an exception to = every rule.

Ethereum's DAO hack show= s us what happens to those who commit to such uncompromising fervor. Ethere= um's devs had committed to code-is-law, and then faced a similar situat= ion where a large fraction of their supply=C2=A0<= /span>(one third of it, if my = sources are correct) was at risk of immediate theft, and they could either= stick to their principles and do nothing, or intervene and hard fork. The = interventionist chain turned into ETH and the purist chain turned into ETC.= Today, ETH=C2=A0is far more=C2=A0economically=C2=A0relevant than ETC, because their community rec= ognized that cruelty is not the ethical response to tragedy.=C2=A0Us= ers prefer not losing their coins to attackers, basically. They prefer to u= se technologies whose devs take steps to prevent that sort of thing. ETC me= anwhile has suffered a slow death, as devs and users migrate to greener pas= tures.

Their situation rhymes with ours= , but is very different too. We can see our threat (CRQCs) coming from year= s away, and can prepare today to avoid the need for a hard fork. So in a wa= y, our prospects are more optimistic, but our problem is also far harder to= engineer around. It's not just a single bug we need to fix. It's t= he fact that our entire supply is currently resting on a shaky assumption (= the ECDLP is hard). When and if that assumption breaks, some significant fr= action of coins will also be at risk, and we will be put to the same choice= as the ETH devs were: Do we intervene and compromise our principles to red= uce the fallout, or do we do nothing?

Personally, I think we should learn from the history of the ETH DAO hack,= and make the same choice the ETH devs did: intervene. We have options to m= itigate the confiscatory effects of intervention, and we can do it without = a hard-fork. While I doubt the appetite exists to deploy any of this stuff = today, I suspect it will be someday when the threat looms larger.


regards,
conduition
On Tuesday, April 14th, 2026 at 1:51 PM, Erik Aronesty <er...@q32.com> wrote:
Deactivating ECDSA/Schnorr = based schemes should not be discussed seriously.
<= br>
You give people alternatives, yes. I'm a big= fan of quantum optionality.

But we cannot have a forced vaccination situation.


There is simp= ly no credible way you can convince somebody who is sovereign that their en= cryption algorithm is broken aside from breaking it.

People can send to bad keys today.

There are lots of op codes that le= t people shoot themselves in the foot

Bitcoin is not a nanny state.

"oh no someone might break satoshi's keys&quo= t;

Let them. if satosh= i's 50 Bitcoin stash keys serve to be the bounty that propels humanity = to a future of limitless unbounded magical computing that is not a problem = we need to solve right now.

The worst possible thing we could do is confiscate everybody's coi= n and move to a NISD approved algorithm on the say so of large government f= unded organizations.

Tha= t sounds dystopian at best.







<= /div>

--
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 bitc= oindev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= CAJowKgJcGTvkzjkRN3cd8LRkfazWycSp8p6oOd5D5dtEYRaB1w%40mail.gmail.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.com/d/msgid/bitcoind= ev/a058151d-3134-47e5-96c7-3f79f6dab5b2n%40googlegroups.com.
------=_Part_159675_1338194539.1776227245665-- ------=_Part_159674_1263816765.1776227245665--