path: root/95/62903f988402a7b9fc6b432e24280f5ac82347

Return-Path: <eric@voskuil.org>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 23466C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  7 Jul 2022 19:58:03 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id DDD9E418D9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  7 Jul 2022 19:58:02 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org DDD9E418D9
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=voskuil-org.20210112.gappssmtp.com
 header.i=@voskuil-org.20210112.gappssmtp.com header.a=rsa-sha256
 header.s=20210112 header.b=AG2mh1oS
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001]
 autolearn=ham autolearn_force=no
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 p0Lf3F3wmdSg
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  7 Jul 2022 19:58:00 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org C388F418CC
Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com
 [IPv6:2607:f8b0:4864:20::534])
 by smtp4.osuosl.org (Postfix) with ESMTPS id C388F418CC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  7 Jul 2022 19:58:00 +0000 (UTC)
Received: by mail-pg1-x534.google.com with SMTP id bh13so14457495pgb.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 07 Jul 2022 12:58:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=voskuil-org.20210112.gappssmtp.com; s=20210112;
 h=content-transfer-encoding:from:mime-version:subject:date:message-id
 :references:cc:in-reply-to:to;
 bh=gX+fFUswloSEnq4rxfK4F4JCUj31JYAZEhs0yMeXFh4=;
 b=AG2mh1oSVT28kp4gElm2iO6LGuxRr908woLDMPL7f6l2K4F6uORZ7Q2Mp+Wt02Wi6E
 W180uAk+UqFHBSFXqrzOHfS7bgRMdGNiswyOMAI8PTSBi1AI2NWwdF7IjgEHXx6ThwJk
 KIFG/h4FCns/+rHqcjIbl4ZXIuh4numem/buWppF3TqOPHLT10DAag1Chmib8VK6muVH
 jbcHlj6EeGno0UitDywzcdVcaJHPCkNXB2G2nkAuQAEXAondIrc1dyKjcVinHsHivN64
 PjBXEsrx7F8JPDSqSQMe7WZg+OZs8OaDZI+2Pr3fZJDY0MNLlDLtdDaQUKBGnnb/fofn
 HDtw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:content-transfer-encoding:from:mime-version
 :subject:date:message-id:references:cc:in-reply-to:to;
 bh=gX+fFUswloSEnq4rxfK4F4JCUj31JYAZEhs0yMeXFh4=;
 b=0MW6CKUWR/6k28N3CMwInRN8goQT4YjK0wm31s4MVa0Y5h6MkafAwqsikN3NiON0EO
 NCvYbPySWKLgAVphubowHS+NSExMvm5eZV+a3urze8fkrZ8lbpg1Tq6rIJMeG3jigmzs
 zPS9OJA746DY6uTo2Q8Mp9D8pU576u/qjo8zbZhcGDEXEOrf5N3C6tUr5gqfDfCxY4Vm
 pGo7i1jUgUWwuDrRdwexlduiZz/hDD9Mmrxg/IcPJhTiiv1GmpJhLRjS4lbc6I5GyHZz
 V60BNu0OdUvdy5A6J27k+xsRL7ASx6AdNvxLbGXKWH3TNrDKROX1M729nDuIjLQrFVFY
 5Eyg==
X-Gm-Message-State: AJIora/7A4bnbi952p3xOVyQ3qgk5ewdSZaCgpyoLusQ//ZBSQPOXIHe
 95e1v1QkwyUxOzdTm4OZsk6CupGUst8VXQ==
X-Google-Smtp-Source: AGRyM1vcSNCzNEG5zznIxBnhwsJwUp3xtS+kUJa6Fs9ZlNhAtgZ5g/3TUae+8G/N5PvDxOgvpYg+0Q==
X-Received: by 2002:a17:902:d708:b0:16b:d655:e15a with SMTP id
 w8-20020a170902d70800b0016bd655e15amr29597237ply.34.1657223879631; 
 Thu, 07 Jul 2022 12:57:59 -0700 (PDT)
Received: from smtpclient.apple ([2600:380:801f:6202:f47e:c7ca:fad6:7d1])
 by smtp.gmail.com with ESMTPSA id
 l3-20020a17090a408300b001eab99a42efsm19781328pjg.31.2022.07.07.12.57.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 07 Jul 2022 12:57:58 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary=Apple-Mail-635FE9B0-6D7D-4035-98CB-4EB148897C34
Content-Transfer-Encoding: 7bit
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Thu, 7 Jul 2022 12:57:56 -0700
Message-Id: <8438F081-D085-4491-8C1C-4D83FFC7DE84@voskuil.org>
References: <CAJowKg+OP92w+zHjy4T79tMDL5O0gboUEurhBAuWbp+npsv94A@mail.gmail.com>
In-Reply-To: <CAJowKg+OP92w+zHjy4T79tMDL5O0gboUEurhBAuWbp+npsv94A@mail.gmail.com>
To: Erik Aronesty <erik@q32.com>
X-Mailer: iPhone Mail (19F77)
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 John Carvalho <john@synonym.to>
Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable
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: Thu, 07 Jul 2022 19:58:03 -0000


--Apple-Mail-635FE9B0-6D7D-4035-98CB-4EB148897C34
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

It=E2=80=99s not clear how reducing block size changes the fee aspect of the=
 block reward. Assuming half the space implies twice the fee per avg tx the r=
eward remains constant.

Any additional cost of processing more or less bytes would not matter, becau=
se of course this is just a cost that gets nulled out by difficulty =E2=80=94=
 average profit (net income) is the cost of capital.

The reason for smaller vs. larger blocks is to ensure that individuals can a=
fford to validate. That=E2=80=99s a threshold criteria.

Given unlimited size blocks, miners would still have to fix a point in time t=
o mine, gathering as much fee as they can optimize in some time period presu=
mably less than 10 minutes. The produces a limit to transaction volume, yet n=
either reward nor profit would be affected given the above assumptions. The d=
ifference would be in a tradeoff of per tx fee against the threshold.

Given Moore=E2=80=99s Law, that threshold is constantly decreasing, which wi=
ll make it  cheaper over time for more individuals to validate. But the diff=
erence for miners for smaller blocks is largely inconsequential relative to t=
heir other costs.

Increasing demand is the only thing that increases double spend security (an=
d censorship resistance assuming fee-based reward). With rising demand there=
 is rising overall hash rate, despite block reward and profit remaining cons=
tant. This makes the cost of attempting to orphan a block higher, therefore l=
owering the depth/time requirement implied to secure a given tx amount.

These are the two factors, demand and time. Less demand implies more time to=
 secure a given amount against double spend, and also implies a lower cost t=
o subsidize a censorship regime. But the latter requires a differential in r=
eward between the censor and non-censoring miners. While this could be paid i=
n side fees, that is a significant anonymity issue.

e

> On Jul 7, 2022, at 10:37, Erik Aronesty <erik@q32.com> wrote:
>=20
> =EF=BB=BF
> > > We should not imbue real technology with magical qualities.
>=20
> > Precisely. It is economic forces (people), not technology, that provide s=
ecurity.
>=20
> Yes, and these forces don't prevent double-spend / 51% attacks if the amou=
nts involved are greater than the incentives.
>=20
> In addition to "utility", lowering the block size could help prevent this i=
ssue as well... increasing fee pressure and double-spend security while redu=
cing the burden on node operators.
>=20
> Changes to inflation are, very likely, off the table.
>=20
> =20
>=20
>> On Thu, Jul 7, 2022 at 12:24 PM Eric Voskuil via bitcoin-dev <bitcoin-dev=
@lists.linuxfoundation.org> wrote:
>>=20
>>=20
>> > On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev <bitcoin-dev@lists=
.linuxfoundation.org> wrote:
>> >=20
>> > =EF=BB=BFOn Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via bi=
tcoin-dev wrote:
>> >> Billy,
>> >>=20
>> >> Proof of work and the difficulty adjustment function solve literally
>> >> everything you are talking about already.
>> >=20
>> > Unfortunately you are quite wrong: the difficulty adjustment function m=
erely
>> > adjusts for changes in the amount of observable, non-51%-attacking, has=
hing
>> > power. In the event of a chain split, the difficulty adjustment functio=
n does
>> > nothing; against a 51% attacker, the difficulty adjustment does nothing=
;
>> > against a censor, the difficulty adjustment does nothing.
>>=20
>> Consider falling hash rate due to a perpetual 51% attack. Difficulty fall=
s, possibly to min difficulty if all non-censors stop mining and with all ce=
nsors collaborating (one miner). Yet as difficulty falls, so does the cost o=
f countering the censor. At min difficulty everyone can CPU mine again.
>>=20
>> Given the presumption that fees rise on unconfirmed transactions, there i=
s inherent economic incentive to countering at any level of difficulty. Cons=
equently the censor is compelled to subsidize the loss resulting from forgoi=
ng higher fee transactions that are incentivizing its competition.
>>=20
>> With falling difficulty this incentive is compounded.
>>=20
>> Comparisons of security in different scenarios presume a consistent level=
 of demand. If that demand is insufficient to offset the censor=E2=80=99s su=
bsidy, there is no security in any scenario.
>>=20
>> Given that the block subsidy (inflation) is paid equally to censoring and=
 non-censoring miners, it offers no security against censorship whatsoever. T=
rading fee-based block reward for inflation-based is simply trading censorsh=
ip resistance for the presumption of double-spend security. But of course, a=
 censor can double spend profitably in any scenario where the double spend v=
alue (to the censor) exceeds that of blocks orphaned (as the censor earns 10=
0% of all block rewards).
>>=20
>> Banks and state monies offer reasonable double spend security. Not sure t=
hat=E2=80=99s a trade worth making.
>>=20
>> It=E2=80=99s not clear to me that Satoshi understood this relation. I=E2=80=
=99ve seen no indication of it. However the decision to phase out subsidy, o=
nce a sufficient number of units (to assure divisibility) had been issued, i=
s what transitions Bitcoin from a censorable to a censorship resistant money=
. If one does not believe there is sufficient demand for such a money, there=
 is no way to reconcile that belief with a model of censorship resistance.
>>=20
>> > We should not imbue real technology with magical qualities.
>>=20
>> Precisely. It is economic forces (people), not technology, that provide s=
ecurity.
>>=20
>> e
>>=20
>> >> Bitcoin does not need active economic governanance by devs or meddlers=
.
>> >=20
>> > Yes, active governance would definitely be an exploitable mechanism. On=
 the
>> > other hand, the status quo of the block reward eventually going away en=
tirely
>> > is obviously a risky state change too.
>> >=20
>> >>>> There is also zero agreement on how much security would constitute s=
uch
>> >>> an optimum.
>> >>>=20
>> >>> This is really step 1. We need to generate consensus on this long bef=
ore
>> >>> the block subsidy becomes too small. Probably in the next 10-15 years=
. I
>> >>> wrote a paper
>> >=20
>> > The fact of the matter is that the present amount of security is about 1=
.7% of
>> > the total coin supply/year, and Bitcoin seems to be working fine. 1.7% i=
s also
>> > already an amount low enough that it's much smaller than economic volat=
ility.
>> >=20
>> > Obviously 0% is too small.
>> >=20
>> > There's zero reason to stress about finding an "optimal" amount. An amo=
unt low
>> > enough to be easily affordable, but non-zero, is fine. 1% would be fine=
; 0.5%
>> > would probably be fine; 0.1% would probably be fine.
>> >=20
>> > Over a lifetime - 75 years - 0.5% yearly inflation works out to be a 31=
% tax on
>> > savings; 0.1% works out to be 7.2%
>> >=20
>> > These are all amounts that are likely to be dwarfed by economic shifts.=

>> >=20
>> > --=20
>> > https://petertodd.org 'peter'[:-1]@petertodd.org
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev@lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--Apple-Mail-635FE9B0-6D7D-4035-98CB-4EB148897C34
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr"></div><div dir=3D"ltr">It=E2=
=80=99s not clear how reducing block size changes the fee aspect of the bloc=
k reward. Assuming&nbsp;<span style=3D"caret-color: rgb(0, 0, 0); color: rgb=
(0, 0, 0);">half the space implies twice the fee per avg tx the reward remai=
ns constant.</span></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">Any add=
itional cost of processing more or less bytes would not matter, because of c=
ourse this is just a cost that gets nulled out by difficulty =E2=80=94 avera=
ge profit (net income) is the cost of capital.</div><div dir=3D"ltr"><br></d=
iv><div dir=3D"ltr">The reason for smaller vs. larger blocks is to ensure th=
at individuals can afford to validate. That=E2=80=99s a threshold criteria.<=
/div><div dir=3D"ltr"><br></div><div dir=3D"ltr">Given unlimited size blocks=
, miners would still have to fix a point in time to mine, gathering as much f=
ee as they can optimize in some time period presumably less than 10 minutes.=
 The produces a limit to transaction volume, yet neither reward nor profit w=
ould be affected given the above assumptions. The difference would be in a t=
radeoff of per tx fee against the threshold.</div><div dir=3D"ltr"><br></div=
><div dir=3D"ltr">Given Moore=E2=80=99s Law, that threshold is constantly de=
creasing, which will make it &nbsp;cheaper over time for more individuals to=
 validate. But the difference for miners for smaller blocks is largely incon=
sequential relative to their other costs.</div><div dir=3D"ltr"><br></div><d=
iv dir=3D"ltr">Increasing demand is the only thing that increases double spe=
nd security (and censorship resistance assuming fee-based reward). With risi=
ng demand there is rising overall hash rate, despite block reward and profit=
 remaining constant. This makes the cost of attempting to orphan a block hig=
her, therefore lowering the depth/time requirement implied to secure a given=
 tx amount.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">These are the t=
wo factors, demand and time. Less demand implies more time to secure a given=
 amount against double spend, and also implies a lower cost to subsidize a c=
ensorship regime. But the latter requires a differential in reward between t=
he censor and non-censoring miners. While this could be paid in side fees, t=
hat is a significant anonymity issue.</div><div dir=3D"ltr"><br></div><div d=
ir=3D"ltr">e</div><div dir=3D"ltr"><br><blockquote type=3D"cite">On Jul 7, 2=
022, at 10:37, Erik Aronesty &lt;erik@q32.com&gt; wrote:<br><br></blockquote=
></div><blockquote type=3D"cite"><div dir=3D"ltr">=EF=BB=BF<div dir=3D"ltr">=
<div><span style=3D"color:rgb(80,0,80)">&gt; &gt; We should not imbue real t=
echnology with magical qualities.</span><br></div><div><span class=3D"gmail-=
im" style=3D"color:rgb(80,0,80)"><br></span>&gt; Precisely. It is economic f=
orces (people), not technology, that provide security.<font color=3D"#888888=
"><br></font></div><div><br></div><div>Yes, and these forces don't prevent d=
ouble-spend / 51% attacks if the amounts involved are greater than the incen=
tives.</div><div><br></div><div>In addition to "utility", lowering the block=
 size could help prevent this issue as well... increasing fee pressure and d=
ouble-spend security while reducing the burden on node operators.</div><div>=
<br></div><div>Changes to inflation are, very likely, off the table.</div><d=
iv><br></div><div>&nbsp;</div></div><br><div class=3D"gmail_quote"><div dir=3D=
"ltr" class=3D"gmail_attr">On Thu, Jul 7, 2022 at 12:24 PM Eric Voskuil via b=
itcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitc=
oin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex"><br>
<br>
&gt; On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev &lt;<a href=3D"mai=
lto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lis=
ts.linuxfoundation.org</a>&gt; wrote:<br>
&gt; <br>
&gt; =EF=BB=BFOn Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via bi=
tcoin-dev wrote:<br>
&gt;&gt; Billy,<br>
&gt;&gt; <br>
&gt;&gt; Proof of work and the difficulty adjustment function solve literall=
y<br>
&gt;&gt; everything you are talking about already.<br>
&gt; <br>
&gt; Unfortunately you are quite wrong: the difficulty adjustment function m=
erely<br>
&gt; adjusts for changes in the amount of observable, non-51%-attacking, has=
hing<br>
&gt; power. In the event of a chain split, the difficulty adjustment functio=
n does<br>
&gt; nothing; against a 51% attacker, the difficulty adjustment does nothing=
;<br>
&gt; against a censor, the difficulty adjustment does nothing.<br>
<br>
Consider falling hash rate due to a perpetual 51% attack. Difficulty falls, p=
ossibly to min difficulty if all non-censors stop mining and with all censor=
s collaborating (one miner). Yet as difficulty falls, so does the cost of co=
untering the censor. At min difficulty everyone can CPU mine again.<br>
<br>
Given the presumption that fees rise on unconfirmed transactions, there is i=
nherent economic incentive to countering at any level of difficulty. Consequ=
ently the censor is compelled to subsidize the loss resulting from forgoing h=
igher fee transactions that are incentivizing its competition.<br>
<br>
With falling difficulty this incentive is compounded.<br>
<br>
Comparisons of security in different scenarios presume a consistent level of=
 demand. If that demand is insufficient to offset the censor=E2=80=99s subsi=
dy, there is no security in any scenario.<br>
<br>
Given that the block subsidy (inflation) is paid equally to censoring and no=
n-censoring miners, it offers no security against censorship whatsoever. Tra=
ding fee-based block reward for inflation-based is simply trading censorship=
 resistance for the presumption of double-spend security. But of course, a c=
ensor can double spend profitably in any scenario where the double spend val=
ue (to the censor) exceeds that of blocks orphaned (as the censor earns 100%=
 of all block rewards).<br>
<br>
Banks and state monies offer reasonable double spend security. Not sure that=
=E2=80=99s a trade worth making.<br>
<br>
It=E2=80=99s not clear to me that Satoshi understood this relation. I=E2=80=99=
ve seen no indication of it. However the decision to phase out subsidy, once=
 a sufficient number of units (to assure divisibility) had been issued, is w=
hat transitions Bitcoin from a censorable to a censorship resistant money. I=
f one does not believe there is sufficient demand for such a money, there is=
 no way to reconcile that belief with a model of censorship resistance.<br>
<br>
&gt; We should not imbue real technology with magical qualities.<br>
<br>
Precisely. It is economic forces (people), not technology, that provide secu=
rity.<br>
<br>
e<br>
<br>
&gt;&gt; Bitcoin does not need active economic governanance by devs or meddl=
ers.<br>
&gt; <br>
&gt; Yes, active governance would definitely be an exploitable mechanism. On=
 the<br>
&gt; other hand, the status quo of the block reward eventually going away en=
tirely<br>
&gt; is obviously a risky state change too.<br>
&gt; <br>
&gt;&gt;&gt;&gt; There is also zero agreement on how much security would con=
stitute such<br>
&gt;&gt;&gt; an optimum.<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; This is really step 1. We need to generate consensus on this lo=
ng before<br>
&gt;&gt;&gt; the block subsidy becomes too small. Probably in the next 10-15=
 years. I<br>
&gt;&gt;&gt; wrote a paper<br>
&gt; <br>
&gt; The fact of the matter is that the present amount of security is about 1=
.7% of<br>
&gt; the total coin supply/year, and Bitcoin seems to be working fine. 1.7% i=
s also<br>
&gt; already an amount low enough that it's much smaller than economic volat=
ility.<br>
&gt; <br>
&gt; Obviously 0% is too small.<br>
&gt; <br>
&gt; There's zero reason to stress about finding an "optimal" amount. An amo=
unt low<br>
&gt; enough to be easily affordable, but non-zero, is fine. 1% would be fine=
; 0.5%<br>
&gt; would probably be fine; 0.1% would probably be fine.<br>
&gt; <br>
&gt; Over a lifetime - 75 years - 0.5% yearly inflation works out to be a 31=
% tax on<br>
&gt; savings; 0.1% works out to be 7.2%<br>
&gt; <br>
&gt; These are all amounts that are likely to be dwarfed by economic shifts.=
<br>
&gt; <br>
&gt; -- <br>
&gt; <a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">=
https://petertodd.org</a> 'peter'[:-1]@<a href=3D"http://petertodd.org" rel=3D=
"noreferrer" target=3D"_blank">petertodd.org</a><br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-d=
ev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/m=
ailman/listinfo/bitcoin-dev</a><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">b=
itcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" r=
el=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mailma=
n/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</div></blockquote></body></html>=

--Apple-Mail-635FE9B0-6D7D-4035-98CB-4EB148897C34--