path: root/18/bfd00e0f8926f3c0c868b8c2a2eb0725bc399b

Delivery-date: Fri, 11 Jul 2025 11:48:30 -0700
Received: from mail-oa1-f59.google.com ([209.85.160.59])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDL4XL646QOBB5FYYXBQMGQEYL6IKZY@googlegroups.com>)
	id 1uaInN-0007XO-TT
	for bitcoindev@gnusha.org; Fri, 11 Jul 2025 11:48:30 -0700
Received: by mail-oa1-f59.google.com with SMTP id 586e51a60fabf-2e9b1f85b2bsf2666914fac.0
        for <bitcoindev@gnusha.org>; Fri, 11 Jul 2025 11:48:29 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1752259704; cv=pass;
        d=google.com; s=arc-20240605;
        b=OGPoc81Fx7e7VodkME+WnO+tYypxwbNwX6f+nak6MCYjAkm/Q6V8FToSoVKaeEoROD
         xy/acI+AyJbvuohFVu54Rfn1Du/A5Vlw6Ew4eYJY7tkdI65f0gYRtS0/gHONiJDDElNZ
         Jv3l3gxqVspfiU0luKf1smMQq/RbLhfUwSO9PSG3i94nGdxmEUohwJgpRnKXEnDYGf+j
         47vA869iJJW0ndwZpicJPzWt2sVJae2xs6Jk/Zi8/E+QmUIEoFLs6gDagmP52VFhAzai
         zP43GHDM4PuZZdB0RZMkxNXnPFyXTnarS9NaQnm6TxzQZbYfMQdX81Uj1DkYCYqTbKBk
         ZzLg==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id
         :references:in-reply-to:message-id:subject:cc:from:to:date
         :dkim-signature;
        bh=4p8udwMCasT9M6dqToXPGyaO5p8CuZKsuvvVTWdILEo=;
        fh=8d9t483TS9r4bg/GeK4q16zz1DaZhBOixi3Dfaov7g8=;
        b=S529GnbCjhj6AX+tdGlPhED+ONlhVdl5iRnujQ3QnugO7cDEgbH2xfkmr5RBEL2oJs
         5+0UISkqTJ7yHlIa6a3ykK5WGB1B2KO+BZNyxTBVdoYSqDlXmqGMb+RVONNuOtq5guy1
         /dBOARgo+WIIGyJ72LfObm3QHgnBy7ij1RXSwSqGvcDJn5Z6AC3w9+bDjq+e43NN2IxE
         aX4teXp5mo+4H+HhpQ/2xhOL3Gi/3uNuFqLTWDb/OuUhVENmrm69o7NA3eDaL45KOD+P
         j8ASYFqdbsnyDuqqLX5Usq8xA4R2lqrsIcNrPydrOQVp0gsjcM8M9WzduJcZKAufGyRC
         MdIw==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=bgPgI3I8;
       spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.16 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1752259704; x=1752864504; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to
         :x-original-authentication-results:x-original-sender:mime-version
         :feedback-id:references:in-reply-to:message-id:subject:cc:from:to
         :date:from:to:cc:subject:date:message-id:reply-to;
        bh=4p8udwMCasT9M6dqToXPGyaO5p8CuZKsuvvVTWdILEo=;
        b=pArn13wDgEo9ESQ7wUoOr0zJhMZRNiUTOPxR9Ke6frw46BCiherQapeXcmxizWbhZH
         QEXlEuRyTSvXg8vCqIWbdcO78l3oGb4Cl/EWqP2GvkXeXOVQgO4wyhac4kSTApKLaIk8
         fZewesR8xXAC42uQC5JKM4JRdt8/CVytKx/wYzKOLZXdDrdtcBCSvdd+8PArjDOneoiv
         vxgX7J229pgRvkMrcUi9sPbvHYBcY2SezW+iULzGgfIMJp/YCqNxnPoDKybHENnkCpoi
         /vguEie1WLm9Im3lg7DiXbRU87HX5CwLy3OV/k8AyoflprJBWerZrNBoqorBSAudR9Vq
         72Dg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1752259704; x=1752864504;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to
         :x-original-authentication-results:x-original-sender:mime-version
         :feedback-id:references:in-reply-to:message-id:subject:cc:from:to
         :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=4p8udwMCasT9M6dqToXPGyaO5p8CuZKsuvvVTWdILEo=;
        b=G4fwN4H7fQVTmnRzEfVD+FeG/+jv9ST0YLkudXblfS+g1eNgdz2KRcsCi0Vlp59ciW
         I09IZtvjm2dPWuCQuwsOubGNVFkVMBfbwUv8SpQ4KWnh1n7iB82AC/Yi50loSoJjgYMA
         oGu5rhs1ngX9KcDoUbMPCx4hMA1k2gS0iy7QH/QdT4iiX4/rpmTPVUNz0gbKfz604/qq
         B8a1POyNuNJZoCf78n18Uk2fdDt0k2IjRu5xjP5AvV/eIcZTm3m0BAo+TK7KjlHv2Ru3
         fijsW6QrWuNUpBbQEyreamGUMmW7xZH36ziGrP82FPd0TBH1+I/yIqDsQmsUOdLGM0N9
         LP8Q==
X-Forwarded-Encrypted: i=2; AJvYcCWwSYdiiAXCUPMmrcX9LzRXSdWf83tiNG2mnfp2q15/C01vKJssIiDlLWXzIxBuEBtLMBE2kHV5jblr@gnusha.org
X-Gm-Message-State: AOJu0YxMlbN9xwaD044CDSPihoSYcxjLoKiRjMHmfsVoDGEAUNJHQFgr
	7KdmT8aDYO/z0CeGLXThR6KvQFScKR09U5TctTsHL0noLO7vSiOUFN47
X-Google-Smtp-Source: AGHT+IF6ysly9W5Td3oLyt+3sheT3uaLG5H4zQjRMsap2YekDQYTjmviheV6eqfus0rGODYZ+Ro46g==
X-Received: by 2002:a05:6871:a112:b0:2e4:4617:f6e1 with SMTP id 586e51a60fabf-2ff26e79dcamr3335938fac.2.1752259703542;
        Fri, 11 Jul 2025 11:48:23 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZeoGk0yWFvg414lappG1GsapWsoejYQKDOmxPZvV0MVVQ==
Received: by 2002:a05:6870:3054:b0:2c1:8546:7864 with SMTP id
 586e51a60fabf-2ff0bcc7901ls824106fac.2.-pod-prod-07-us; Fri, 11 Jul 2025
 11:48:20 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCUphYo38UkbQ7QDNB0UcvP2NkH/bWmu2MPmoI1t2H/+X909fl1jJ5v0cG9BBPSb0KGurx/i6IFnzicc@googlegroups.com
X-Received: by 2002:a05:6808:168a:b0:406:6e89:499f with SMTP id 5614622812f47-4153a27fef0mr3411628b6e.35.1752259700449;
        Fri, 11 Jul 2025 11:48:20 -0700 (PDT)
Received: by 2002:a05:600c:6089:b0:450:ce23:93de with SMTP id 5b1f17b1804b1-4538ed863cams5e9;
        Fri, 11 Jul 2025 11:37:42 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCVDUkUXd1KCFK7NfwO+gj1b0+iYc8u7grB6df54litBASc2VHjVAxFZJ0D2u9CZW+lPCHCD9UKYQ7Jc@googlegroups.com
X-Received: by 2002:a05:6000:2806:b0:3b3:e29:bda7 with SMTP id ffacd0b85a97d-3b5f187d355mr2903866f8f.9.1752259055146;
        Fri, 11 Jul 2025 11:37:35 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1752259055; cv=none;
        d=google.com; s=arc-20240605;
        b=JHHx+FqVW1eGi/e5deBYdj3My9+eex2fZ2vbAXRetzB+YW81JCKa+a41KRc1ygMUne
         aSW+Js08cFIOTWHSq/PtduTk6Djj7C5iLltMEtnyMUmAs0YeI6DCFhzfDu0QEoIHAoBq
         X6BMJrAydpyQqpYcfqHxQw18NI1auwYR1LrQ3qr0FrZm4yxdd5ZVrNJ3dH5/SQFlTs/v
         cH3bEsEGj1aDYK5E6X67MVeMEqB+swXvqGkRpib+Ylgd1ea6Bwd8/Gf5QGR1TKMVppky
         8MOLmWgmuEZ0gwnYzs7khJrzdTfnLO3Ip24EAImizP8TSC2QShQkszezeHkHwX18/nbN
         Mjcw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=content-transfer-encoding:mime-version:feedback-id:references
         :in-reply-to:message-id:subject:cc:from:to:date:dkim-signature;
        bh=2za3/C6ASLTSdD5RbdySi8fGO/pUkU4IM76d3MkVAo8=;
        fh=2GrigbsrOQbyEDwLakImaK9x8AKyAYXirBaHYK+psY0=;
        b=bou+vMsVtfwhZaJoV2fKolE9YciFKu4zhO19Ub36705sM/Mw/Yk8cxDnn95dJJp4ex
         lleRhtpi0hvdCWsnojORZU4T60pX50yHbtSQ/d3wRrPJAr6mJuSEY47xL5Oddt8BrVV2
         vgnT70K3DFZRSfmPqp4p3VlKy5JULCzlNHdDg9bQcBmYJm+hlQm+Wq7hTkIwaZh9jQle
         Ow2okIStSGxTjX5EjE+XDid5AYAtjH+MBoPsHyHDm/hZjyyDqfiu7bIro+glc89zBofD
         bFunhJV3tfxwVtr49tKChaFM4mfxsDWI4AtouLZYByjpEBjkeYhR6ybGM4QfRmRB/VDw
         A4Vg==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=bgPgI3I8;
       spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.16 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch. [185.70.43.16])
        by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-3b5e8e139c3si126765f8f.8.2025.07.11.11.37.35
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Fri, 11 Jul 2025 11:37:35 -0700 (PDT)
Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 185.70.43.16 as permitted sender) client-ip=185.70.43.16;
Date: Fri, 11 Jul 2025 18:37:31 +0000
To: James O'Beirne <james.obeirne@gmail.com>
From: "'Antoine Poinsot' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Cc: Greg Sanders <gsanders87@gmail.com>, Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] A Taproot-native (re-)bindable transaction bundle proposal
Message-ID: <_POzkO7sHDURx6skGAWsrxN_UUtN_6Ak6donzVhmzYzAV6Ej22jBnE2baxM_WtqxW2RNvDjze72kOVgowNhqGSJ1dg5m_HTO3FuG6QM5daw=@protonmail.com>
In-Reply-To: <CAPfvXf+E0YDzqY_jsGVoc4KKh_Kgsp-p20wNAD05tv_rMNG2sA@mail.gmail.com>
References: <26b96fb1-d916-474a-bd23-920becc3412cn@googlegroups.com> <CAPfvXf+E0YDzqY_jsGVoc4KKh_Kgsp-p20wNAD05tv_rMNG2sA@mail.gmail.com>
Feedback-ID: 7060259:user:proton
X-Pm-Message-ID: 3aa9fe5dd3be553a257cddb040f60faa4ce7a3f8
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
X-Original-Sender: darosior@protonmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@protonmail.com header.s=protonmail3 header.b=bgPgI3I8;
       spf=pass (google.com: domain of darosior@protonmail.com designates
 185.70.43.16 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
X-Original-From: Antoine Poinsot <darosior@protonmail.com>
Reply-To: Antoine Poinsot <darosior@protonmail.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -1.0 (-)

Hi James,

Thanks for your interest in our proposal.

You point that the annex commitment may prevent someone who pre-committed to a spending transaction
through OP_TEMPLATEHASH from using a different annex at spending time. Annex commitment is important
for rebindable signatures, but also for committing to the spending transaction: it allows to be
forward-compatible with future uses of the annex (from proof of publication not requiring an
additional signature to being able to pre-commit to any consensus meaning the annex may be given
in a future soft fork). In this regard it is no different from other fields of the transaction
that are today defined at spend time and OP_TEMPLATEHASH would allow to pre-commit to.

You list 3 examples where you claim a user who has committed to the transaction to spend his utxo,
turns out to be willing to use a different annex than the one committed. The first example lacks
citation: could you explain the exact scenario with CISA here? The next two examples i don't think
make sense. First you point to my amounts check idea, but these only ever make sense if you haven't
already completely committed to the spending transaction! If you have pre-committed to the spending
transaction through OP_TEMPLATEHASH (or even OP_CTV for that matter), you have already committed to
how the value from this output will flow into the spending transaction's outputs. Same for your
third example, the SIGHASH_GROUP idea: what's the point in having a signature that commits to part
of the spending transaction's outputs when all of those outputs are already set in stone through an
OP_TEMPLATEHASH commitment?

I think a better argument for your position is that pre-committing to the annex weakens the upgrade
hook it provides: it could arguably increase the risk of invalidating someone's coins if/when the
annex is given meaning in the future. I would object that first of all pre-committing to the
offending annex only marginally makes it worse compared to pre-signing it, and more importantly if
we think people would design software that create such transactions in spite of the very clear
warning "users SHOULD NOT include annex in transactions, or it may lead to PERMANENT FUND LOSS" then
all bets are off. By this token, users may commit to other upgrade hooks: a higher nVersion, future
Segwit versions in transaction outputs, etc.

Your second main criticism concerns the lack of Segwit v0 support. You start by cherry-picking some
data about Taproot's usage, so i'll ask you to please keep the discussion honest here. You state
that between 0.1% and 0.75% of all bitcoins in existence are held in P2TR outputs, and use this
figure to conclude the "overwhelming majority of **value transfer** in bitcoin is still happening in
a pre-Taproot script context". This non-sequitur reads as though you'd already settled on the
conclusion and were reaching for data that might appear to support it. In 2024 and 2025 between 20%
and 40% of all onchain transfers used Taproot[^0] (vs between 1% and 3% for P2WSH). Even
considering the value of these transfers gives a pretty clear trajectory: since the beginning of
2024 the percentage of BTC getting locked into P2TR outputs quadrupled from 2.2% to 8.5%[^1] (the
percentage for P2WSH was steady from 16.4% to 16.8%).

I strongly believe our default position should be to only enable new features in the latest
iteration of the scripting system. While Segwit v0 fixed the most important quirks of legacy Script,
Taproot/Tapscript finishes this work by removing the remaining instances of quadratic hashing,
enforcing by consensus more malleability-related standardness rules, being compatible with batched
validation today and a possible future CISA, and finally presenting the slight but still good to
have privacy improvement that all outputs look the same before being spent (and sometimes even after
being spent although it's harder to achieve). We should not provide new features for an outdated
scripting context unless we have a strong reason to.

I don't think you provide a strong reason not to stick to Tapscript. You claim that many industrial
players would not be able to use OP_TEMPLATEHASH but you don't back it up with anything
demonstrating those companies 1) desire to use OP_TEMPLATEHASH and jointly 2) are somehow unable to
upgrade from P2WSH to Taproot.

Regarding your non-blocking gripes, let me state that P2TH is still very much on the table (like any
other change really). If an optimisation for congestion control is really important, using a new
Segwit version would be worth it, and the implementation is trivial (and is even more so if you end
up being correct regarding annex commitment). We are just all three of us very unconvinced that it
is in fact worth it, as are many others it appears.

Best,
Antoine Poinsot

[^0]: See https://mainnet.observer/charts/inputs-types-by-count and
https://mainnet.observer/charts/output-type-distribution-count
[^1]: Hovering the percentages for dates 2025-07-07 (closest i could get to today) and 2024-01-02
(closest i could get to 1st Jan 2024) at https://mainnet.observer/charts/output-type-distribution-amount.


On Thursday, July 10th, 2025 at 9:04 AM, James O'Beirne <james.obeirne@gmail.com> wrote:

> Hi Greg,
> 
> Congratulations on the BIPs and happy to see a concrete counterproposal
> from you and the coauthors.
> 
> While the simplicity of the BIPs and draft implementation are
> refreshing, I see a few issues relative to BIP-119:
> 
> # Annex commitment
> 
> TEMPLATEHASH commits to the annex, whereas CTV does not. I think this
> poses some potential issues.
> 
> We don't know what the annex will be used for yet. BIP-341, where the
> annex is defined, writes
> 
> > Until the meaning of this field is defined by another softfork, users
> > SHOULD NOT include annex in transactions, or it may lead to PERMANENT
> > FUND LOSS. [0]
> 
> To date, no other widely adopted BIP has spelled out exactly what the
> annex will ultimately be used for.
> 
> The germane thing in this case is that the annex contents are specified
> at *spend time*, whereas the CTV or TEMPLATEHASH hash must be
> precomputed before the creation of the UTXO.
> 
> If the hash must know the contents of the annex prior to spend time, it
> fundamentally constrains how the annex can be used in conjunction with
> TEMPLATEHASH (since you have to anticipate the contents of the annex).
> 
> Some conceivable uses of the annex that have been floated are:
> 
> - for cross-input signature aggregation,
> - for amount checks in aggregate vault operations[1],
> - for implementing some SIGHASH_GROUP-like function[2].
> 
> To me it isn't inconceivable, and is perhaps even likely, that the use
> of the CTV-like functionality and some of the above future examples
> might overlap.
> 
> Rather than bundling a commitment to the annex with TEMPLATEHASH, it
> would seem more prudent to defer treatment of the annex until we've
> decided what it is. It might ultimately make sense to have some
> orthogonal opcode ("OP_CHECKANNEX" or something) that allows script
> authors to explicitly specify annex expectations.
> 
> 
> [0]: https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki
> [1]: https://github.com/bitcoin/bitcoin/commit/2c63a983ddb7f2b7eaaedc8313fbeaf8f7c1b128
> [2]: https://gnusha.org/pi/bitcoindev/20220305055924.GB5308@erisian.com.au/
> 
> 
> # No witness v0 (segwit) support
> 
> I think the lack of TEMPLATEHASH's availability in a witness v0 script
> context will significantly limit its deployability for at least the next
> few years and possibly permanently for some users.
> 
> Right now two separate estimates put Taproot usage (by value) at
> 0.1% or 0.75% as of May 2025[3][4]. This is nearly four years after its
> activation. We can't say exactly why users aren't upgrading, but the
> reality is that the overwhelming majority of value transfer in bitcoin
> is still happening in a pre-Taproot script context.
> 
> One concrete impediment to Taproot adoption among custodians is the lack
> of native HSM support for the Schnorr signature scheme. It's reasonable
> to believe that some already-deployed HSM contexts may never get to
> Taprootability.
> 
> While the TEMPLATEHASH authors don't acknowledge vaults in their
> proposal, there is popular demand for CTV on the basis of being both a
> simple vaulting mechanism[5] and a necessary ingredient for more ergonomic
> vaults[6]. Much of my own professional grounding for supporting CTV stems
> from this use.
> 
> TEMPLATEHASH's lack of witness v0 support hampers this use, and prevents
> many industrial users who are (for varying reasons) stuck in a wit-v0
> world from making use of the simple vaulting primitives that much CTV
> interest comes from.
> 
> [3]: https://www.unchained.com/blog/bitcoin-address-types-compared
> [4]: https://research.mempool.space/utxo-set-report/
> [5]: https://github.com/jamesob/simple-ctv-vault
> 
> To date I haven't heard any concrete downside of including witness v0
> support for an opcode like this other than "it's marginally more to
> think about during review."
> 
> The reality is that we're still living in a witness v0 world; there will
> be significant amounts of wit v0 traffic for the foreseeable future. To
> throw that context aside is to ignore many potential users.
> 
> # Non-blocking gripes
> 
> I'm disappointed by the lack of consideration for the succinct "deferred
> payout" or "congestion control" use that is provided by either bare CTV
> or your P2TH ("witness v2") patch, but that isn't surprising given the
> unwillingness on the part of the authors to acknowledge the potential
> value of that use.
> 
> Even though it's disappointing to me, its absence here wouldn't hold up
> my support for the proposal.
> 
> ---
> 
> I'm glad to see progress on the prospect of making bitcoin's script more
> useful, thanks for your work.
> 
> James
> 
> --
> You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAPfvXf%2BE0YDzqY_jsGVoc4KKh_Kgsp-p20wNAD05tv_rMNG2sA%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/_POzkO7sHDURx6skGAWsrxN_UUtN_6Ak6donzVhmzYzAV6Ej22jBnE2baxM_WtqxW2RNvDjze72kOVgowNhqGSJ1dg5m_HTO3FuG6QM5daw%3D%40protonmail.com.