path: root/ae/b9452cd9bab54484a23ce8b865b33013d39abd

Return-Path: <fresheneesz@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 6D6A0C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 Jan 2022 15:27:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 4E3FB41768
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 Jan 2022 15:27:46 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.698
X-Spam-Level: 
X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5
 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id BJ2RfxG3-xkV
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 Jan 2022 15:27:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [IPv6:2a00:1450:4864:20::529])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 9D56F416FC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 Jan 2022 15:27:44 +0000 (UTC)
Received: by mail-ed1-x529.google.com with SMTP id m11so10481799edi.13
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 Jan 2022 07:27:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=xiV37NQ7WdUOCzdc3Z4DsgWBF49QQS7t05yvSnUMV6s=;
 b=XjzfFNk/k1RxJC0nHsGD5LGiI+EUXzoj4jCQJzg8ndaR5fQzvYyFEY13a8jRhiEAgf
 UtVJt9ynuf7NDuMb50B0Um3dd08UxBLlFhHYrhyMZM4ZffvMdjujDyjb1zM79w6za5th
 kO9h8LfU0YFnBWSdsGPSQAn1xW6cFH93XO0TeUMeWDyGAeIyiSliKhD1nxjittwsPcpM
 HCbg1QJG0TxuJKCP19eVLcjMlhGaEoSyc2sreksiN8EeT2zVk3X0+jEiU2YFR8FTGGAk
 44w9cbajhn1D6pYQ2BByDr8+h6utUHCBOJoRuXOAlCmnJalItQ/uf2pO3x6BVBhjxFes
 X3xg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=xiV37NQ7WdUOCzdc3Z4DsgWBF49QQS7t05yvSnUMV6s=;
 b=10cYH4hZlVuJJucppsJ9le0/swi09u2QHwyaEuEvr4lMLA0+38QZZmSWiIh619bfmb
 s0Fq8OH1vEXJr/Lm0tCBrU8YjxZYAZAdPxhWnGmRiJ3IFsiMJYrlZ3/42a76dIJXtoGo
 CsOA2wSwwqR7RQszPtQI41UZbVqKvKOpZ5HdfabtDgvkjslE/+5nTI0Dj9cHMKgMo3w9
 z4E5OjnIubTe+VOleJvLFEv4YL2TsVNWKQ1OuyY2GbXrIN68/utgnGz22ipCx3fHovGc
 GpSW1X8VWrNcHs3IpZ1diZBhxNfdSWqfoUO46T79xIv17u205kHPWltp+mlcHT7d6Myu
 lKUg==
X-Gm-Message-State: AOAM530OM8OObzH5QYgE0vZa7vxZLu4l36zateBPWOTBT9JmUvys4UH+
 bZcL+E8z35ybf1aSCn4+OpstVCw/rTAZ3u5Zd12Nx9UV
X-Google-Smtp-Source: ABdhPJyw6+i2dP+mid/yUExV4nhAez8ZxU6EcXrxXwIvNoih9TADkEOHm0qBXsVErrdfv7lGw+PZCMlnnmNAkpWHKBo=
X-Received: by 2002:a05:6402:37a:: with SMTP id
 s26mr8634871edw.400.1643383662550; 
 Fri, 28 Jan 2022 07:27:42 -0800 (PST)
MIME-Version: 1.0
References: <jMANAdspMdPb1ZCFttQ3tGmkZ0oYojLY5Oz1d8ZSNl3JhZeDuT1xK0vxTu8uyHcgPXWsM_6XNb3R9tVD3_Yez88pviFrCaNt7LPqdWVBWus=@protonmail.com>
 <CAGpPWDY3vZ2JOsa1UhoT-z8kfxqkVWcq1nyt9Ah5ye6HE_6gOQ@mail.gmail.com>
 <By1G6iST5DCXZJVfEd3HzdPgU3e_NGoqvH-5UoqsOzY8qjiOmy5iHXiOwjXtm7Znq1Z6z-XOL0IPDSyQiLOZ6-lRQ-vi1I6Cba4aqywe8xw=@protonmail.com>
In-Reply-To: <By1G6iST5DCXZJVfEd3HzdPgU3e_NGoqvH-5UoqsOzY8qjiOmy5iHXiOwjXtm7Znq1Z6z-XOL0IPDSyQiLOZ6-lRQ-vi1I6Cba4aqywe8xw=@protonmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Fri, 28 Jan 2022 09:27:30 -0600
Message-ID: <CAGpPWDa=YBMrkuUHD0ogS3uxWq0g4LZubm=g9yQVuEffudsJhA@mail.gmail.com>
To: AdamISZ <AdamISZ@protonmail.com>
Content-Type: multipart/alternative; boundary="0000000000006fa14b05d6a613fe"
X-Mailman-Approved-At: Fri, 28 Jan 2022 15:40:30 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] PathCoin
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Jan 2022 15:27:46 -0000

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

> what is the incentive for the honest party to punish?

Justice. Also, there's no incentive for the honest party to not punish -
presumably their software would automatically punish, and why go through
any effort to stop it? A 1 cent bribe certainly wouldn't be enough. Maybe a
$10 bribe might get someone somewhere to install hacked up software to be
able to fulfill such a bribe, but even then i think it would be a rare
person that would stoop to that. Were it to become a true negotiation, the
cheater has more to lose, and therefore the bribee has a lot of leverage.

> my strong intuition is that it will never be properly stable.

I'm curious what you mean by "stable". You had mentioned the game theory is
"fragile" and I'm wondering if there's more to this than just "what
incentive does the honest party have to burn?"

To be clear, I'm not advocating for Sabu and I haven't done any deep
thinking about burn based incentives.

One thing I thought of regarding path coin, if there's ever a situation
where there are multiple choices in path, whatever punishment there is
probably needs to be able to handle the multiple of the number of paths.
The only way around this i can imagine is to have some method of
coordination between payees, eg a place where a payee records their payment
such that a payee who has been double spent on to become aware they've been
double spent on and initiate the punishment. But once you have that
coordination mechanism it starts not looking more like an on chain
transaction.

On Tue, Jan 25, 2022, 06:50 AdamISZ <AdamISZ@protonmail.com> wrote:

> Hi Billy,
> I read through the description. I think systems like this *mostly* fail
> due to game theory.
>
> With punishment-by-burn you have various issues that make it to my mind
> pretty unstable, too unstable to use for any serious system. To be fair,
> this isn't cut-and-dried. So let me unpack:
>
> (I briefly touched on why I dismissed penalties via burn in my gist,
> section: "Not feeling the burn".)
>
> There is a distinction between penalty via burn to unspendable output and
> penalty via burn to miner fees. The latter has an obvious problem: if you=
r
> counterparties collude with (or are) miners, they may not actually be
> penalized at all (now to be clear, that is a problematic attack ex nihilo=
:
> nobody usually can be sure who's mining the next block, but markets have =
a
> way of solving and coordinating such things: see e.g. the various MEV
> discussions and initiatives in Ethereum for an example of that).
>
> But the former (provable burn) is still imo extremely unstable: if the
> penalty tx destroys all the money, what is the incentive for the honest
> party to punish? In such a scenario even a one cent donation from the
> attacker to the victim might prevent the penalty from happening.
> You can combine 'destruction of most, or some, of the funds' with a
> smaller payout to the aggrieved party, but then again you have to factor =
in
> the possibility of bribes. The Sabu post you linked describes it as: "The=
re
> are precise and delicate formulas for calculating the amount of loss of t=
he
> issuer and the creditor, which ensures that just and true act in both
> parties are cost-effective in all situations." I agree it's delicate, but
> after having spent time looking into these things, my strong intuition is
> that it will never be properly stable.
>
> In the PathCoin description I am specifically looking for a trustless
> system, with this finesse: we still count it as trustless even though we
> are using penalties as disincentive, because the penalty *consists of a
> payment directly from the attacker to the attacked, and that payment is
> larger than the amount stolen*. I claim that that *is* stable.
>
> Notice that Lightning has the same model (in LN-Penalty), as long as
> 'claiming the whole channel capacity' is enough to be larger than what is
> stolen (see: channel reserves etc.).
>
> Sent with ProtonMail <https://protonmail.com/> Secure Email.
>
>
> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original =
Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
> On Tuesday, January 25th, 2022 at 11:53, Billy Tetrud via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> There was a protocol someone mentioned a while back called Sabu that had
> the same goals. As i recall, it had some pretty promising constructs, but
> would have a critical vulnerability that could be exploited by miners. Th=
is
> is the write up:
>
>
> https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-=
transactions-per-second-and-privacy-1eef8568d180
>
> Perhaps some of the techniques there could be combined with your ideas to
> get closer to a solution.
>
> On Mon, Jan 24, 2022, 08:51 AdamISZ via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hello list,
>>
>> I took the time to write up this rather out-there idea:
>>
>> Imagine you wanted to send a coin just like email, i.e. just transfer
>> data to the counterparty.
>>
>> Clearly this is in general entirely impossible; but with what
>> restrictions and assumptions could you create a toy version of it?
>>
>> See this gist for a detailed build up of the idea:
>>
>> https://gist.github.com/AdamISZ/b462838cbc8cc06aae0c15610502e4da
>>
>> Basically: using signature adaptors and CTV or a similar covenant, you
>> could create a fully trustless transfer of control of a utxo from one pa=
rty
>> to another with no interaction with the rest of the group, at the time o=
f
>> transfer (modulo of course lots and lots of one-time setup).
>>
>> The limitations are extreme and as you'd imagine. In the gist I feel lik=
e
>> I got round one of them, but not the others.
>>
>> (I very briefly mention comparison to e.g. statechains or payment pools;
>> they are making other tradeoffs against the 'digital cash' type of goal.
>> There is no claim that this 'pathcoin' idea is even viable yet, let alon=
e
>> better than those ideas).
>>
>> Publishing this because I feel like it's the kind of thing imaginative
>> minds like the ones here, may be able to develop further. Possibly!
>>
>>
>> waxwing / AdamISZ
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>

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

<div dir=3D"auto">&gt;=C2=A0<span style=3D"font-family:arial;font-size:14px=
">what is the incentive for the honest party to punish?=C2=A0</span><div di=
r=3D"auto"><span style=3D"font-family:arial;font-size:14px"><br></span></di=
v><div dir=3D"auto"><font face=3D"arial"><span style=3D"font-size:14px">Jus=
tice. Also, there&#39;s no incentive for the honest party to not punish - p=
resumably their software would automatically punish, and why go through any=
 effort to stop it? A 1 cent bribe certainly wouldn&#39;t be enough. Maybe =
a $10 bribe might get someone somewhere to install hacked up software to be=
 able to fulfill such a bribe, but even then i think it would be a rare per=
son that would stoop to that. Were it to become a true negotiation, the che=
ater has more to lose, and therefore the bribee has a lot of leverage.=C2=
=A0</span></font></div><div dir=3D"auto"><font face=3D"arial"><span style=
=3D"font-size:14px"><br></span></font></div><div dir=3D"auto"><font face=3D=
"arial"><span style=3D"font-size:14px">&gt; my strong intuition is that it =
will never be properly stable.</span></font></div><div dir=3D"auto"><font f=
ace=3D"arial"><span style=3D"font-size:14px"><br></span></font></div><div d=
ir=3D"auto"><font face=3D"arial"><span style=3D"font-size:14px">I&#39;m cur=
ious what you mean by &quot;stable&quot;. You had mentioned the game theory=
 is &quot;fragile&quot; and I&#39;m wondering if there&#39;s more to this t=
han just &quot;what incentive does the honest party have to burn?&quot;</sp=
an></font></div><div dir=3D"auto"><font face=3D"arial"><span style=3D"font-=
size:14px"><br></span></font></div><div dir=3D"auto"><font face=3D"arial"><=
span style=3D"font-size:14px">To be clear, I&#39;m not advocating for Sabu =
and I haven&#39;t done any deep thinking about burn based incentives.=C2=A0=
</span></font></div><div dir=3D"auto"><font face=3D"arial"><span style=3D"f=
ont-size:14px"><br></span></font></div><div dir=3D"auto"><font face=3D"aria=
l"><span style=3D"font-size:14px">One thing I thought of regarding path coi=
n, if there&#39;s ever a situation where there are multiple choices in path=
, whatever punishment there is probably needs to be able to handle the mult=
iple of the number of paths. The only way around this i can imagine is to h=
ave some method of coordination between payees, eg a place where a payee re=
cords their payment such that a payee who has been double spent on to becom=
e aware they&#39;ve been double spent on and initiate the punishment. But o=
nce you have that coordination mechanism it starts not looking more like an=
 on chain transaction.</span></font></div></div><br><div class=3D"gmail_quo=
te"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jan 25, 2022, 06:50 AdamI=
SZ &lt;<a href=3D"mailto:AdamISZ@protonmail.com">AdamISZ@protonmail.com</a>=
&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"font-fami=
ly:arial;font-size:14px"><div style=3D"font-family:arial;font-size:14px">Hi=
 Billy,<br></div><div style=3D"font-family:arial;font-size:14px">I read thr=
ough the description. I think systems like this *mostly* fail due to game t=
heory.<br></div><div style=3D"font-family:arial;font-size:14px"><br></div><=
div style=3D"font-family:arial;font-size:14px">With punishment-by-burn you =
have various issues that make it to my mind pretty unstable, too unstable t=
o use for any serious system. To be fair, this isn&#39;t cut-and-dried. So =
let me unpack:<br></div><div style=3D"font-family:arial;font-size:14px"><br=
></div><div style=3D"font-family:arial;font-size:14px">(I briefly touched o=
n why I dismissed penalties via burn in my gist, section: &quot;Not feeling=
 the burn&quot;.)<br></div><div style=3D"font-family:arial;font-size:14px">=
<br></div><div style=3D"font-family:arial;font-size:14px">There is a distin=
ction between penalty via burn to unspendable output and penalty via burn t=
o miner fees. The latter has an obvious problem: if your counterparties col=
lude with (or are) miners, they may not actually be penalized at all (now t=
o be clear, that is a problematic attack ex nihilo: nobody usually can be s=
ure who&#39;s mining the next block, but markets have a way of solving and =
coordinating such things: see e.g. the various MEV discussions and initiati=
ves in Ethereum for an example of that).<br></div><div style=3D"font-family=
:arial;font-size:14px"><br></div><div style=3D"font-family:arial;font-size:=
14px">But the former (provable burn) is still imo extremely unstable: if th=
e penalty tx destroys all the money, what is the incentive for the honest p=
arty to punish? In such a scenario even a one cent donation from the attack=
er to the victim might prevent the penalty from happening.<br></div><div st=
yle=3D"font-family:arial;font-size:14px">You can combine &#39;destruction o=
f most, or some, of the funds&#39; with a smaller payout to the aggrieved p=
arty, but then again you have to factor in the possibility of bribes. The S=
abu post you linked describes it as: &quot;There are precise and delicate f=
ormulas for calculating the amount of
loss of the issuer and the creditor, which ensures that just and true
act in both parties are cost-effective in all situations.&quot; I agree it&=
#39;s delicate, but after having spent time looking into these things, my s=
trong intuition is that it will never be properly stable.<br></div><div sty=
le=3D"font-family:arial;font-size:14px"><br></div><div style=3D"font-family=
:arial;font-size:14px">In the PathCoin description I am specifically lookin=
g for a trustless system, with this finesse: we still count it as trustless=
 even though we are using penalties as disincentive, because the penalty *c=
onsists of a payment directly from the attacker to the attacked, and that p=
ayment is larger than the amount stolen*. I claim that that *is* stable.<br=
></div><div style=3D"font-family:arial;font-size:14px"><br></div><div style=
=3D"font-family:arial;font-size:14px">Notice that Lightning has the same mo=
del (in LN-Penalty), as long as &#39;claiming the whole channel capacity&#3=
9; is enough to be larger than what is stolen (see: channel reserves etc.).=
<br></div><div style=3D"font-family:arial;font-size:14px"><br></div><div st=
yle=3D"font-family:arial;font-size:14px"><div></div><div>Sent with <a href=
=3D"https://protonmail.com/" rel=3D"noopener noreferrer noreferrer" target=
=3D"_blank">ProtonMail</a> Secure Email.</div></div><div style=3D"font-fami=
ly:arial;font-size:14px"><br></div></div><div style=3D"font-family:arial;fo=
nt-size:14px"><br></div><div><div>=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=
=80=90=E2=80=90=E2=80=90 Original Message =E2=80=90=E2=80=90=E2=80=90=E2=80=
=90=E2=80=90=E2=80=90=E2=80=90<br></div><div> On Tuesday, January 25th, 202=
2 at 11:53, Billy Tetrud via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@=
lists.linuxfoundation.org" target=3D"_blank" rel=3D"noreferrer">bitcoin-dev=
@lists.linuxfoundation.org</a>&gt; wrote:<br></div><div> <br></div><blockqu=
ote type=3D"cite"><div dir=3D"auto"><div>There was a protocol someone menti=
oned a while back called Sabu that had the same goals. As i recall, it had =
some pretty promising constructs, but would have a critical vulnerability t=
hat could be exploited by miners. This is the write up:<br></div><div dir=
=3D"auto"><br></div><div dir=3D"auto"><a rel=3D"noopener noreferrer norefer=
rer" href=3D"https://raymo-49157.medium.com/time-to-boost-bitcoin-circulati=
on-million-transactions-per-second-and-privacy-1eef8568d180" target=3D"_bla=
nk">https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-millio=
n-transactions-per-second-and-privacy-1eef8568d180</a><br></div><div dir=3D=
"auto"><br></div><div dir=3D"auto">Perhaps some of the techniques there cou=
ld be combined with your ideas to get closer to a solution.<br></div></div>=
<div><br></div><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_a=
ttr">On Mon, Jan 24, 2022, 08:51 AdamISZ via bitcoin-dev &lt;<a rel=3D"noop=
ener noreferrer noreferrer" href=3D"mailto:bitcoin-dev@lists.linuxfoundatio=
n.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrot=
e:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div>Hello list,<br></div><div> =
<br></div><div> I took the time to write up this rather out-there idea:<br>=
</div><div> <br></div><div> Imagine you wanted to send a coin just like ema=
il, i.e. just transfer data to the counterparty.<br></div><div> <br></div><=
div> Clearly this is in general entirely impossible; but with what restrict=
ions and assumptions could you create a toy version of it?<br></div><div> <=
br></div><div> See this gist for a detailed build up of the idea:<br></div>=
<div> <br></div><div> <a href=3D"https://gist.github.com/AdamISZ/b462838cbc=
8cc06aae0c15610502e4da" rel=3D"noopener noreferrer noreferrer" target=3D"_b=
lank">https://gist.github.com/AdamISZ/b462838cbc8cc06aae0c15610502e4da</a><=
br></div><div> <br></div><div> Basically: using signature adaptors and CTV =
or a similar covenant, you could create a fully trustless transfer of contr=
ol of a utxo from one party to another with no interaction with the rest of=
 the group, at the time of transfer (modulo of course lots and lots of one-=
time setup).<br></div><div> <br></div><div> The limitations are extreme and=
 as you&#39;d imagine. In the gist I feel like I got round one of them, but=
 not the others.<br></div><div> <br></div><div> (I very briefly mention com=
parison to e.g. statechains or payment pools; they are making other tradeof=
fs against the &#39;digital cash&#39; type of goal. There is no claim that =
this &#39;pathcoin&#39; idea is even viable yet, let alone better than thos=
e ideas).<br></div><div> <br></div><div> Publishing this because I feel lik=
e it&#39;s the kind of thing imaginative minds like the ones here, may be a=
ble to develop further. Possibly!<br></div><div> <br></div><div> <br></div>=
<div> waxwing / AdamISZ<br></div><div> ____________________________________=
___________<br></div><div> bitcoin-dev mailing list<br></div><div> <a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noopener noreferre=
r noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><b=
r></div><div> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo=
/bitcoin-dev" rel=3D"noopener noreferrer noreferrer" target=3D"_blank">http=
s://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br></div></b=
lockquote></div></blockquote></div><div style=3D"font-family:arial;font-siz=
e:14px"><br></div></blockquote></div>

--0000000000006fa14b05d6a613fe--