From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 06 Jun 2026 15:24:33 -0700 Received: from mail-oo1-f58.google.com ([209.85.161.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wVzRQ-0003ar-Dk for bitcoindev@gnusha.org; Sat, 06 Jun 2026 15:24:33 -0700 Received: by mail-oo1-f58.google.com with SMTP id 006d021491bc7-69e3464b1afsf4465407eaf.0 for ; Sat, 06 Jun 2026 15:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1780784666; x=1781389466; 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=aKiYWcVNpOEGQSPNv5GFNHSYu7ZWuCRB0sjFgVBbvb8=; b=Em4n1NcnogL8k2Y1hB7vQYkJqgZ7tixtFptVPM7/eDswt35CbwmBP1WSkr7N4iPDNI NkDQJClIs8eM1u3gWl9GQUTPRz1C5bNy8jO5PJtSYCqlBq0XOOO9I6cEZh/6uHkiQAEv +WV58Va973Az/BUCEef4aAyMDeOQfWS6jPvfjzLhnQDYPwb8zPlrAm7v43txObtXSQIG HQDnYH1BQo5x8n9Gu26qa8cA4HW0pP9hKUTZ1vnoMw83Gxkkpy8XvAIvMgNfKvgcYEtQ zTdKKzLygc1j9JUVqkBakq7SNwid7gZ/b8K7KRIsMNOA2mY6lAdK6UrUhWDL5ES3HASU vkzQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780784666; x=1781389466; 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=aKiYWcVNpOEGQSPNv5GFNHSYu7ZWuCRB0sjFgVBbvb8=; b=YTbAUdl+V47w+SV5KuSxFLdHbmdb+9eKWnFNWE5phmoRL2bW9Bl0pYAQO5ApBO/jHs rGOBSC+OyDKjNrb3wkLAfY09EP5JK6EZ7ZoWTocrXj3dlweWhwoRElOX+nL48C+CjGnI 6iDfYD0n1Qfv3nLRfreetZzgTf4wSRnlUd7IVy9zHsxO7EO+Ppos0sEwILu893PEE3jN +U37sz1bGq7YLpbhS5oVPGcRUYxleONcSfSOlzCAURlZyKMUC7VmnugbCIpd0C9BhHZp N1hoToYxc/mnFDj9WLChS8jwd8FOsHA8rWiYONY3LzNl1gl4tfioEbHPM9pgKDPOWmRF kN8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780784666; x=1781389466; 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=aKiYWcVNpOEGQSPNv5GFNHSYu7ZWuCRB0sjFgVBbvb8=; b=ol1UBwqNPi2BGjZYYrWi6SK93W1XOdIjXcNIPCmG8H87OZnqGIYVVg6/YoDIC/wPx/ YSuBCbooSUayqODDMF04iYjmf2jH8tcELKnUWDzGwEc8mqWGLqYnG5BJ0mmr9ek5Z5d4 czMsWWwkZOlCeB8yPuUQIGf2IfEsL3JQiCqGS+wSl1XmvmxMy9JIA97kTvUd8S/ZG/VG 5C/0bEhF9vewAJxkdg2794+3l7WjpYlciD++3sPPk7A4l6kKSzFZpG5BLPW6+Ua+tF8X FKKpSLcFp60ZuOohN1SlX6MBIcjwRKGEzDl9XMeA1xFhKXlHmvfrJoARm4Yx4KH90Tpr gCYA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ8m1X5fjVtonJf2c2cZfIXdCso0Wu5cqgdnRI26rXHZi3n/i2AHn0kmcmb/vb3j2V99w2egDOW9psB+@gnusha.org X-Gm-Message-State: AOJu0Yy5jhq16etzlGfJiBFQzv1flOAaJ9VQKGFJvfiZyRfYz3eAp6HO 1D3DXEdY4uVI2fb8++ctwDmBEChZ+lohcRZw4XF7S5xqoGbOI3ZfMq+D X-Received: by 2002:a05:6820:81cd:b0:69e:158c:8998 with SMTP id 006d021491bc7-69e68c0609amr5284821eaf.38.1780784666156; Sat, 06 Jun 2026 15:24:26 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUenA9gyQtetxf/UDOJyhjwqpLHV+FPAmj1OTBVSaBdoAA==" Received: by 2002:a05:6871:73aa:b0:43d:16cf:84ea with SMTP id 586e51a60fabf-44109a55694ls2017338fac.1.-pod-prod-06-us; Sat, 06 Jun 2026 15:24:21 -0700 (PDT) X-Received: by 2002:a05:6808:1825:b0:486:7b58:3874 with SMTP id 5614622812f47-4868def5783mr6601813b6e.41.1780784661455; Sat, 06 Jun 2026 15:24:21 -0700 (PDT) Received: by 2002:a05:690c:c1e:b0:7ba:f5aa:4ab8 with SMTP id 00721157ae682-7ed27751347ms7b3; Sat, 6 Jun 2026 15:12:47 -0700 (PDT) X-Received: by 2002:a05:690c:883:b0:7dc:61c7:5929 with SMTP id 00721157ae682-7ed0d1d52c7mr103191837b3.14.1780783966854; Sat, 06 Jun 2026 15:12:46 -0700 (PDT) Date: Sat, 6 Jun 2026 15:12:46 -0700 (PDT) From: Boris Nagaev To: Bitcoin Development Mailing List Message-Id: <26684d8a-cdb3-43dd-a5b4-fc607ed95e8bn@googlegroups.com> In-Reply-To: References: Subject: Re: [bitcoindev] Aligning privacy incentives in P2MR MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_91690_1329493957.1780783966223" X-Original-Sender: bnagaev@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_91690_1329493957.1780783966223 Content-Type: multipart/alternative; boundary="----=_Part_91691_1247968547.1780783966223" ------=_Part_91691_1247968547.1780783966223 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Antoine, Conduition, Pieter, and list, I want to share my proposal for EC public key recovery in P2MR (BIP-360).= =20 It saves 35 bytes in the witness by removing the witness element that=20 contains the script. https://delvingbitcoin.org/t/public-key-recovery-for-ec-leaves-in-p2mr-bip-= 360/2603=20 Best, Boris On Saturday, June 6, 2026 at 1:00:08=E2=80=AFPM UTC-5 Pieter Wuille wrote: Hi Conduition, Some comments inline below. On Friday, June 5th, 2026 at 6:59 PM, 'conduition' via Bitcoin Development= =20 Mailing List wrote: Hi Antoine, thanks for the feedback. Glad to hear you're receptive! It's important to consider that in any scenario where Bitcoin as we know it= =20 survives a CRQC, the vast majority of users would have had to migrate to an= =20 output type that includes an escape hatch long before we could have been=20 reasonably certain that a CRQC would materialize. Therefore we should not= =20 assume that the vast majority of users strongly desire to migrate to an=20 escape-hatch output type. (In fact, i think it would actually be reasonable= =20 to assume none have a strong desire to do so. This is because everyone has= =20 an incentive for everybody to migrate, but there is little incentive for=20 each individual to migrate if nobody else does.) Therefore any additional barrier to encourage users to opt into an=20 escape-hatch output type is working against CRQC risk mitigation. All else being equal, whether we use P2MR or P2TRv2 I believe we will end= =20 up with roughly the same (small) fraction of the UTXO set migrated by=20 Q-day. I believe this because address format adoption is always slow even= =20 with good incentives. Even after 7 years and plenty of incentives to=20 migrate, P2TR still secures only a small fraction of the UTXO-set compared= =20 to P2(W)PKH, and a tiny fraction (0.75%) of the supply. See this 2025=20 report from mempool.space = and=20 this 2025 report from Galaxy Digital=20 . Incen= tivizing=20 adoption doesn't always lead to adoption, so why expect it to do so with=20 P2TRv2? It doesn't offer any incentive over P2TR beyond a shallow promise= =20 of *maybe-some-day-quantum-security*. I don't think that's necessarily the right conclusion. P2TR adoption is=20 low, partially because wallets and especially commercial service providers= =20 generally don't ever upgrade their technology stacks unless there is a=20 compelling reason; the ecosystem primarily updates through companies going= =20 out of business and being replaced by new ones, which are more likely to be= =20 built using modern technology. We obviously cannot ask for faster movement= =20 through business failure here, but as far as compelling reasons go, I think= =20 the quantum resistance debate is quite different from P2TR adoption. As=20 Q-fear grows, I suspect there will be increasingly loud and hard-to-ignore= =20 voices (and possibly regulation...) to adopt post quantum cryptography=20 technology stacks. At that point, wallets may start to offer users an=20 "Upgrade to quantum-resistant addresses?" migration button. In the case of= =20 P2MR that will need to come with a "Warning: transactions will cost 15%=20 more going forward" notice. In the case of P2TRv2, depending on what what= =20 used before it may have 0 impact on costs, or even be a discount going=20 forward. If on-chain fees remain as low as they are now, this may not=20 matter, but otherwise, I think the number may very well discourage a=20 substantial amount of users who aren't convinced about CRQC threats. And I= =20 think those users do matter, unfortunately. Here's my timeline prediction, with the above precedent in mind. We deploy= =20 a PQ output type, some minority of UTXOs migrate to it. When the first=20 confirmed ECDLP break is proven (e.g. if someone breaks a NUMS point) or=20 suspected (someone stole Satoshi's coins), then we will deploy a rescue=20 protocol which we hopefully prepared in advance to protect the majority=20 procrastinator UTXOs. Maybe we disable EC spending at the same time (a=20 valid option for either P2MR or P2TRv2). Then there will be a brief=20 fork-war (hard or soft) revolving around the question of how to handle=20 Satoshi's coins. After that IDK what happens, but I expect Bitcoin will=20 survive if we prepare adequately today by deploying a quantum-safe address= =20 format and PQ signature scheme, and develop rescue protocols for later=20 activation to move laggards over to PQ wallets. No offense, but this sounds like a fairly depressing scenario to me. If an= =20 ECDLP break happens before even a large majority of the "active" economy=20 adopts Q-safe outputs, I don't think there is much of an interesting future= =20 for Bitcoin. Leaving many users' coins vulnerable to theft will undermine= =20 short-term trust in the currency, possibly fatally so. The alternative,=20 burning significant amounts of users' coins will be seen as confiscation=20 that undermines the long-term stability value proposition bitcoin has, as= =20 it would be indistinguishable from a PQC altcoin that imports some fairly= =20 arbitrary subset of Bitcoin's UTXO set (see also=20 https://antoinep.com/posts/quantum_risk_mitigation/, where Antoine makes=20 that point in more detail). I cannot confidently state that your scenario is unlikely of course, but I= =20 think there is little we can do today that affects the outcome in this=20 case. People can think about emergency recovery scenarios to scavenge=20 what's left to save (BIP32 ZKPs and all that), and the result may well=20 survive, but I don't think it'll be very interesting, and not something we= =20 as protocol designers should optimize for at this stage. The interesting scenarios to me are ones where either a CRQC doesn't=20 happen, or where we get a large majority of users to adopt Q-safe outputs= =20 before that happens. Maximizing the probability that that will happen=20 should be our priority. Whether we pick P2MR or P2TRv2 today, neither choice will affect the early= =20 stages of this plot-line very much, so we might as well optimize for the=20 long-term future, and P2MR wins out there. The ideal long-term future is one where we get feature-rich cryptographic= =20 schemes that can replace most of the properties Bitcoin relies on today=20 (homomorphic derivation, efficient multisigs, ...) with low costs (through= =20 discounts, smaller signatures/keys, efficient verification, ...). At that= =20 point, they can be introduced in PQC-only outputs even (say, P2MR without= =20 any EC opcodes ever), everyone can adopt them over time, and then when a=20 CRQC appears or not won't really matter. That technology does not exist=20 today, I think, so the best we can aim for today is something where most=20 users can migrate to with minimal downsides before Q-day, even if it comes= =20 with some downsides afterwards, which will inevitably be chaotic but maybe= =20 not an existential threat. I don't think it matters much that P2TR(v2) is= =20 slightly less efficient than P2MR in this hopefully-avoidable chaos; we'll= =20 have much bigger fish to fry. I believe P2MR is effectively optimizing for the time after/if a CRQC=20 appears (possibly only temporarily so if another migration to a more=20 fully-features PQC scheme is needed anyway then) while P2TRv2 is optimizing= =20 for the time before a CRQC happens and minimizing barriers for adopting=20 Q-safe coins. All of this is under the assumption that P2MR comes with a=20 reasonable expectation of a narrow P2MR-only EC opcode disabling softfork= =20 when CRQCs happen (like P2TRv2); without it, I believe it is much worse, as= =20 P2MR would be entirely inadvisable to adopt by anyone whose workflow relies= =20 on sharing public keys with others (hardware wallets with descriptor-based= =20 watchonly software, wallets with indexing servers, multisig, Lightning,=20 escrows, fee bumping, ...). So, I prefer P2TRv2 here, though under the assumption that the narrow EC=20 opcode disabling softfork can be relied upon. I am not confident that that= =20 is possible, though I have more thoughts on the matter. That's for another= =20 post, though. any additional barrier to encourage users to opt into an escape-hatch=20 output type is working against CRQC risk mitigation. And i think the=20 additional costs of using P2MR compared to P2TRv2 is one of them. I have good news for you: there is an optimization to BIP360 which would=20 make single-signer Schnorr spending significantly (32 bytes) cheaper. It's= =20 not my idea so I don't want to jump the gun in explaining the details, but= =20 expect another mailing list post soon with more info. It's possible to allow a Merkle tree whose leaves are either EC keys or=20 scripts, and then allow spending from the key-leaves by revealing the path= =20 and a signature, but recover the expected public key from the signature.=20 That needs a variation of BIP340 that doesn't commit to the public keys=20 (which may break some of the proofs of higher-level schemes, but as long as= =20 there is no ANYPREVOUT like functionality, the message implicitly commits= =20 to the output so that may be fine). But even with that, efficiency is 32=20 bytes worse than P2TR, because in a Q-safe setting with at least one=20 additional PQC branch, you have at least 32 bytes of Merkle path. Is this= =20 what you have in mind? --=20 Pieter --=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/= 26684d8a-cdb3-43dd-a5b4-fc607ed95e8bn%40googlegroups.com. ------=_Part_91691_1247968547.1780783966223 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Antoine, Conduition, Pieter, and list,

I want to share my pro= posal for EC public key recovery in P2MR (BIP-360). It saves 35 bytes in th= e witness by removing the witness element that contains the script.
ht= tps://delvingbitcoin.org/t/public-key-recovery-for-ec-leaves-in-p2mr-bip-36= 0/2603=C2=A0

Best,
Boris

On Saturday, June 6, 2026 at 1:00:08=E2=80=AFPM UTC-5 Pieter Wuille wr= ote:
Hi Conduition,

Som= e comments inline below.

On Friday, June 5th, 2026 at= 6:59 PM, 'conduition' via Bitcoin Development Mailing List <bitco...@googlegroups.com> wrote:
Hi Antoine, thanks for the feedback. Glad = to hear you're receptive!

It= 's important to consider that in any scenario where Bitcoin as we know it s= urvives a CRQC, the vast majority of users would have had to migrate to an = output type that includes an escape hatch long before we could have been re= asonably certain that a CRQC would materialize. Therefore we should not ass= ume that the vast majority of users strongly desire to migrate to an escape= -hatch output type. (In fact, i think it would actually be reasonable to as= sume none have a strong desire to do so. This is because everyone has an in= centive for everybody to migrate, but there is little incentive for each in= dividual to migrate if nobody else does.)

Therefore any additional barr= ier to encourage users to opt into an escape-hatch output type is working a= gainst CRQC risk mitigation.

All else being equal, whether we use P2MR or P2TRv2 I bel= ieve we will end up with roughly the same (small) fraction of the UTXO set = migrated by Q-day. I believe this because address format adoption is always= slow even with good incentives. Even after 7 years and plenty of incentive= s to migrate, P2TR still secures only a small fraction of the UTXO-set comp= ared to P2(W)PKH, and a tiny fraction (0.75%) of the supply.=C2=A0See=C2=A0this 2025 repo= rt from mempool.space=C2=A0and this 2025 report from Galaxy Digital. Inc= entivizing adoption doesn't always lead to adoption, so why expect it to do= so with P2TRv2? It doesn't offer any incentive over P2TR beyond a shallow = promise of maybe-some-day-quantum-security.

I don't think that's necessarily the right= conclusion. P2TR adoption is low, partially because wallets and especially= commercial service providers generally don't ever upgrade their technology= stacks unless there is a compelling reason; the ecosystem primarily update= s through companies going out of business and being replaced by new ones, w= hich are more likely to be built using modern technology. We obviously cann= ot ask for faster movement through business failure here, but as far as com= pelling reasons go, I think the quantum resistance debate is quite differen= t from P2TR adoption. As Q-fear grows, I suspect there will be increasingly= loud and hard-to-ignore voices (and possibly regulation...) to adopt post = quantum cryptography technology stacks. At that point, wallets may start to= offer users an "Upgrade to quantum-resistant addresses?" migration button.= In the case of P2MR that will need to come with a "Warning: transactions w= ill cost 15% more going forward" notice. In the case of P2TRv2, depending o= n what what used before it may have 0 impact on costs, or even be a discoun= t going forward. If on-chain fees remain as low as they are now, this may n= ot matter, but otherwise, I think the number may very well discourage a sub= stantial amount of users who aren't convinced about CRQC threats. And I thi= nk those users do matter, unfortunately.

Here's my timeline prediction, with t= he above precedent in mind. We deploy a PQ output type, some minority of UT= XOs migrate to it. When the first confirmed ECDLP break is proven (e.g. if = someone breaks a NUMS point) or suspected (someone stole Satoshi's coins), = then we will deploy a rescue protocol which we hopefully prepared in advanc= e to protect the majority procrastinator UTXOs. Maybe we disable EC spendin= g at the same time (a valid option for either P2MR or P2TRv2).=C2=A0Then th= ere will be a brief fork-war (hard or soft) revolving around the question o= f how to handle Satoshi's coins. After that IDK what happens, but I expect = Bitcoin will survive if we prepare adequately today by deploying a quantum-= safe address format and PQ signature scheme, and develop rescue protocols f= or later activation to move laggards over to PQ wallets.
=

No offense, but this sounds like a f= airly depressing scenario to me. If an ECDLP break happens before even a la= rge majority of the "active" economy adopts Q-safe outputs, I don't think t= here is much of an interesting future for Bitcoin. Leaving many users' coin= s vulnerable to theft will undermine short-term trust in the currency, poss= ibly fatally so. The alternative, burning significant amounts of users' coi= ns will be seen as confiscation that undermines the long-term stability val= ue proposition bitcoin has, as it would be indistinguishable from a PQC alt= coin that imports some fairly arbitrary subset of Bitcoin's UTXO set (see a= lso=C2=A0https://antoinep= .com/posts/quantum_risk_mitigation/, where Antoine makes that po= int in more detail).
<= br />
I cannot confide= ntly state that your scenario is unlikely of course, but I think there is l= ittle we can do today that affects the outcome in this case. People can thi= nk about emergency recovery scenarios to scavenge what's left to save (BIP3= 2 ZKPs and all that), and the result may well survive, but I don't think it= 'll be very interesting, and not something we as protocol designers should = optimize for at this stage.

The inter= esting scenarios to me are ones where either a CRQC doesn't happen, or wher= e we get a large majority of users to adopt Q-safe outputs before that happ= ens. Maximizing the probability that that will happen should be our priorit= y.

<= blockquote type=3D"cite">
Wh= ether we pick P2MR or P2TRv2 today, neither choice will affect the early st= ages of this plot-line very much, so we might as well optimize for the long= -term future, and P2MR wins out there.

The ideal long-term future is one where we get feature= -rich cryptographic schemes that can replace most of the properties Bitcoin= relies on today (homomorphic derivation, efficient multisigs, ...) with lo= w costs (through discounts, smaller signatures/keys, efficient verification= , ...). At that point, they can be introduced in PQC-only outputs even (say= , P2MR without any EC opcodes ever), everyone can adopt them over time, and= then when a CRQC appears or not won't really matter. That technology does = not exist today, I think, so the best we can aim for today is something whe= re most users can migrate to with minimal downsides before Q-day, even if i= t comes with some downsides afterwards, which will inevitably be chaotic bu= t maybe not an existential threat. I don't think it matters much that P2TR(= v2) is slightly less efficient than P2MR in this hopefully-avoidable chaos;= we'll have much bigger fish to fry.

= I believe P2MR is effectively optimizing for the time after/if a CRQC appea= rs (possibly only temporarily so if another migration to a more fully-featu= res PQC scheme is needed anyway then) while P2TRv2 is optimizing for the ti= me before a CRQC happens and minimizing barriers for adopting Q-safe coins.= All of this is under the assumption that P2MR comes with a reasonable expe= ctation of a narrow P2MR-only EC opcode disabling softfork when CRQCs happe= n (like P2TRv2); without it, I believe it is much worse, as P2MR would be e= ntirely inadvisable to adopt by anyone whose workflow relies on sharing pub= lic keys with others (hardware wallets with descriptor-based watchonly soft= ware, wallets with indexing servers, multisig, Lightning, escrows, fee bump= ing, ...).

So, I prefer P2TRv2 here, = though under the assumption that the narrow EC opcode disabling softfork ca= n be relied upon. I am not confident that that is possible, though I have m= ore thoughts on the matter. That's for another post, though.

any additional barrie= r to encourage users to opt into an escape-hatch output type is working aga= inst CRQC risk mitigation. And i think the additional costs of using P2MR c= ompared to P2TRv2 is one of them.

I have good news for you: there is an optimization to BIP36= 0 which would make single-signer Schnorr spending significantly (32 bytes) = cheaper. It's not my idea so I don't want to jump the gun in explaining the= details, but expect another mailing list post soon with more info.<= /div>

It's possible to allow a Merkle tree whose leaves are either = EC keys or scripts, and then allow spending from the key-leaves by revealin= g the path and a signature, but recover the expected public key from the si= gnature. That needs a variation of BIP340 that doesn't commit to the public= keys (which may break some of the proofs of higher-level schemes, but as l= ong as there is no ANYPREVOUT like functionality, the message implicitly co= mmits to the output so that may be fine). But even with that, efficiency is= 32 bytes worse than P2TR, because in a Q-safe setting with at least one ad= ditional PQC branch, you have at least 32 bytes of Merkle path. Is this wha= t you have in mind?

--=C2=A0
Pieter

--
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/26684d8a-cdb3-43dd-a5b4-fc607ed95e8bn%40googlegroups.com.
------=_Part_91691_1247968547.1780783966223-- ------=_Part_91690_1329493957.1780783966223--