From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 16 Jun 2026 13:23:08 -0700 Received: from mail-oi1-f189.google.com ([209.85.167.189]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wZaJO-0002DV-Kq for bitcoindev@gnusha.org; Tue, 16 Jun 2026 13:23:08 -0700 Received: by mail-oi1-f189.google.com with SMTP id 5614622812f47-48651d7d505sf7517672b6e.0 for ; Tue, 16 Jun 2026 13:23:06 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1781641380; cv=pass; d=google.com; s=arc-20240605; b=JBNS6nL3tDJO6J2o6UMFHphvFzw41MZJ3o6TLIlFJn8ZkXzn85Wh+pg0PmOhGHzboM q/6bx2EwXiKEnd5z+16ByZIFSSwEAnOn0xWMM50huAEz7c5hJ2N5fFpJtZVjfsYQjdFW jhhfgx42V2gHYM7jUrMoXZoBSS3fX1lsreI/BVHaoNoK12lCGDcZwWfHtcJO+UDG++aX VWwYguOPBTYU+vj//B60PT4k6W317xTCrgi9xShUel9KwcWjzyKLVXSJEmDoq8TduBGA GdBz37ojgOQRenWeSadNuV900hxw0yR29TIvCLBCvC8D5ijcOsAQqMixJWJ6eGvtLAVM i4Hw== 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:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:sender :dkim-signature; bh=YRPpOimSF6n3yyT9Y+wWFmkxTawmOpB+jk1GuvENLoE=; fh=EHMJ8C/MP9rZT+ZPRS9H4xwFi5fAKadYD/od/6MHbPY=; b=fqucttSRzcG0IRddolP389brbm3RamgW1ML8YkaoE7VrSznkmuZ8HmJLsGTyaI9VUc T6NiBZf9P4BY7Kb/WHlAu7xgx7viPRNpYHHLyhdyV6V4d39xH1nlbuo4q5GdBFeJFh3p fpt+738yhqU9AVMI5Hjvs/gilXWGueODVYYxDFhkB2YFf9Jrx6MvjnXcpLrSg0A9hRtv JD4+61I5qsqvowzaTSGvz0+O+/q3gT9jqR6xgsK6NDZCgBVFZtHtwDCZYH+CWPOdAxLD EMDGat7E4BJG7jqcEec8Wvmv8GkhBEudZh/Ie6XGGTO6sftdxFQjmLoP+58U57FgcVUE tToQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@wuille.net header.s=protonmail header.b="A10/49uG"; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 109.224.244.20 as permitted sender) smtp.mailfrom=bitcoin-dev@wuille.net; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wuille.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1781641380; x=1782246180; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:mime-version:feedback-id:references:in-reply-to :message-id:subject:cc:from:to:date:sender:from:to:cc:subject:date :message-id:reply-to; bh=YRPpOimSF6n3yyT9Y+wWFmkxTawmOpB+jk1GuvENLoE=; b=keuFZCqYp6ZNBA90c0BTlqO2p8eOsom0LkjLCEDu9gB8iays9Y2UxFQo+rcb+veWFM S2i2nTjMqMDarGhvZIgYwhMJxoPjsC22qqjv3CKDwGtWr/5yJAtrm3Ps5eNfAnCUbiOl cAkViCAGsipWmY4gnklruYsulE+Tgkc6Fq7Wr7HPDcUCcwC5W0wzvj5tJKTKXb7PpAnN tZWeAfRq+s4TF0FVg6IZg8pQQJXMNCrXwhvLYKHIxxB+EC4ZuMNMANP/prPa0jWoQwOm YWn7NWbn6am9wYPL/YTXOKnd91Er06cw8sQXmDLAqFvE90yJ+PSy/qz0+yFHxlUNwtg0 yo6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781641380; x=1782246180; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:mime-version:feedback-id:references:in-reply-to :message-id:subject:cc:from:to:date:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=YRPpOimSF6n3yyT9Y+wWFmkxTawmOpB+jk1GuvENLoE=; b=H0QnqteJtVEkXm38oY3jcdNfdFvovJ3KPjxu0hF3/RIKZiYDRGRwtO+PbRvu6buo4v PbxxBAeRIHx0Mso2x0YCZGcC3YHEecDaWpH/pz9lS4bubRbq2Vl77exfbdlxDiDSdW+z VKHjq1ZHrn8m/8KOsOu6ZUDtVTThovyfX1NACNvI3IS5eYIypemiOMAxTmy4VFFiHHI6 n91Y0DE5GaF7o7FILGsOnmoCiczf/0quZ7Q/j21Dzt6Pvz0h9hX7aCB9eKofPh/Dvdrg nTvmjh//ZRXz9czB1XuSyxt6cAi94jV5G8/jGSQ0aVRZfqYlACL1E6Po0pOipm/v9rkE oKXQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AFNElJ88r+0d5nEMfzK2uwkIpsIo7e9z65o+IrG7SPOpbbh77jKFxDlUs7xlM24sjSLlA5FymzNALmQCjpkz@gnusha.org X-Gm-Message-State: AOJu0YwRFSLNv87vQY7CTt01NySSdb000R2lZHHAHN5lYAQWg2qMJ5Ds EcIz2JjMD5oCcyzneeXIgSPKvpAzllCFAAUOaAVPePakc6Pak8duKZq7 X-Received: by 2002:a05:6808:2444:b0:486:4892:d568 with SMTP id 5614622812f47-48942a3d708mr828173b6e.39.1781641380499; Tue, 16 Jun 2026 13:23:00 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUemoh2VDLS0qYA/0d6vqbAnZJkbchzFEdLe3XnVjgPqpQ==" Received: by 2002:a05:6871:e0f1:b0:439:b6fe:4488 with SMTP id 586e51a60fabf-4426270eebcls1679312fac.2.-pod-prod-05-us; Tue, 16 Jun 2026 13:22:57 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ+L60WnpUJoVGwpTvbgyJBJFXb/9sL6rbfn3f6BJaVtUnIKn9JyQ08h3vIBOmZoIKQSXljrXzO71c0R@googlegroups.com X-Received: by 2002:a05:6808:4442:b0:485:a3f8:d5aa with SMTP id 5614622812f47-48942a0566dmr1060634b6e.31.1781641377069; Tue, 16 Jun 2026 13:22:57 -0700 (PDT) Received: by 2002:a05:6809:30f:20b0:487:5060:f86f with SMTP id 5614622812f47-4894378099emsb6e; Tue, 16 Jun 2026 13:09:17 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ824J3ITKffTjywSHLsgYllYsgkRPlsfQAYoCzWPrVmnR87gQE/CF7LFodQ1ykEqHSj9m2VesCqfOOq@googlegroups.com X-Received: by 2002:a05:7022:485:b0:134:df7f:910d with SMTP id a92af1059eb24-1398f61fd53mr259158c88.7.1781640556810; Tue, 16 Jun 2026 13:09:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781640556; cv=none; d=google.com; s=arc-20240605; b=MXEjQNP8TatbmipDZGzqYzFSDyoQnJNNO75lvUWOK41B+7PcqCepirDnLQJX1tXpB3 +WaOvhpp9w+8Gp8HMM0JrQF3JMWVsOrCiiGa0QymTI+595gmJ51hK7KUmlrN6ixGwPoK Pe/1buypLGnl2r8dBZz4Hla9VY5qvcDpNB4hQ0tUrinP+AzfcwX9afvaQO3cE8Z8cnna IhhT5SoHiyoIOl5u4Vhbt8wYESQlhRGdL8Z2jvka8ze5dJrojXVssuM6vhqbp4GLaHhL QLgNeGNpmytP/z/gc6FKSwmPOAlA+bydRkc+F8THpKL1n/TdbvTGKJhpQM40FpI5Ah98 6jAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=GTUa6FpCfMvpll5FQ5QGeOPN6pwWosDTyWIvwAvOJCk=; fh=D2zN9mv8jVn5Hb696WOH8AcKnxQ3Rlerek2KxSdkxlE=; b=ZqaLMs9vHTj7C07kx2qzQjXt6Acdux10tzMnBajfJxTgrNhB0Jyq7DuhlDqTHHAM51 5H/8sS6TpaCq90iqscEe5Nlxvnl+tH1wsFXxbBwgT4aM/3KNeTEJ4bJcuCIGuxBpiQ7o SovBDVyEqdKKsTC937l8ttUAE6vcewyUhfegZw2C2hsk4hY+yN/0esX9ZOi61brr0UAc XBsTiYxGSF19bNg6f4aXWJCJlDDQmf6acYyy7IDI26Sbl0J/mQYd+NNUqPnOTF2Eq5dC XrdBEglvMuXqyCqikroFTWcmeR9h+TvOwO4WFdbR6FY+OZXQAI7AbnYgRoJ4d3WJqo+k U48g==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@wuille.net header.s=protonmail header.b="A10/49uG"; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 109.224.244.20 as permitted sender) smtp.mailfrom=bitcoin-dev@wuille.net; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wuille.net Received: from mail-24420.protonmail.ch (mail-24420.protonmail.ch. [109.224.244.20]) by gmr-mx.google.com with ESMTPS id a92af1059eb24-1397261c28asi353592c88.4.2026.06.16.13.09.15 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Jun 2026 13:09:16 -0700 (PDT) Received-SPF: pass (google.com: domain of bitcoin-dev@wuille.net designates 109.224.244.20 as permitted sender) client-ip=109.224.244.20; Date: Tue, 16 Jun 2026 20:09:08 +0000 To: conduition From: Pieter Wuille Cc: Antoine Poinsot , "bitcoindev@googlegroups.com" Subject: Re: [bitcoindev] Aligning privacy incentives in P2MR Message-ID: <81QWqov2xqthGLjORSKtR2jDDosHG7gjK91LNQ61iIBNRQaJPsu6wTA63d3KjVdROO2VZy5zr3Buo5A8UXb3Ue5E4zc2qWYn65gRxmmFLKg=@wuille.net> In-Reply-To: References: <_z6_JUmphCkUYvI6gemSFMD9Sb_rDL03IQbtZQCNlk6pmioGEQBir_gMyZCfticFa8Ttfc0xoFHdxR07_MNuAfBu8do_h5IDf2apVk1w1BM=@wuille.net> Feedback-ID: 19463299:user:proton X-Pm-Message-ID: d8be944d645f3c53154b2765486dddb62ca5aad9 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_VrJ4SZJqP9578XIRJSOTptWEA0y3ak5C8B6FoDEY" X-Original-Sender: bitcoin-dev@wuille.net X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@wuille.net header.s=protonmail header.b="A10/49uG"; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 109.224.244.20 as permitted sender) smtp.mailfrom=bitcoin-dev@wuille.net; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wuille.net Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.7 (/) --b1=_VrJ4SZJqP9578XIRJSOTptWEA0y3ak5C8B6FoDEY Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the comments, conduition, See my responses inline below. On Friday, June 12th, 2026 at 12:43 AM, conduition w= rote: > Hi Pieter > >> my reasoning is primarily that the "Never" and/or "Immediately" options = are just insufficient with current technology for any worthwhile migration = attempt (independent of which commitment structure is used), and thus that = we simply need the "Later" option. > > Also agreed. Though I take things a step further as I suspect we will als= o be forced to restrict legacy coins by deploying a rescue protocol, but so= far i'm following w.r.t the new output type. Whether it's P2MR or P2TRv2, = EC disabling will be highly desirable. I want to first correct a potential misunderstanding here, because I realiz= e the terms "Later" and "Never" aren't very descriptive. They are specifica= lly about an expected and relied-upon expectation that an EC-disabling fork= will happen that at least applies to the output type itself, in time. "Lat= er" is the expectation that such a disabling will happen after the output t= ype is introduced, but still in time (so, before Q-day). Outputs without a = strong expectation that their EC paths/opcodes will be disabled, or not in = time, I classify under "Never". Note that it is not about whether you believe such disabling (possibly in g= eneral) will be needed or not, but about whether there is a built-in expect= ation that it will=E2=80=8B be, as it changes usage patterns: using a "Late= r" type without PQC path is manifestly incorrect as the coin is subject to = burning, and due to the expected EC disabling, cannot be treated as confisc= ation (which could otherwise be a basis to protest the disabling). The upsi= de is that the EC paths/opcodes in it can be used without the arduous restr= ictions of post-EC-safety (no address reuse, no pubkey sharing, ...). It al= so trades the security assumption of CRQCs being too slow for short-range a= ttacks for a security assumption that the EC disabling will happen in time. So under that terminology (and again, apologies for the confusing naming, f= eel free to suggest better ones, but I'll stick with them for now to not co= nfuse things further): - I think most people interpret P2MR as something that falls under Merkle-N= ever. Sure, some may assume EC disabling in general will be needed, but the= re is no strong expectation that P2MR will have EC opcodes disabled before = Q-day, I think. - It's possible to consider an alternative to P2MR ("P2MR+ED") which comes = with a built-in Expected Disabling of (just) its own EC opcodes before Q-da= y, which would fall under Merkle-Later. - P2TRv2 falls under Taproot-Later. - A hypothetical proposal to add just PQC opcodes to normal P2TR would be u= nder Taproot-Never. - A new output type ("P2QR") that is like P2MR, but with EC disabled right = from the start would be under Merkle-Now. I introduce this separation into two dimensions because I think most of the= arguments for/against P2TRv2 vs P2MR are really arguments about "Later" vs= "Never", rather than arguments about "Taproot" vs "Merkle". Having a "Later" type does not rule out the possibility of also having a se= parate general EC disabling, but it can (and hopefully does) significantly = reduce the need/impact of that. Coins whose EC path/opcodes are disabled th= rough the "Later" type aren't confiscated. If that gets adopted at scale, i= t removes those coins entirely from the steal-or-freeze equation. Perhaps t= o the point where general freezing is not considered a necessity anymore. P= erhaps to the point where general freezing is limited to old presumed-lost = coins, and the Bitcoin community then doesn't see that as an infringement o= n its core value proposition anymore. So the point of mine you're responding to here is really saying: we need=E2= =80=8B a "Later" output type, whether that's P2MR+ED or P2TRv2 or something= else, because other output types are practically unavailable to large clas= ses of users: "Never" (because it is so restrictive in how it can be used i= n ways that are incompatible with today's reality) and "Now" (because it's = too expensive and comes with bad privacy trade-offs, probably encouraging a= ddress/key reuse to avoid needing to share tons of keys etc). - >> Once you accept that, there is a secondary line of reasoning about which= specific structure(s) are , and that is where taproot-based constructions = come out ahead by having better incentives in the short- to medium term (th= e numbers above mean essentially less/zero economical friction). > > This is where you lose me. Why does P2TRv2 incentivize migration better t= han P2MR? You'd have to assume EC disabling will happen and will be timed p= erfectly. Then assume everyone using Bitcoin will have utter confidence in = this TBD timing solution, and no reason to doubt it will work perfectly. The point you're responding to is about if=E2=80=8B you already accept that= we need "Later", then among the two options "P2MR+ED" or "P2TRv2", the lat= ter is preferable. I believe here you're instead arguing for P2MR ("Merkle-Never") over all "L= ater" options. That was my previous point: I think (solely) having "Never" = output types like P2MR is just utterly insufficient for any worthwhile migr= ation. It's so incompatible with today's workflows that it either won't be = adopted, or (possibly inadvertently) adopted in an insecure fashion. Yes, i= t gives people the option to safeguard their own coins, but to me that's di= saster recovery territory - I think we ought to prioritize maximizing the c= hances for saving the currency as a whole in case Q-day comes, not a small = subset of individual users' coins. P2MR (alone) doesn't really achieve much= in that regard in my view, thus we at least need something of the "Later" = class in addition. So the point here was just: if you already accept the need for a "Later" ou= tput type (=3D one with builtin-in EC disabling expected from the start), P= 2TRv2 is preferable over P2MR+ED, because: - It's cheaper for now for common cases, thus has lower friction for adopti= on, especially to those for whom quantum-resistance isn't a priority. - It has less incentive for misuse, because the only=E2=80=8B reason why an= yone would use P2TRv2 is quantum resistance (given that P2TR already exists= ). - Their security assumptions are identical (all based on expected EC disabl= ing before Q-day; but note that that isn't the case for "Never" P2MR). - Preserving the taproot incentive structure better, for now. > Even then, AFAICT the only distinction to the lay user between P2MR and P= 2TRv2 is that P2TRv2 is more efficient pre-Q-day, and P2MR is more efficien= t afterward, and both by about the same margin: 32 witness bytes (counting = Boris' EC recovery improvement). That's 8 vbytes per Schnorr spend - less t= han a cent at current rates. Yes, but one doesn't need to look back very far to see times where Bitcoin = fee rates were much higher, and presumably, if Bitcoin is going to survive = post-subsidy, it'll need much higher fees in any case. I don't think you ca= n use today's low-fee regime as an argument for fees not being relevant. > Theorycrafting for a second here. It's reasonable to conjecture fee rates= will be much higher post-Q-day, and thus P2MR's 32 byte advantage over P2T= Rv2 will yield significant savings for end-users in absolute terms. If fee = rates inflate 10x higher after Q-day, then 8 vbytes becomes significant (10= 0 sats per spend or more). In other words, the P2TRv2 internal key will be = much more expensive to a user after Q-day than P2MR's PQ leaf script hash w= ill be to a user today. Agreed. After Q-day we'll probably want some "Merkle" type (P2MR or P2QR), = or something novel we haven't imagined yet. But I think that's a concern fo= r later, when we're ready to adopt "full migration" technology (feature-ric= h, efficient, PQC). If Q-day comes before that time, we'll inevitably be sc= rambling in a somewhat suboptimal but hopefully survivable world. I don't t= hink we should optimize for the hopefully short / avoidable temporary "afte= r Q-day, before fancy tech" time, at the cost of (a) reducing the chances o= f actually migrating the Bitcoin ecosystem to be Q-ready and (b) incentives= and properties in the present time before Q-day. > I think our disagreement comes from your assumption we must always time t= he disabling fork perfectly to coincide with Q-day. On the other hand, I ex= pect we will not solve the fork timing problem, so an EC disable fork will = be a messy, panicked affair, arriving possibly quite late (months or years = after Q-day). With P2MR, at least holders who used it properly will have sh= elter, and those who didn't will have an opportunity to move coins somewher= e safe to ride things out. This is very interesting. I have reservations too about the "Later" EC-disa= bling soft fork expectations about P2TRv2, but they're not about whether th= e future Bitcoin ecosystem can coordinate a softfork; that seems almost tri= vial if not doing so poses an existential threat, and could be done within = a few months if it's expected and designed already. I'm more worried about = it not being adopted due to indifference/friction, or being abused/misused. FWIW, I don't think the P2TRv2 EC-disabling fork needs to be timed perfectl= y. The expectation should be just that it happens before Q-day, and when it= looks inevitable or the fear about that is large enough. There is certainl= y some variance there, and there will be some disagreement, but I can't ima= gine we don't get at least a year's worth of notice in the form of breakthr= oughs on simpler QC problems. >> And if you accept that at least a "Later" option is needed, I think addi= ng more PQC options actually weakens it! If some people have their coins in= "Never" or "Now" outputs in a PQC-safe manner (subject to the restriction = / costs those bring), then that reduces the incentive to get the "Later" na= rrow EC freeze to occur, and indirectly reduces the value of that output ty= pe. > > Interesting. It sounds like you're arguing that because P2TRv2 is blatant= ly PQ-vulnerable, it will incentivize future bitcoin users to lock it down = later. I mean yes, that's technically true, but that would be like putting = a spike on the steering wheels of cars, to incentivize drivers to wear seat= belts. First a meta-point here: the reason I like separating the discussion into d= ifferent dimensions than just "P2TRv2 vs P2MR" is because there are more op= tions than those two, and not every argument applies to the same separation= into two classes. Let me list them explicitly here, roughly in decreasing = order of how strongly I feel about them: - We need at least a "Later" option for meaningful migration, i.e. P2TRv2 o= r P2MR+ED. - Within the "Later" option, P2TRv2 is preferable. - A "Later" option benefits from being the only PQC migration strategy, mak= ing it a Schelling point. If one were to disagree with just (3), other options could be e.g. to intro= duce both P2TRv2 and P2MR, or even P2TRv2 and P2QR. That may be easier or h= arder to get consensus on, I don't know. I think having multiple PQC migrat= ion paths makes the "Later" option less compelling (3), but even then I bel= ieve we still need one (1). Secondly, yes I understand the concern, if you phrase it like that. But I t= hink this sort of risk exists whether we choose to base the new output type= 's security on it or not. I think Bitcoin can only meaningfully survive a s= ystemic risk of this nature through collective action, at least in the near= to medium term, and the P2TRv2-expected-disabling one has at least a chanc= e of being sufficient, and is non-invasive. In contrast, one that needs to = freeze non-opted-in coins is likely far more damaging. > Should we really bet the entire network on that incentive working out? Ev= en if you're right and we all want very-badly to deploy EC disabling later,= how can we know we'll time it correctly? I don't see it as a bet. It's an opportunity, and we can choose to take it = or not. If Q-day comes before migration can reach meaningful levels (what t= hose are is probably a matter of perspective), then I think there isn't muc= h of an interesting future for Bitcoin anyway. > Remember, it's not just me you have to convince. Absolutely! But I think your views probably reflect those of many others, s= o getting to the core of things like this thread seems to be doing can gain= us insight. > You'd have to convince everyone to deploy and then adopt P2TRv2 today und= er the public knowledge that it is insecure and their coins are more likely= to be stolen. That's a hard sell. > How does one pitch P2TRv2 to users? "It will be quantum secure one day we= promise because everyone is incentivized to fix it later as Bitcoin will d= ie if we don't." > > How do you pitch P2MR? "It's quantum secure if you use it correctly." To me, the pitch is "Bitcoin can only remain valuable if we mostly/all migr= ate." for both. P2TRv2 is just much easier to adopt, because P2MR (or any "= Never" output type) fundamentally requires many users to change their workf= lows entirely. This focus on allowing individual users the ability to safeguard their coin= s just feels like a red herring: I'm not worried about my own coins being s= tolen. I'm worried about (fear of) a CRQC undermining trust in the currency= as a whole, or through a fear-driven consensus change the ecosystem destro= ying its own values beforehand. > The simplest example is a hash preimage. With preimage P=E2=80=8B and mes= sage m=E2=80=8B, I publish H(P)=E2=80=8B and H(P, m)=E2=80=8B at time T=E2= =80=8B=E2=80=8B. Then I reveal (P, m)=E2=80=8B=E2=80=8B=E2=80=8B at time T+= 1=E2=80=8B. A verifier checks H(P, m)=E2=80=8B was published first, and con= firms there exist no earlier reveals for P (by looking for H(P)=E2=80=8B=E2= =80=8B). This confirms I=E2=80=8B=E2=80=8B must have also approved the mess= age m=E2=80=8B=E2=80=8B. A similar mechanism is used as the core coin authe= ntication system of [FawkesCoin](https://jbonneau.com/doc/BM14-SPW-fawkesco= in.pdf). There are complexities to handle especially regarding censorship a= ttacks, but ultimately it's doable. Neat, thanks for explaining. You'd need some way to attach these to a speci= fic UTXO(s), I'd imagine, so the information can live with, and disappear w= ith, those outputs. Otherwise you need an boundlessly growing set of H(P) v= alues to prevent reuse? In either case, I consider anything that requires hardcoding specific walle= t designs (BIP32 or otherwise) into Bitcoin's consensus rules (and only all= owing those coins to survive) to be squarely in disaster-recovery land. It = feels like embracing arbitrariness, and giving up on the permissionlessness= that makes Bitcoin interesting - if the community shows it can get consens= us on effectively burning coins except those that match a whitelist, it fee= ls hard to maintain censorship-freeness as a value, even if the whitelist i= ncludes most of the (active) coins. That is of course not to say such techn= iques aren't interesting to work on, but to me, their place is in disaster = recovery scenarios to save what's left, after Q-day, if migration attempts = were unsuccessful. In such a setting, I think we're already in effectively = an altcoin-with-UTXO-bootstrapped-from-Bitcoin territory, and a (possibly g= rowing) set of ways to recover burned coins can be hardforked in. > Because consensus changes take years to deploy, and we're running out of = those. Many people seem to think so at least, I'm no physicist. I understand the feeling of urgency, but this seems like a "we must do some= thing, this is something, thus we must do it!" approach that just gives peo= ple the impression something is being done, without fundamentally tackling = the hard problem of actually migrating Bitcoin, and leaving that harder pro= blem to a (to me) very undesirable, but still unspecified future. And solvi= ng that harder problem will inevitably need another consensus change later,= so it doesn't help with the "running out of years" problem if you believe = those take too long. My impression is that your approach is to have an answer for many possible = futures, including ones where Q-day arrives within just a few years. But op= timizing for disaster-recovery also means reducing the chances of preservin= g Bitcoin as we know it in the scenarios where a successful migration is st= ill possible. And if Q-day does arrive that soon, I don't see what we can d= o today that would preserve Bitcoin in a form we care about anyway. By acce= pting that, we can focus on the futures where our choices today can still m= aterially improve the outcome. > Essentially yes though, I expect the majority of holders will probably mi= grate to PQ addresses via rescue protocols, either on Bitcoin or a fork the= reof. Even if we can't come to consensus and deploy a new output type, we'l= l still be able to rescue most coins. It's just that we'd have nowhere to r= escue them to, so we ought to make PQ wallets available soon, so we're not = in a rush to build them later when we need them. If a PQ wallet can use che= ap EC signatures while they're still trustworthy, all the better Thanks, I think that very much highlights a difference in vision. To me, if= we need to mostly migrate to PQ through rescue protocols post Q-day, we've= long lost already. Since it's just not an interesting future to me, I weig= h optimizing for it as a very minor secondary goal at best, and actively di= stracting at worst. Of course, if you believe it's the only possible future, I understand you'd= come to a different conclusion. But is it really? Do you think this isn't = a plausible future: - A P2TRv2 type (let's leave aside whether P2MR or P2QR gets added too) get= s introduced in the next few years, with hash-based PQC opcodes. - Over the course of the next decade or so, it gets adopted by practically = all active users. - What happens next depends on whether Q-day happens late-ish or soon-ish a= fterwards: - Late-ish (incl. never): - Isogenies (or something else) get a ton more attention, implementations g= et more efficient, gain well-studied features like tweaking and homomorphic= derivation, get far better confidence in their security. - A P2QR output type with isogeny PQC (or possibly hybrid EC+isogeny) opcod= es get added. - Many users migrate over to this P2QR type, and are fully living in a Q-mi= grated world. - (Possibly) Q-day happens, and nobody cares. - Soon-ish: - A (not-quite-CR)-QC breaks 128-bit ECDLP, say. - The community quickly softforks to disable EC paths/opcodes in P2TRv2. It= 's messy, spending gets expensive, there are privacy losses from PQC key re= use etc, but nothing really breaks. - Some stragglers migrate still, but a large part of the ecosystem migrated= already, supporting wallets are commonplace. - Based on how worried people are about early-era unmigrated coins, either = them being stolen isn't considered a threat anymore, or they get still wide= ly frozen but it's just a minority / presumed-lost coins. - Q-day happens. - Accelerated research into PQC schemes gets incorporated into P2QR, over a= longer time period, and eventually the messiness of P2TRv2 disappears. There are many other possible futures. Some are minor variations of these t= wo scenarios. Some are fairly bad independently of the choice between P2MR = or P2TRv2 (e.g. Q-day comes before any substantial migration). Some are mos= tly fine regardless (e.g. everyone has time to migrate to later P2QR isogen= y stuff, or just no CRQC ever). But these two in particular, I think have a= much better chance of happening with P2TRv2 than P2MR, because far more pe= ople can just adopt it with low friction. Cheers, -- 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/= 81QWqov2xqthGLjORSKtR2jDDosHG7gjK91LNQ61iIBNRQaJPsu6wTA63d3KjVdROO2VZy5zr3B= uo5A8UXb3Ue5E4zc2qWYn65gRxmmFLKg%3D%40wuille.net. --b1=_VrJ4SZJqP9578XIRJSOTptWEA0y3ak5C8B6FoDEY Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for = the comments, conduition,

See my responses inline below.

On Friday, June 12th, 2026 at 12:= 43 AM, conduition <conduition@proton.me> wrote:
Hi Pieter

my reasoning is primarily th= at the "Never" and/or "Immediately" options are just insufficient with curr= ent technology for any worthwhile migration attempt (independent of which c= ommitment structure is used), and thus that we simply need the "Later" opti= on.

Also agreed. Though I take t= hings a step further as I suspect we will also be forced to restrict legacy= coins by deploying a rescue protocol, but so far i'm following w.r.t the n= ew output type. Whether it's P2MR or P2TRv2, EC disabling will be highly de= sirable.

I want to first correct a potential misunderstanding = here, because I realize the terms "Later" and "Never" aren't very descripti= ve. They are specifically about an expected and relied-upon expectation tha= t an EC-disabling fork will happen that at least applies to the output type= itself, in time. "Later" is the expectation that such a disabling will hap= pen after the output type is introduced, but still in time (so, befo= re Q-day). Outputs without a strong expectation that their EC paths/opcodes= will be disabled, or not in time, I classify under "Never".

Note that it is not a= bout whether you believe such disabling (possibly in general) will be neede= d or not, but about whether there is a built-in expectation that it will= =E2=80=8B be, as it changes usage patterns: using a "Later" type withou= t PQC path is manifestly incorrect as the coin is subject to burning, and d= ue to the expected EC disabling, cannot be treated as confiscation (which c= ould otherwise be a basis to protest the disabling). The upside is that the= EC paths/opcodes in it can be used without the arduous restrictions of pos= t-EC-safety (no address reuse, no pubkey sharing, ...). It also trades the = security assumption of CRQCs being too slow for short-range attacks for a s= ecurity assumption that the EC disabling will happen in time.

So under that termin= ology (and again, apologies for the confusing naming, feel free to suggest = better ones, but I'll stick with them for now to not confuse things further= ):
  • I think most people interpret P2MR as somethin= g that falls under Merkle-Never. Sure, some may assume EC disabling in gene= ral will be needed, but there is no strong expectation that P2MR will have = EC opcodes disabled before Q-day, I think.
  • It's possible to consider an alternative to P2MR ("P2= MR+ED") which comes with a built-in Expected Disabling of (just) its own EC= opcodes before Q-day, which would fall under Merkle-Later.
  • P2TRv2 falls under Taproot-Later.
  • A hypothetical proposal= to add just PQC opcodes to normal P2TR would be under Taproot-Never.
  • A new output type ("P2QR") that = is like P2MR, but with EC disabled right from the start would be under Merk= le-Now.

    • I introduce this separation into two d= imensions because I think most of the arguments for/against P2TRv2 vs P2MR = are really arguments about "Later" vs "Never", rather than arguments about = "Taproot" vs "Merkle".

    Having a "Later" type does = not rule out the possibility of also having a separate general EC disabling= , but it can (and hopefully does) significantly reduce the need/impact of t= hat. Coins whose EC path/opcodes are disabled through the "Later" type aren= 't confiscated. If that gets adopted at scale, it removes those coins entir= ely from the steal-or-freeze equation. Perhaps to the point where general f= reezing is not considered a necessity anymore. Perhaps to the point where g= eneral freezing is limited to old presumed-lost coins, and the Bitcoin comm= unity then doesn't see that as an infringement on its core value propositio= n anymore.

    So the point of mine you're responding = to here is really saying: we need=E2=80=8B a "Later" output type, wh= ether that's P2MR+ED or P2TRv2 or something else, because other output type= s are practically unavailable to large classes of users: "Never" (because i= t is so restrictive in how it can be used in ways that are incompatible wit= h today's reality) and "Now" (because it's too expensive and comes with bad= privacy trade-offs, probably encouraging address/key reuse to avoid needin= g to share tons of keys etc).
    • =
      Once you accept that, there is a secondary line of reasoning about whic= h specific structure(s) are , and that is where taproot-based constructions= come out ahead by having better incentives in the short- to medium term (t= he numbers above mean essentially less/zero economical friction).

    This is where you lose me. Why does = P2TRv2 incentivize migration better than P2MR? You'd have to assume EC disabling will happen and will be timed perfectly. T= hen assume everyone using Bitcoin will have utter confidence in this TBD ti= ming solution, and no reason to doubt it will work perfectly.
    <= /blockquote>

    The point you're resp= onding to is about if=E2=80=8B you already accept that we need "Late= r", then among the two options "P2MR+ED" or "P2TRv2", the latter is prefera= ble.

    I believe here you're i= nstead arguing for P2MR ("Merkle-Never") over all "Later" options. That was= my previous point: I think (solely) having "Never" output types like P2MR = is just utterly insufficient for any worthwhile migration. It's so incompat= ible with today's workflows that it either won't be adopted, or (possibly i= nadvertently) adopted in an insecure fashion. Yes, it gives people the opti= on to safeguard their own coins, but to me that's disaster recovery territo= ry - I think we ought to prioritize maximizing the chances for saving the c= urrency as a whole in case Q-day comes, not a small subset of individual us= ers' coins. P2MR (alone) doesn't really achieve much in that regard in my v= iew, thus we at least need something of the "Later" class in addition.

    So the point here was just: if y= ou already accept the need for a "Later" output type (=3D one with builtin-= in EC disabling expected from the start), P2TRv2 is preferable over P2MR+ED= , because:
    • It's cheape= r for now for common cases, thus has lower friction for adoption, especiall= y to those for whom quantum-resistance isn't a priority.
    • It has less incentive for misuse, becau= se the only=E2=80=8B reason why anyone would use P2TRv2 is quantum r= esistance (given that P2TR already exists).
    • Their security assumptions are identical (all based = on expected EC disabling before Q-day; but note that that isn't the case fo= r "Never" P2MR).
    • Pres= erving the taproot incentive structure better, for now.

    Even then, AFAICT the only distinction to the lay user between P2MR an= d P2TRv2 is that P2TRv2 is more efficient pre-Q-day, and P2MR is more effic= ient afterward, and both by about the same margin: 32 witness bytes (counti= ng Boris' EC recovery improvement). That's 8 vbytes per Schnorr spend - less than a cent at curre= nt rates.

    Yes, but one doesn't need to look back very far to see times where= Bitcoin fee rates were much higher, and presumably, if Bitcoin is going to= survive post-subsidy, it'll need much higher fees in any case. I don't thi= nk you can use today's low-fee regime as an argument for fees not being rel= evant.

    Theorycrafting for a second here. It'= s reasonable to conjecture fee rates will be much higher post-Q-day, and th= us P2MR's 32 byte advantage over P2TRv2 will yield significant savings for = end-users in absolute terms. If fee rates inflate 10x higher after Q-day, t= hen 8 vbytes becomes significant (100 sats per spend or more). In other wor= ds, the P2TRv2 internal key will be much more expensive to a user after Q-d= ay than P2MR's PQ leaf script hash will be to a user today.

    Agreed. After Q-= day we'll probably want some "Merkle" type (P2MR or P2QR), or something nov= el we haven't imagined yet. But I think that's a concern = for later, when we're ready to adopt "full migration" technology (feature-r= ich, efficient, PQC). If Q-day comes before that time, we'll inevitably be = scrambling in a somewhat suboptimal but hopefully survivable world. I don't= think we should optimize for the hopefully short / avoidable temporary "af= ter Q-day, before fancy tech" time, at the cost of (a) reducing the chances= of actually migrating the Bitcoin ecosystem to be Q-ready and (b) incentiv= es and properties in the present time before Q-day.

    I think our disagreement comes from your assumption we must always time= the disabling fork perfectly to coincide with Q-day. On the other hand, I = expect we will not solve the fork timing problem, so an EC disable fork wil= l be a messy, panicked affair, arriving possibly quite late (months or year= s after Q-day). With P2MR, at least holders who used it properly will have = shelter, and those who didn't will have an opportunity to move coins somewh= ere safe to ride things out.

    This is very interesting. I have reservations t= oo about the "Later" EC-disabling soft fork expectations about P2TRv2, but = they're not about whether the future Bitcoin ecosystem can coordinate a sof= tfork; that seems almost trivial if not doing so poses an existential threa= t, and could be done within a few months if it's expected and designed alre= ady. I'm more worried about it not being adopted due to i= ndifference/friction, or being abused/misused. 

    FWIW, I don't think the P2TRv2 EC-disabling f= ork needs to be timed perfectly. The expectation should be just that it hap= pens before Q-day, and when it looks inevitable or the fear about that is l= arge enough. There is certainly some variance there, and there will be some= disagreement, but I can't imagine we don't get at least a year's worth of = notice in the form of breakthroughs on simpler QC problems.

    And if you accept that at least a "Later" option is need= ed, I think adding more PQC options actually weakens it! If some people hav= e their coins in "Never" or "Now" outputs in a PQC-safe manner (subject to = the restriction / costs those bring), then that reduces the incentive to ge= t the "Later" narrow EC freeze to occur, and indirectly reduces the value o= f that output type.
    Inte= resting. It sounds like you're arguing that because P2TRv2 is blatantly PQ-= vulnerable, it will incentivize future bitcoin users to lock it down later.=  I mean yes, that's technically true, but that would be like putting = a spike on the steering wheels of cars, to incentivize drivers to wear seat= belts.

    F= irst a meta-point here: the reason I like separating the discussion into di= fferent dimensions than just "P2TRv2 vs P2MR" is because there are more opti= ons than those two, and not every argument applies to the same separation i= nto two classes. Let me list them explicitly here, roughly in decreasing or= der of how strongly I feel about them:

    1. We need at least a "Later" option for meaningful migration, i.e. P= 2TRv2 or P2MR+ED.
    2. Within the "Later" op= tion, P2TRv2 is preferable.
    3. A "Later" option benefi= ts from being the only PQC migration strategy, making it a Schelling point.=
    =

    If one were to disagree with just (3), other options co= uld be e.g. to introduce both P2TRv2 and P2MR, or even P2TRv2 and P2QR. Tha= t may be easier or harder to get consensus on, I don't know. I think having= multiple PQC migration paths makes the "Later" option less compelling (3),= but even then I believe we still need one (1).

    Se= condly, yes I understand the concern, if you phrase it like that. But I thi= nk this sort of risk exists whether we choose to base the new output type's= security on it or not. I think Bitcoin can only meaningfully survive a = systemic risk of this nature through collective action, at least in the= near to medium term, and the P2TRv2-expected-disabling one has at least a = chance of being sufficient, and is non-invasive. In contrast, one that need= s to freeze non-opted-in coins is likely far more damaging.

    <= /div>
    Should we really bet = the entire network on that incentive working out? Even if you're right and = we all want very-badly to deploy EC disabling later, how can we know we'll = time it correctly?

    I don't see it as a bet. It's an opportunity, and we can choose = to take it or not. If Q-day comes before migration can reach meaningful lev= els (what those are is probably a matter of perspective), then I think ther= e isn't much of an interesting future for Bitcoin anyway.

    Remember, it's no= t just me you have to convince.
    Absolutely! But I think your views probably reflect= those of many others, so getting to the core of things like this thread se= ems to be doing can gain us insight.

    You'd have to convince everyone to deploy and then adopt P2T= Rv2 today un= der the public knowledge that it is insecure and their coins are more likel= y to be stolen. = That's a hard sell.

    How does one pitch P2TRv2 to users? "It will be quantum s= ecure one day we promise because everyone is incentivized to fix it later a= s Bitcoin will die if we don't."

    How do you pitch P2MR? "It's quantu= m secure if you use it correctly."

    To me, the pitch is "Bitcoin can only remain val= uable if we mostly/all migrate." for both. P2TRv2 is just much easier to ad= opt, because P2MR (or any "Never" output type) fundamentally requires many = users to change their workflows entirely.

    This focus on allowing individual users the ability to safegu= ard their coins just feels like a red herring: I'm not worried about my own= coins being stolen. I'm worried about (fear of) a CRQC undermining trus= t in the currency as a whole, or through a fear-driven consensus change the= ecosystem destroying its own values beforehand.
    <= br>
    The simplest example is a hash preimage. With preimage P=E2=80=8B and message m=E2=80=8B, I publish H(P)=E2= =80=8B and H(P, m)=E2=80=8B at time T=E2= =80=8B<= span style=3D"font-family: Arial, sans-serif;">=E2=80=8B. Then I reveal (P, m)=E2=80=8B=E2=80=8B=E2=80=8B at tim= e T+1=E2=80=8B. A ve= rifier checks H(P, m)= =E2=80=8B was published first, and confirms there exist no earlier reveals = for P (by look= ing for H(P)=E2=80=8B=E2=80=8B). This confirms I=E2=80=8B=E2=80=8B must have also approved the message= m=E2=80=8B=E2= =80=8B. A similar mechanism is used as the core coin authentication system = of FawkesCoin. There are complexities to handle e= specially regarding censorship attacks, but ultimately it's doable.<= /font>

    Neat, th= anks for explaining. You'd need some way to attach these to a specific UTXO= (s), I'd imagine, so the information can live with, and disappear with, tho= se outputs. Otherwise you need an boundlessly growing set of H(P) values to= prevent reuse?

    In either ca= se, I consider anything that requires hardcoding specific wallet designs (B= IP32 or otherwise) into Bitcoin's consensus rules (and only allowing those = coins to survive) to be squarely in disaster-recovery land. It feels like e= mbracing arbitrariness, and giving up on the permissionlessness that makes = Bitcoin interesting - if the community shows it can get consensus on effect= ively burning coins except those that match a whitelist, it feels hard to m= aintain censorship-freeness as a value, even if the whitelist includes most= of the (active) coins. That is of course not to say such techniques aren't= interesting to work on, but to me, their place is in disaster recovery sce= narios to save what's left, after Q-day, if migration attempts were unsucce= ssful. In such a setting, I think we're already in effectively an altcoin-w= ith-UTXO-bootstrapped-from-Bitcoin territory, and a (possibly growing) set = of ways to recover burned coins can be hardforked in.
    =
    Because consensus cha= nges take years to deploy, and we're running out of those. Many peop= le seem to think so at least, I'm no physicist.

    I understand the feeling of urgency, but this seem= s like a "we must do something, this is something, thus we must do it!= " approach that just gives people the impression something is being done, w= ithout fundamentally tackling the hard problem of actually migrating Bitcoi= n, and leaving that harder problem to a (to me) very undesirable, but still= unspecified future. And solving that harder problem will inevitably need a= nother consensus change later, so it doesn't help with the "running out of = years" problem if you believe those take too long.
    My impression is that your approach is to have an answer for many possible= futures, including ones where Q-day arrives within just a few years. But o= ptimizing for disaster-recovery also means reducing the chances of preservi= ng Bitcoin as we know it in the scenarios where a successful migration is s= till possible. And if Q-day does arrive that soon, I don't see what we can = do today that would preserve Bitcoin in a form we care about anyway. By acc= epting that, we can focus on the futures where our choices today can still = materially improve the outcome.

    Essentially yes though, I expect the majority= of holders will probably migrate to PQ addresses via rescue protocols, eit= her on Bitcoin or a fork thereof. Even if we can't come to consensus and de= ploy a new output type, we'll still be able to rescue most coins. It's just= that we'd have nowhere to rescue them to, so we ought to make PQ wallets a= vailable soon, so we're not in a rush to build them later when we need them= . If a PQ wallet can use cheap EC signatures while they're still trustworth= y, all the better

    T= hanks, I think that very much highlights a difference in vision. To me, if = we need to mostly migrate to PQ through rescue protocols post Q-day, we've = long lost already. Since it's just not an interesting future to me, I weigh= optimizing for it as a very minor secondary goal at best, and actively dis= tracting at worst.

    Of course, if you believe it's = the only possible future, I understand you'd come to a different conclusion= . But is it really? Do you think this isn't a plausible future:
    <= br>
    • A P2TRv2 type (let's leave as= ide whether P2MR or P2QR gets added too) gets introduced in the next few ye= ars, with hash-based PQC opcodes.
    • Over the course of the next decade or so, it gets adopted by&n= bsp;practically all active users.
    • What happens next depends on whether Q-day happens late-ish or= soon-ish afterwards:
      • Late-ish (incl. never):
        • Isogenies (or something else) get a ton more attention, i= mplementations get more efficient, gain well-studied features like tweaking= and homomorphic derivation, get far better confidence in their security.
        • A P2QR output type with isogeny PQC (or possibly hybrid E= C+isogeny) opcodes get added.
        • Many users migrate over to= this P2QR type, and are fully living in a Q-migrated world.
        • (Possibly) Q-day happens, and nobody cares.
      • S= oon-ish:
        • A (not-quite-CR)-QC breaks 128-bit ECDLP, say.=
        • The community quickly softforks to disable EC paths/opc= odes in P2TRv2. It's messy, spending gets expensive, there are privacy loss= es from PQC key reuse etc, but nothing really breaks.
        • So= me stragglers migrate still, but a large part of the ecosystem migrated alr= eady, supporting wallets are commonplace.
        • Based on how w= orried people are about early-era unmigrated coins, either them being stole= n isn't considered a threat anymore, or they get still widely frozen but it= 's just a minority / presumed-lost coins.
        • Q-day happens.=
        • Accelerated research into PQC schemes gets incorporated= into P2QR, over a longer time period, and eventually the messiness of P2TR= v2 disappears.

    There are many other = possible futures. Some are minor variations of these two scenarios. Some ar= e fairly bad independently of the choice between P2MR or P2TRv2 (e.g. Q-day= comes before any substantial migration). Some are mostly fine regardless (= e.g. everyone has time to migrate to later P2QR isogeny stuff, or just no C= RQC ever). But these two in particular, I think have a much better chance o= f happening with P2TRv2 than P2MR, because far more people can just adopt i= t with low friction.

    Cheers,

    <= div>-- 
    Pieter

    <= /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 bitcoind= ev+unsubscribe@googlegroups.com.
    To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/81QWq= ov2xqthGLjORSKtR2jDDosHG7gjK91LNQ61iIBNRQaJPsu6wTA63d3KjVdROO2VZy5zr3Buo5A8= UXb3Ue5E4zc2qWYn65gRxmmFLKg%3D%40wuille.net.
    --b1=_VrJ4SZJqP9578XIRJSOTptWEA0y3ak5C8B6FoDEY--