path: root/63/32c68eeabe8e2c3982d1062c97d709834009b6

Return-Path: <gmaxwell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 3E147900
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Nov 2017 09:12:52 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f43.google.com (mail-vk0-f43.google.com
	[209.85.213.43])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E688BE4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Nov 2017 09:12:50 +0000 (UTC)
Received: by mail-vk0-f43.google.com with SMTP id u84so2968238vke.10
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Nov 2017 01:12:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:sender:in-reply-to:references:from:date:message-id
	:subject:to; bh=BniFJr0nhy2CKDoxbtL+aPG2c3sOsU6Ales1lTeGiLU=;
	b=SMc9Fn8upWyrctt2POhdMirgVaWn1KF2s1Jyc/161t5VlYRjSXNlqSZ53aAsNaNiLl
	1AAOuAHqodkIuMKPIF2QrIY6FDTieiQ7hpXfRAx5m/nx3R80K8v9iMgw75QnsB/S0yaX
	+1CwlslIycLZtt/Qx95lczqIT/TnmAGFi/sUBB+EXkxcKkw88rwYNxlcyxmBOz8vjbCn
	Ix/WBp7PMLv9Z2WYheaxEKk7mfqPRwB1lQPC7czOjQSTsk+i8Huay8YboQu+DQpnUu7W
	BQVds9ix7deeasdV/kf7pn8WniHuk8drtI1tMNd8mjbRp9o9yW24B0NVMwnk+TytfZUZ
	HW8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
	:date:message-id:subject:to;
	bh=BniFJr0nhy2CKDoxbtL+aPG2c3sOsU6Ales1lTeGiLU=;
	b=ricxCny3Lcs227QjO/ealrDQTdQztM6NLFnymJXgv2Aj4CbP+hJoHjkGDc3YdUSK37
	PCGu2dmRTcgpftAwQJ23zhY6BZdtxip4WOpb7j5AXZFV9h75ZW5rOdYSz2t94ryvrqjn
	xaNkvs2vA1STk577LsxfxUdetsJ9dAf2syZXoaMJl0TtUw5crNgL1WIzbfAxlq/7+B18
	OKf3VOruqlYxmn5mU1RRweQwchH158QmY2ZG0GpogZQIGAWtmTbAOQARVEkSl871v4Sr
	D+CQ6pcveAAkR5qKqeBPZxBepvfkLaQVKSBH/ek0jXk9+59AS+eZPKUif2GGqNykBxDB
	jVUA==
X-Gm-Message-State: AKGB3mK6iyMmnTpadl0RcF4cnhF+bdyGX79dXZc5+Z8jzd8YzHiaTNyY
	g4idUq9nj6UAB7GIxaCWbg1MnRau92yyASuWNHKNDQ==
X-Google-Smtp-Source: AGs4zMad2m+yN+qnLXbXafrNR2EhiHEGxHl+FF4IJ6ZQPBZyZe5yWaFjnKmGD5toKYXG1VVpE07XaIhfTeQY8pErv5k=
X-Received: by 10.31.165.150 with SMTP id o144mr1294078vke.124.1512033169121; 
	Thu, 30 Nov 2017 01:12:49 -0800 (PST)
MIME-Version: 1.0
Sender: gmaxwell@gmail.com
Received: by 10.103.85.148 with HTTP; Thu, 30 Nov 2017 01:12:48 -0800 (PST)
In-Reply-To: <CAAS2fgS5jiNCmdwEt3YtZMJ0SfhC8Hw1eXr_0Vo5AQhYv7bJfg@mail.gmail.com>
References: <CADpM8jr_RrbPXLx6Up8HMW-fv=noFLjy817dfsFdYTg216Pu7w@mail.gmail.com>
	<CAAS2fgS5jiNCmdwEt3YtZMJ0SfhC8Hw1eXr_0Vo5AQhYv7bJfg@mail.gmail.com>
From: Gregory Maxwell <greg@xiph.org>
Date: Thu, 30 Nov 2017 09:12:48 +0000
X-Google-Sender-Auth: GDJ1Q2aq0J2AHSwlWW1vdZ_wLfo
Message-ID: <CAAS2fgRtzjC6+ZZFPon_4nwjMoVjQkWQDQwMO4pfKhZqPfHZ9w@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a1142d310ef2707055f2fa791"
X-Spam-Status: No, score=-1.9 required=5.0 tests=AC_DIV_BONANZA,BAYES_00,
	DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] BIP Idea: Marginal Pricing
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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, 30 Nov 2017 09:12:52 -0000

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

This idea presumes that the protocol has any ability to regulate fees. I
believe the locally optimal strategy for both miners and payers alike is to
accept (pay) zero fees natively in the protocol and instead accept (pay)
their actual fees out-of-band or via OP_TRUE outputs which the miner can
simply collect.  Then the miner sets the fee threshold to ~0 and selects
transactions on the basis of out of band fees.

Miners today already accept out-of-band fees, and as far back as at least
2011 there were miners that would also accept fees in the form of
additional transaction outputs which they were able to spend.

On Thu, Nov 30, 2017 at 9:11 AM, Gregory Maxwell <gmaxwell@gmail.com> wrote=
:

>
>
> This idea presumes that the protocol has any ability to regulate fees. I
> believe the locally optimal strategy for both miners and payers alike is =
to
> accept (pay) zero fees natively in the protocol and instead accept (pay)
> their actual fees out-of-band or via OP_TRUE outputs which the miner can
> simply collect.  Then the miner sets the fee threshold to ~0 and selects
> transactions on the basis of out of band fees.
>
> Miners today already accept out-of-band fees, and as far back as at least
> 2011 there were miners that would also accept fees in the form of
> additional transaction outputs which they were able to spend.
>
>
>
> On Thu, Nov 30, 2017 at 12:47 AM, William Morriss via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Comrades,
>>
>> Long term, tx fees must support hash power by themselves. The following
>> is an economic approach to maximize total fee collection, and therefore
>> hashpower.
>>
>> *Goals*
>> Maximize total transaction fees
>> Reduce pending transaction time
>> Reduce individual transaction fees
>>
>> *Challenges*
>> Validators must agree on the maximum block size, else miners can cheat
>> and include extra transactions.
>> Allowing too many transactions per block will increase the cost of the
>> mining without collecting much income for the network.
>>
>>
>> *Problem*
>> In the transaction market, users are the demand curve, because they will
>> transact less when fees are higher, and prefer altcoins. The block size =
is
>> the supply curve, because it represents miners' willingness to accept
>> transactions.
>> Currently, the supply curve is inelastic:
>>
>> =E2=80=8BIncreasing the block size will not affect the inelasticity for =
any
>> fixed block size. The downsides of a fixed block size limit are well-kno=
wn:
>> - Unpredictable transaction settlement time
>> - Variable transaction fees depending on network congestion
>> - Frequent overpay
>>
>> *Proposal*
>> 1. Miners implicitly choose the market sat/byte rate with the
>> cheapest-fee transaction included in their block. Excess transaction fee=
s
>> are refunded to the inputs.
>> 2. Remove the block size limit, which is no longer necessary.
>>
>> *Benefits*
>> - Dynamic block size limit regulated by profit motive
>> - Transaction fees maximized for every block
>> - No overpay; all fees are fair
>>
>> =E2=80=8BMiners individually will make decisions to maximize their block=
-reward
>> profit.
>> Miners are incentivized to ignore low-fee transactions because they woul=
d
>> shave the profits of their other transactions and increase their hash ti=
me.
>> Users and services are free to bid higher transaction fees in order to
>> reach the next block, since their excess bid will be refunded.
>>
>> The block size limit was added as a spam-prevention measure, but in orde=
r
>> for an attacker to spam the network with low-fee transactions, they woul=
d
>> have to offset the marginal cost of reducing the price with their own
>> transaction fees. Anti-spam is thus built into the marginal system witho=
ut
>> the need for an explicit limit.
>>
>> Rarely, sections of the backlog would become large enough to be
>> profitable. This means every so many blocks, lower-fee transactions woul=
d
>> be included en masse after having been ignored long enough. Low-fee
>> transactions thus gain a liveness property not previously enjoyed: low-f=
ee
>> transactions will eventually confirm. Miners targeting these transaction=
s
>> would be at a noteworthy disadvantage because they would be hashing a
>> larger block. I predict that this scheme would result in two markets: a
>> backlog market and a real-time market. Users targeting the backlog marke=
t
>> would match the price of the largest backlog section in order to be
>> included in the next backlog block.
>>
>> *Examples*
>>
>> Scenario 1
>> Sat/byte Bytes Reward
>> 400 500000 200000000
>> 300 700000 210000000
>> 200 1000000 200000000
>> 100 1500000 150000000
>> 50 5000000 250000000
>> 20 10000000 200000000
>> A miner would create a 5MB block and receive 0.25 BTC
>>
>> Scenario 2
>> Sat/byte Bytes Reward
>> 400 600000 240000000
>> 300 700000 210000000
>> 200 1000000 200000000
>> 100 1800000 180000000
>> 50 4000000 200000000
>> 20 10000000 200000000
>> A miner would create a 600KB block and receive 0.24 BTC
>>
>> Thanks,
>> William Morriss
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>

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

<div dir=3D"ltr"><br>This idea presumes that the protocol has any ability
 to regulate fees. I believe the locally optimal strategy for both=20
miners and payers alike is to accept (pay) zero fees natively in the=20
protocol and instead accept (pay) their actual fees out-of-band or via=20
OP_TRUE outputs which the miner can simply collect.=C2=A0 Then the miner se=
ts
 the fee threshold to ~0 and selects transactions on the basis of out of
 band fees.<br><br>Miners today already accept out-of-band fees,=20
and as far back as at least 2011 there were miners that would also=20
accept fees in the form of additional transaction outputs which they=20
were able to spend.</div><div class=3D"gmail_extra"><br><div class=3D"gmail=
_quote">On Thu, Nov 30, 2017 at 9:11 AM, Gregory Maxwell <span dir=3D"ltr">=
&lt;<a href=3D"mailto:gmaxwell@gmail.com" target=3D"_blank">gmaxwell@gmail.=
com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div><div><br><br></div>This idea presumes that the protocol has any abil=
ity to regulate fees. I believe the locally optimal strategy for both miner=
s and payers alike is to accept (pay) zero fees natively in the protocol an=
d instead accept (pay) their actual fees out-of-band or via OP_TRUE outputs=
 which the miner can simply collect.=C2=A0 Then the miner sets the fee thre=
shold to ~0 and selects transactions on the basis of out of band fees.<br><=
br></div>Miners today already accept out-of-band fees, and as far back as a=
t least 2011 there were miners that would also accept fees in the form of a=
dditional transaction outputs which they were able to spend.<br><div><br><b=
r></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><di=
v><div class=3D"h5">On Thu, Nov 30, 2017 at 12:47 AM, William Morriss via b=
itcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxf=
oundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org=
</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><=
div class=3D"h5"><div dir=3D"ltr">Comrades,<br><div><br>Long term, tx fees =
must support hash power by themselves. The following is an economic approac=
h to maximize total fee collection, and therefore hashpower.<br><div class=
=3D"gmail_quote"><div dir=3D"ltr"><div><div><div><div><div><div><div><div><=
div><div><div><div><div><div><b><br></b></div><div><b>Goals</b><br></div>Ma=
ximize total transaction fees<br></div>Reduce pending transaction time<br><=
/div>Reduce individual transaction fees<br></div><div><br></div><div><b>Cha=
llenges</b></div><div>Validators must agree on the maximum block size, else=
 miners can cheat and include extra transactions.</div><div>Allowing too ma=
ny transactions per block will increase the cost of the mining without coll=
ecting much income for the network.</div><div><br></div><b>Problem<br></b><=
/div>In the transaction market, users are the demand curve, because they wi=
ll transact less when fees are higher, and prefer altcoins. The block size =
is the supply curve, because it represents miners&#39; willingness to accep=
t transactions.<br></div>Currently, the supply curve is inelastic:<br></div=
><div><img width=3D"458" height=3D"458"><br>=E2=80=8B<img style=3D"margin-r=
ight:0px" width=3D"0" height=3D"0">Increasing the block size will not affec=
t the inelasticity for any fixed block size. The downsides of a fixed block=
 size limit are well-known:<br></div></div></div>- Unpredictable transactio=
n settlement time<br></div>- Variable transaction fees depending on network=
 congestion<br></div>- Frequent overpay</div><div><br></div><div><b>Proposa=
l</b></div><div>1. Miners implicitly choose the market sat/byte rate with t=
he cheapest-fee transaction included in their block. Excess transaction fee=
s are refunded to the inputs.</div><div>2. Remove the block size limit, whi=
ch is no longer necessary.<br></div><div><br></div><div><div><b>Benefits</b=
></div><div>- Dynamic block size limit regulated by profit motive</div><div=
>- Transaction fees maximized for every block<br></div><div>- No overpay; a=
ll fees are fair</div><div><img width=3D"458" height=3D"458"><br>=E2=80=8BM=
iners individually will make decisions to maximize their block-reward profi=
t.<br></div></div><div>Miners are incentivized to ignore low-fee transactio=
ns because they would shave the profits of their other transactions and inc=
rease their hash time.</div><div>Users and services are free to bid higher =
transaction fees in order to reach the next block, since their excess bid w=
ill be refunded.</div><div><br></div><div>The block size limit was added as=
 a spam-prevention measure, but in order for an attacker to spam the networ=
k with low-fee transactions, they would have to offset the marginal cost of=
 reducing the price with their own transaction fees. Anti-spam is thus buil=
t into the marginal system without the need for an explicit limit.<br></div=
><div><br></div><div>Rarely, sections of the backlog would become large eno=
ugh to be profitable. This means every so many blocks, lower-fee transactio=
ns would be included en masse after having been ignored long enough. Low-fe=
e transactions thus gain a liveness property not previously enjoyed: low-fe=
e transactions will eventually confirm. Miners targeting these transactions=
 would be at a noteworthy disadvantage because they would be hashing a larg=
er block. I predict that this scheme would result in two markets: a backlog=
 market and a real-time market. Users targeting the backlog market would ma=
tch the price of the largest backlog section in order to be included in the=
 next backlog block.<br></div><div><br></div><div><b>Examples</b></div><div=
><b><br></b></div><div>Scenario 1<br></div><div><b></b><table dir=3D"ltr" s=
tyle=3D"table-layout:fixed;font-size:10pt;font-family:arial,sans,sans-serif=
;width:0px;border-collapse:collapse;border-color:currentcolor;border-style:=
none;border-width:medium" border=3D"1" cellspacing=3D"0" cellpadding=3D"0">=
<colgroup><col width=3D"100"><col width=3D"100"><col width=3D"100"></colgro=
up><tbody><tr style=3D"height:21px"><td style=3D"overflow:hidden;padding:2p=
x 3px;vertical-align:bottom">Sat/byte</td><td style=3D"overflow:hidden;padd=
ing:2px 3px;vertical-align:bottom">Bytes</td><td style=3D"overflow:hidden;p=
adding:2px 3px;vertical-align:bottom">Reward</td></tr><tr style=3D"height:2=
1px"><td style=3D"overflow:hidden;padding:2px 3px;vertical-align:bottom;tex=
t-align:right">400</td><td style=3D"overflow:hidden;padding:2px 3px;vertica=
l-align:bottom;text-align:right">500000</td><td style=3D"overflow:hidden;pa=
dding:2px 3px;vertical-align:bottom;text-align:right">200000000</td></tr><t=
r style=3D"height:21px"><td style=3D"overflow:hidden;padding:2px 3px;vertic=
al-align:bottom;text-align:right">300</td><td style=3D"overflow:hidden;padd=
ing:2px 3px;vertical-align:bottom;text-align:right">700000</td><td style=3D=
"overflow:hidden;padding:2px 3px;vertical-align:bottom;text-align:right">21=
0000000</td></tr><tr style=3D"height:21px"><td style=3D"overflow:hidden;pad=
ding:2px 3px;vertical-align:bottom;text-align:right">200</td><td style=3D"o=
verflow:hidden;padding:2px 3px;vertical-align:bottom;text-align:right">1000=
000</td><td style=3D"overflow:hidden;padding:2px 3px;vertical-align:bottom;=
text-align:right">200000000</td></tr><tr style=3D"height:21px"><td style=3D=
"overflow:hidden;padding:2px 3px;vertical-align:bottom;text-align:right">10=
0</td><td style=3D"overflow:hidden;padding:2px 3px;vertical-align:bottom;te=
xt-align:right">1500000</td><td style=3D"overflow:hidden;padding:2px 3px;ve=
rtical-align:bottom;text-align:right">150000000</td></tr><tr style=3D"heigh=
t:21px"><td style=3D"overflow:hidden;padding:2px 3px;vertical-align:bottom;=
text-align:right">50</td><td style=3D"overflow:hidden;padding:2px 3px;verti=
cal-align:bottom;text-align:right">5000000</td><td style=3D"overflow:hidden=
;padding:2px 3px;vertical-align:bottom;text-align:right">250000000</td></tr=
><tr style=3D"height:21px"><td style=3D"overflow:hidden;padding:2px 3px;ver=
tical-align:bottom;text-align:right">20</td><td style=3D"overflow:hidden;pa=
dding:2px 3px;vertical-align:bottom;text-align:right">10000000</td><td styl=
e=3D"overflow:hidden;padding:2px 3px;vertical-align:bottom;text-align:right=
">200000000</td></tr></tbody></table></div><div>A miner would create a 5MB =
block and receive 0.25 BTC<br></div><div><br></div><div>Scenario 2</div><di=
v><table dir=3D"ltr" style=3D"table-layout:fixed;font-size:10pt;font-family=
:arial,sans,sans-serif;width:0px;border-collapse:collapse;border-color:curr=
entcolor;border-style:none;border-width:medium" border=3D"1" cellspacing=3D=
"0" cellpadding=3D"0"><colgroup><col width=3D"100"><col width=3D"100"><col =
width=3D"100"></colgroup><tbody><tr style=3D"height:21px"><td style=3D"over=
flow:hidden;padding:2px 3px;vertical-align:bottom">Sat/byte</td><td style=
=3D"overflow:hidden;padding:2px 3px;vertical-align:bottom">Bytes</td><td st=
yle=3D"overflow:hidden;padding:2px 3px;vertical-align:bottom">Reward</td></=
tr><tr style=3D"height:21px"><td style=3D"overflow:hidden;padding:2px 3px;v=
ertical-align:bottom;text-align:right">400</td><td style=3D"overflow:hidden=
;padding:2px 3px;vertical-align:bottom;text-align:right">600000</td><td sty=
le=3D"overflow:hidden;padding:2px 3px;vertical-align:bottom;text-align:righ=
t">240000000</td></tr><tr style=3D"height:21px"><td style=3D"overflow:hidde=
n;padding:2px 3px;vertical-align:bottom;text-align:right">300</td><td style=
=3D"overflow:hidden;padding:2px 3px;vertical-align:bottom;text-align:right"=
>700000</td><td style=3D"overflow:hidden;padding:2px 3px;vertical-align:bot=
tom;text-align:right">210000000</td></tr><tr style=3D"height:21px"><td styl=
e=3D"overflow:hidden;padding:2px 3px;vertical-align:bottom;text-align:right=
">200</td><td style=3D"overflow:hidden;padding:2px 3px;vertical-align:botto=
m;text-align:right">1000000</td><td style=3D"overflow:hidden;padding:2px 3p=
x;vertical-align:bottom;text-align:right">200000000</td></tr><tr style=3D"h=
eight:21px"><td style=3D"overflow:hidden;padding:2px 3px;vertical-align:bot=
tom;text-align:right">100</td><td style=3D"overflow:hidden;padding:2px 3px;=
vertical-align:bottom;text-align:right">1800000</td><td style=3D"overflow:h=
idden;padding:2px 3px;vertical-align:bottom;text-align:right">180000000</td=
></tr><tr style=3D"height:21px"><td style=3D"overflow:hidden;padding:2px 3p=
x;vertical-align:bottom;text-align:right">50</td><td style=3D"overflow:hidd=
en;padding:2px 3px;vertical-align:bottom;text-align:right">4000000</td><td =
style=3D"overflow:hidden;padding:2px 3px;vertical-align:bottom;text-align:r=
ight">200000000</td></tr><tr style=3D"height:21px"><td style=3D"overflow:hi=
dden;padding:2px 3px;vertical-align:bottom;text-align:right">20</td><td sty=
le=3D"overflow:hidden;padding:2px 3px;vertical-align:bottom;text-align:righ=
t">10000000</td><td style=3D"overflow:hidden;padding:2px 3px;vertical-align=
:bottom;text-align:right">200000000</td></tr></tbody></table></div><div><b>=
</b></div><div>A miner would create a 600KB block and receive 0.24 BTC<br><=
/div><br></div>Thanks,<br></div>William Morriss<br></div></div></div></div>
<br></div></div><span class=3D"">______________________________<wbr>_______=
__________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div>

--001a1142d310ef2707055f2fa791--