path: root/b0/5254ef59797835179c8def08f7000b7132d3a9

Delivery-date: Wed, 12 Mar 2025 03:53:25 -0700
Received: from mail-oo1-f60.google.com ([209.85.161.60])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDN456FOY4IRBHGPYW7AMGQEF3I7MHY@googlegroups.com>)
	id 1tsJiG-0000Q4-K7
	for bitcoindev@gnusha.org; Wed, 12 Mar 2025 03:53:25 -0700
Received: by mail-oo1-f60.google.com with SMTP id 006d021491bc7-5feb2ce9b27sf4858831eaf.3
        for <bitcoindev@gnusha.org>; Wed, 12 Mar 2025 03:53:24 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1741776798; cv=pass;
        d=google.com; s=arc-20240605;
        b=icY2HKiDWfJpxYsF89o2bPhkwQfFRzigQXoM17J2iKjnN8yE1umTSM4UOtkJrMmtdq
         m8ZIsuBvOKPvbYRoC5Qs8SvfEDmXpdCN1IKjoO/Dk5cCksiUs0PHReoabuFXqK/3i55I
         mmTuFLWzWGnm+FxV3q+InS/eVwyiQxsyBh4QV2kNFzWiQzO+wRj6BVS/ZhfiIHhjrJOu
         Ao/MRNfoFdbxlgh+z7EYE+BJ436S18qO57YY5CYv72RcFT9Qb4uwi1AFeoF/hEcFD8+A
         Q0WzI1tKkCv9PZ/YoIbjyERgvgkefzmxVGDgafaoUBmZ5obtRlmQxSG8K13hOAIWz5gR
         y8qg==
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:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:sender:dkim-signature;
        bh=9CtijYEX/4w+eoy5KOkQkjfRlD6ynEHnkx+iHdnCdHE=;
        fh=f1vlMwc+T7ggf19vANSlLpViT09f3s0GpuPPiuPVc2U=;
        b=UTht/Ne7tc4C6UujibZkXf/LMjmMrEVWlN3OytP+7aSQHcoHFkvP8CsBjWTUTB+vCV
         ORvAU/2EwpNA43JT98pqE96X2QfL/rBhnQrEiDifh7VleJt0fLZxdgajfbiJbLXYhzSA
         FLGpZwy5Z/rSXUO34KlYi/gO6QIO/+L2yiwzs6ToRbOyQduwKYosuVyfnu+qER3p5IA9
         yVL7X9/o8JI77NT29AciKJ7TIpHSjtwjpYZqCv+FwIr+hxgGCM7yM4IK9NPML1b4rUrZ
         QeDFzUK2C4puinENuLNlHRKAqeZ6xQf72WA0c0OAU1poF/K3CyzvsoUIGfjAkPvvgeBi
         HW0A==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@shesek.info header.s=google header.b=Y51ieZA+;
       spf=pass (google.com: domain of nadav@shesek.info designates 2607:f8b0:4864:20::b2a as permitted sender) smtp.mailfrom=nadav@shesek.info;
       dara=pass header.i=@googlegroups.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1741776798; x=1742381598; 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:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=9CtijYEX/4w+eoy5KOkQkjfRlD6ynEHnkx+iHdnCdHE=;
        b=ivhVlkdbo6zi9xnuomHIgHU5BKeijz4+n5arpg1Jhl90NI41Kk6BdwWNYCECcvP0A5
         z5BP/UwMi/qPsHSqzj9ZprfoNsV2LdXWtWUHpujx26p/8/c569OmekozXA5Pf0rAOV87
         mcpLuvQwILna3kW+JYD4e/wZ73gOWPoxq9WpQvvX6yPLPje5xV0k5WYM+vJJX+Rd884h
         hbNHPhpOe8uahcIup3B3VslLvbx8hn0jg+sRTq8+scGRn/3H4Ss4aDd6f25/7Jej8Iew
         mEBgyPWrOUVORxD76fshoGQ/hZvUccCSYJABomWWJPEA6aZiojGI1JLmJBmslKzyBHAz
         KiPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1741776798; x=1742381598;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-beenthere:x-gm-message-state:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=9CtijYEX/4w+eoy5KOkQkjfRlD6ynEHnkx+iHdnCdHE=;
        b=nswXc5LKjg9qFq0Exu/XcW0l7oCkY/VZ/1PXeRqvrL312YgbbNwTGhSJdjtk/poBdc
         1k1jxKkjORaiKJoVVfNczHlB1mZ03SlHdjal/rpmDNeKjoR6Y7Y+tmOUpOhL3gi7RZNc
         ppj8NTulK2QvETD1T3W61y78VCoI50OeIEFp6+mlY3F1+yPua00gPyd0Tg6QYTcuqVq9
         fH5N0m/ei3IxJsvzgpxV6Vd99k0dVKWZ3b945sIz1kNlpRML91jNQIt+x2NSzILSgnlH
         rnid7CYBH1ag2VZTu5NxvPmiNpiGQSzUpbtcHqc0NucL+cYgp02AqnWHUNwpQo2R0h9A
         FahQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCXG5jLH2UW6LFip/vEMKndOOtJusP37O5Co5SNANjAu1Q22em83Cilu63HzKzB4p/Gg/+9gRI4Am/bp@gnusha.org
X-Gm-Message-State: AOJu0Yy2TSQCl4+wwIipkWFAWBLDZJ4A13mPPPodmTNI0AclrFg2F54H
	IZa2Z0sFwZYUmnonY822yRRAHourxNrZnteDEBiyf4tJPdICWj28
X-Google-Smtp-Source: AGHT+IHaTAmI4cS4UR09DDV3Dirlu+emLRAMFJAY59jnknWjKB4TqlEiP2l/ip48qv5qPvZ16Es2ZQ==
X-Received: by 2002:a05:6820:210e:b0:601:ce76:c46a with SMTP id 006d021491bc7-601ce76c7f8mr1288064eaf.0.1741776798504;
        Wed, 12 Mar 2025 03:53:18 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVElSmANZKWkpiH6Z+t2T6GbqqanB0epCzOJMEhq9I25hw==
Received: by 2002:a4a:d518:0:b0:600:33e3:2af with SMTP id 006d021491bc7-6003e8f62e4ls1582978eaf.0.-pod-prod-08-us;
 Wed, 12 Mar 2025 03:53:15 -0700 (PDT)
X-Received: by 2002:a05:6808:13c1:b0:3f8:f8c6:5518 with SMTP id 5614622812f47-3f8f8c665edmr5821406b6e.11.1741776795796;
        Wed, 12 Mar 2025 03:53:15 -0700 (PDT)
Received: by 2002:a05:6808:207:b0:3fa:6f09:b173 with SMTP id 5614622812f47-3fb50305f9emsb6e;
        Wed, 12 Mar 2025 03:02:39 -0700 (PDT)
X-Received: by 2002:a17:902:ce8f:b0:224:1c41:a4bc with SMTP id d9443c01a7336-224288951edmr330700965ad.12.1741773758761;
        Wed, 12 Mar 2025 03:02:38 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1741773758; cv=none;
        d=google.com; s=arc-20240605;
        b=hG5o6x5yKrlVchfAaMw4hCUrSQ3UdX1gE8VaQLBTRLf1lsYL6IH9bGsYquB95D3YFC
         wPnSFGKichqzu161MJO0nB3KhktwDkJtna2bqe5OOy8SlRCkIMz9kY4RBXH+xpN+r2hF
         XJbrL9t+wwYLLgIYntIAcbxehvhbwVGN6XwKijKXUuUjAWV+1U/P3SNPR7hsnJ7mvzLe
         UIIDLb+SHoPLfcGR8tsYR9VWeSAdTA1GwYWzd40fvgK62REuLrBf8u3U6pOkQNIBtdtp
         NPCmjWpLnJ1jaTHD78kbff6DHZKFeHStGK6utdQqAFzjgkXkwfVHfVT64RScWYs//M86
         6L5w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=8krMfHbWzVDqqmlsnBdUOqmR0UgvnlptiiwdcdbWZ4Q=;
        fh=ZhIePvtzD2qBgm9PadABf9spV2moFvlPRwwE8o08T1o=;
        b=UlLdaxMmrBScDktfUNlIiJto+z0sr1nTDnl+jhyZ5+E6BiGpl8bnx35qhgxN0/WYed
         oA5mIYmXkREoi9h/zXpZuP/D6NHb/FcgLZrOOvTocWlJf+q7N76n7Uxn+KjAVp8JEFKA
         zuVA7LYfzw6Rj/NncjfMRowjp55b6scdkcU/YAlVin6U/PQSncPhfFCpRISzvOGqBuaN
         FhTYZHAcaKr1KF8Wzrf6XcV51+FnZkS1hDBoNPsm+8BACTKCeIBUYwWqViTY1Qo90Hrj
         QAxUzc9Xf0cJGqxUSPHGbiOx69LYmMOfiSlkjqbq+9JfzV7/6HtNBgbF1lswnT3h0vGw
         SrNQ==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@shesek.info header.s=google header.b=Y51ieZA+;
       spf=pass (google.com: domain of nadav@shesek.info designates 2607:f8b0:4864:20::b2a as permitted sender) smtp.mailfrom=nadav@shesek.info;
       dara=pass header.i=@googlegroups.com
Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com. [2607:f8b0:4864:20::b2a])
        by gmr-mx.google.com with ESMTPS id d9443c01a7336-224109d01b7si6506375ad.2.2025.03.12.03.02.38
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Wed, 12 Mar 2025 03:02:38 -0700 (PDT)
Received-SPF: pass (google.com: domain of nadav@shesek.info designates 2607:f8b0:4864:20::b2a as permitted sender) client-ip=2607:f8b0:4864:20::b2a;
Received: by mail-yb1-xb2a.google.com with SMTP id 3f1490d57ef6-e455bf1f4d3so4908349276.2
        for <bitcoindev@googlegroups.com>; Wed, 12 Mar 2025 03:02:38 -0700 (PDT)
X-Gm-Gg: ASbGncunsjP1aqEuBPxn+3F3ni+08ZSoyAdeWnf5o4pM82T8UIzZgsrBrd8oqV7aeLx
	QmsdgfVefpk65rZo2OI0GXNVfFo8axFeGya/P3rztkGDT4JJ6DSLVPN3icgpUpEdEhKacvxgWf9
	/7q6tFZoJ7bJamA+zF5l7YJef2m0IOxGMVsbCevtlwK6uoBGTXoNQfKEAXLuEwatb2o7H69gw=
X-Received: by 2002:a25:15c3:0:b0:e63:823d:bc98 with SMTP id
 3f1490d57ef6-e63823dc5famr15786058276.23.1741773758059; Wed, 12 Mar 2025
 03:02:38 -0700 (PDT)
MIME-Version: 1.0
References: <Z8eUQCfCWjdivIzn@erisian.com.au> <CAGXD5f3EGyUVBc=bDoNi_nXcKmW7M_-mUZ7LOeyCCab5Nqt69Q@mail.gmail.com>
 <Z9ED_dez7_UHxjK0@erisian.com.au>
In-Reply-To: <Z9ED_dez7_UHxjK0@erisian.com.au>
From: Nadav Ivgi <nadav@shesek.info>
Date: Wed, 12 Mar 2025 12:02:27 +0200
X-Gm-Features: AQ5f1JqcRvSGVe4UfYtNhI3wlT9KmDsd6X5UBcu-yGbkF-zNPLZ34FQXmoAiK0E
Message-ID: <CAGXD5f3zHuwGq+M1jwBJjpEc3Wd8biwjwnrXu6VhrysQeyivLQ@mail.gmail.com>
Subject: Re: [bitcoindev] "Recursive covenant" with CTV and CSFS
To: Anthony Towns <aj@erisian.com.au>
Cc: bitcoindev@googlegroups.com
Content-Type: multipart/alternative; boundary="00000000000020f3310630224efe"
X-Original-Sender: nadav@shesek.info
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@shesek.info header.s=google header.b=Y51ieZA+;       spf=pass
 (google.com: domain of nadav@shesek.info designates 2607:f8b0:4864:20::b2a as
 permitted sender) smtp.mailfrom=nadav@shesek.info;       dara=pass header.i=@googlegroups.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: -0.7 (/)

--00000000000020f3310630224efe
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 12, 2025 at 5:48=E2=80=AFAM Anthony Towns <aj@erisian.com.au> w=
rote:

> I think the original COSHV implementation had the hash appear a push
> *after*
> the CTV opcode.
>
> https://github.com/JeremyRubin/bips/blob/op-checkoutputshashverify/bip-co=
shv.mediawiki


Yes you are of course correct. My memory failed me, should've looked up the
BIP :)

With either APO or CTV alone you can do an arbitrarily long chain of
> commitments,

adding CSFS and discarding the CSFS private key allows
> you to have a single commitment that can be reused indefinitely.


With APO alone, you can use one of two constructs:

1. Trustless, Finite - using a chain of pre-computed transactions where the
signature for the next transaction is committed to in the scriptPubKey.
This has similar properties to what you can get with CTV alone.

2. Trusted, Infinite - using a simple non-committed signature spending back
to the same address. This has similar properties to your CTV+CSFS construct=
.

Does adding CSFS enable any additional designs?

I think it's impossible to get Trustless, Infinite short of having full
introspection abilities (CAT/TXHASH/Elements-like), right?

With Elements it's pretty straightforward, something like
`OP_PUSHCURRENTINPUTINDEX OP_INSPECTINPUTSCRIPTPUBKEY <0>
OP_INSPECTOUTPUTSCRIPTPUBKEY OP_ROT OP_EQUALVERIFY OP_EQUAL`

You could have CTV commit to two inputs, with the second input's entire
> value being burnt to fees, but that's fairly annoying


Yes, preparing an exact-sized utxo for fees is indeed annoying. However
it's not much different from CPFP - an extra tx with the same overall
number of inputs/outputs, only around 46vB less efficient[0] (assuming you
need change[1]). So at least for some use-cases it's not terrible either.

One important difference is that for a BMM-like bidding system, losing bids
would still pay tx fees (and take up chain space) for creating the fee
utxo, unlike with CPFP where only the winning bid pays fees. But for other
cases, the difference would be negligible.

Of course, the most WU-optimal construct is APO|SINGLE (implying ACP) that
you mentioned, where no extra transaction is needed at all.

[0] Assuming you need to use N coins for fees and that change is needed,
with an exact-sized fee utxo you have a N-in, 2-out tx to prepare the fee
utxo, then a 2-in, 1-out for the main tx - for a total of N+2 inputs and 3
outputs. With CPFP, its 1-in, 2-out for the main tx, then a N+1-in, 1-out
tx for the CPFP fee bump - also for a total of N+2 inputs and 3 outputs.
However, with CPFP you could use Pay-to-Anchor (while the fee utxo has to
be key-encumbered), saving 65WU for one input plus 30vB/120WU for one
output, making it more efficient by a total of 185WU/46vB (assuming the fee
utxo uses key-path P2TR).

[1] If you happen to have an existing utxo to pay fees with, the 2-input
CTV template would be as efficient as it gets, on par with APO|SINGLE. This
can be extended to combos of multiple utxos, by adding more CTV tapleaves
for different numbers of inputs (at a slight cost of larger control
blocks). With large wallets it could be plausible to find such combos.

Cheers,
shesek

--=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/=
CAGXD5f3zHuwGq%2BM1jwBJjpEc3Wd8biwjwnrXu6VhrysQeyivLQ%40mail.gmail.com.

--00000000000020f3310630224efe
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote gmail_quote_container"><div dir=
=3D"ltr" class=3D"gmail_attr">On Wed, Mar 12, 2025 at 5:48=E2=80=AFAM Antho=
ny Towns &lt;<a href=3D"mailto:aj@erisian.com.au">aj@erisian.com.au</a>&gt;=
 wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I think the original COSHV implementation had the hash appear a push *after=
*<br>
the CTV opcode.<br>
<a href=3D"https://github.com/JeremyRubin/bips/blob/op-checkoutputshashveri=
fy/bip-coshv.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github=
.com/JeremyRubin/bips/blob/op-checkoutputshashverify/bip-coshv.mediawiki</a=
></blockquote><div><br></div><div>Yes you are of course correct. My memory =
failed me, should&#39;ve looked up the BIP :) <br></div><div><br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex">
With either APO or CTV alone you can do an arbitrarily long chain of commit=
ments,</blockquote><div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">a=
dding CSFS and discarding the CSFS private key allows<br>
you to have a single commitment that can be reused indefinitely.</blockquot=
e>=C2=A0</div><div>With APO alone, you can use one of two constructs:</div>=
<div><br></div><div></div><div>1. Trustless, Finite - using a chain of pre-=
computed transactions where the signature for the next transaction is commi=
tted to in the scriptPubKey. This has similar properties to what you can ge=
t with CTV alone.</div><div><br></div><div><div>2. Trusted, Infinite - usin=
g a simple non-committed signature spending back to the
 same address. This has similar properties to your CTV+CSFS construct.</div=
></div><div><br></div><div>Does adding CSFS enable any additional designs?<=
/div><div><br></div><div>I think it&#39;s impossible to get Trustless, Infi=
nite short of having full introspection abilities (CAT/TXHASH/Elements-like=
), right?</div><div><br></div><div><div>With Elements it&#39;s pretty strai=
ghtforward, something like `OP_PUSHCURRENTINPUTINDEX=20
OP_INSPECTINPUTSCRIPTPUBKEY &lt;0&gt; OP_INSPECTOUTPUTSCRIPTPUBKEY=20
OP_ROT OP_EQUALVERIFY OP_EQUAL`</div><br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">

You could have CTV commit to two inputs, with the second input&#39;s entire=
<br>
value being burnt to fees, but that&#39;s fairly annoying</blockquote><div>=
<br></div><div>Yes, preparing an exact-sized utxo for fees is indeed annoyi=
ng. However it&#39;s not much different from CPFP - an extra tx with the sa=
me overall number of inputs/outputs, only around 46vB less efficient[0] (as=
suming you need change[1]). So at least for some use-cases it&#39;s not ter=
rible either.</div><br><div>One important difference is that for a BMM-like=
 bidding system, losing bids would still pay tx fees (and take up chain spa=
ce) for creating the fee utxo, unlike with CPFP where only the winning bid =
pays fees. But for other cases, the difference would be negligible.</div><d=
iv><br></div><div>Of course, the most WU-optimal construct is APO|SINGLE (i=
mplying ACP) that you mentioned, where no extra transaction is needed at al=
l.</div><div><br></div><div>[0] Assuming you need to use N coins for fees a=
nd that change is needed, with an exact-sized fee utxo you have a N-in, 2-o=
ut tx to prepare the fee utxo, then a 2-in, 1-out for the main tx - for a t=
otal of N+2 inputs and 3 outputs. With CPFP, its 1-in, 2-out for the main t=
x, then a N+1-in, 1-out tx for the CPFP fee bump - also for a total of N+2 =
inputs and 3 outputs. However, with CPFP you could use Pay-to-Anchor (while=
 the fee utxo has to be key-encumbered), saving 65WU for one input plus 30v=
B/120WU for one output, making it more efficient by a total of 185WU/46vB (=
assuming the fee utxo uses key-path P2TR).</div><div><br></div><div>[1] If =
you happen to have an existing utxo to pay fees with, the 2-input CTV templ=
ate would be as efficient as it gets, on par with APO|SINGLE. This can be e=
xtended to combos of multiple utxos, by adding more CTV tapleaves for diffe=
rent numbers of inputs (at a slight cost of larger control blocks). With la=
rge wallets it could be plausible to find such combos.</div><div><br></div>=
Cheers,</div><div class=3D"gmail_quote gmail_quote_container">shesek</div><=
/div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAGXD5f3zHuwGq%2BM1jwBJjpEc3Wd8biwjwnrXu6VhrysQeyivLQ%40mail.gma=
il.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/=
msgid/bitcoindev/CAGXD5f3zHuwGq%2BM1jwBJjpEc3Wd8biwjwnrXu6VhrysQeyivLQ%40ma=
il.gmail.com</a>.<br />

--00000000000020f3310630224efe--