path: root/88/46a78e964ecef4d67de6151abded2fc492230a

Return-Path: <outlook_32F81FD1D1BD8CA0@outlook.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id DA1239FA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 20 Mar 2017 15:46:32 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from COL004-OMC3S11.hotmail.com (col004-omc3s11.hotmail.com
	[65.55.34.149])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 84AD91F5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 20 Mar 2017 15:46:31 +0000 (UTC)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com ([65.55.34.136])
	by COL004-OMC3S11.hotmail.com over TLS secured channel with
	Microsoft SMTPSVC(7.5.7601.23008); Mon, 20 Mar 2017 08:46:30 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com;
	s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; 
	bh=dIRxyx/PJogZvZpxhqkQKtXSMXXp0Q6OrpVQeNwiM/Q=;
	b=nifXbpdXErs4iNd4z1T18KsVwYV9MuEG9QS7gej0ruTssxvbXs1q7/3x2wT7U0v9NbuR8cCaFDtkcOcNzA+uxA5zX+SUT4+xTmRpuRjqaQDSFpKl5wuzxzoPfuXIEjZMLMyMhOhq81Ub2gk8E3Cn7Kus3bKaseS24jNY9kLAY3+oPqO4kfuWkBzSTBFpYx8UOoDezrsJho1H1E9S9K1u9wwQLUTxCSWxnxTs/rjUpKLf5U0qqgVDgccQOEN3nMtAomWtvR6aY7AZpF+0nkSDj9LKOJnAeMQuxreaT9Ptkg1ztL1Tm3ak1StAIoZDNztEgKQKUOknBBmyme7ihqRx0g==
Received: from SN1NAM02FT027.eop-nam02.prod.protection.outlook.com
	(10.152.72.54) by SN1NAM02HT061.eop-nam02.prod.protection.outlook.com
	(10.152.73.70) with Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.7;
	Mon, 20 Mar 2017 15:46:29 +0000
Received: from BL2PR03MB435.namprd03.prod.outlook.com (10.152.72.56) by
	SN1NAM02FT027.mail.protection.outlook.com (10.152.72.99) with Microsoft
	SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id
	15.1.977.7 via Frontend Transport; Mon, 20 Mar 2017 15:46:29 +0000
Received: from BL2PR03MB435.namprd03.prod.outlook.com ([10.141.92.24]) by
	BL2PR03MB435.namprd03.prod.outlook.com ([10.141.92.24]) with mapi id
	15.01.0977.013; Mon, 20 Mar 2017 15:46:29 +0000
From: John Hardy <john@seebitcoin.com>
To: Andrew Johnson <andrew.johnson83@gmail.com>, Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Thread-Topic: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA):
	Protecting Bitcoin from malicious miners
Thread-Index: AQHSoADHJYPXh2ezvUyqDSZwzGpL4qGd3+iAgAABHP0=
Sender: John Hardy <outlook_32F81FD1D1BD8CA0@outlook.com>
Date: Mon, 20 Mar 2017 15:46:28 +0000
Message-ID: <BL2PR03MB435F8B16B15BA7E0992DCA5EE3A0@BL2PR03MB435.namprd03.prod.outlook.com>
References: <BL2PR03MB435F510935FC7E230118AD3EE380@BL2PR03MB435.namprd03.prod.outlook.com>,
	<CAAy62_K5ePDuvVn8=DtwJX6ek00Z_r4u9LyA0W11vgZmQ=zzDg@mail.gmail.com>
In-Reply-To: <CAAy62_K5ePDuvVn8=DtwJX6ek00Z_r4u9LyA0W11vgZmQ=zzDg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: gmail.com; dkim=none (message not signed)
	header.d=none; gmail.com;
	dmarc=none action=none header.from=seebitcoin.com; 
x-incomingtopheadermarker: OriginalChecksum:F568E8D36405075B6B6CC999AEDA234E529A1BC67BDB4784CCB141C1539C7E9C;
	UpperCasedChecksum:8BDC370FED98A409B0688F5FAE4B607F807A2F82D7AED86F0255B1AF76A67E2A;
	SizeAsReceived:8440; Count:43
x-ms-exchange-messagesentrepresentingtype: 2
x-tmn: [VWx0S/VZLXpdtmHLa52WRDstlkDBiNih]
x-microsoft-exchange-diagnostics: 1; SN1NAM02HT061;
	5:JJcfw1L9EzCLrOLfUljKdZTPfHzF5aZvbbWKNyXGZxhd75SYELiJfheBetB1X/IvmEhYOsS+iWXuI+xe7PNeTWKKCtA+/t64DQf+JWuuY3Q4BZ4RsthN4F8xv24Gr8g/gLUSuVGpwcdzW0ROT5Kj6Q==;
	24:WFIes8aFGM3q3JEbj9tuF4eSZDTfbjtKBrKJt8drwN9k/wjtheb+w22jMzs/6aODYeiH6KGP4rgG9guyyZyFvCTzNve5WOOPhhOiUF0C4YU=;
	7:g0ZVnWjGCMNfR0rUrUiIE+Yz/LZro0yabtXoKdFsOiZKg1uYVMELa1grb2VBN4g/mJs1/HmAQpVLPBiXs7ol0Q3ZxHWG41zHeiHE9IhjSfS6bbFf8D7sOKgQcZYiPaAYxE1ZYOipw1mLsrbdQlNUjgkutI3c82nWD9rr7zvO5VuDpvCH9csxhuXsjyZng6ILKmy0114SRUE2jZzLZbbu/I2LNI/N38ZsurSOxYut+j8etXJ7fwdq9RWoBWJJbNiz2QW2x5r75PD+R8zfupJ+NfuPIWqwC7C5vqiBFP1q1AOCjwqDhEQF8tfPE8+oDpkH
x-incomingheadercount: 43
x-eopattributedmessage: 0
x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900017);
	DIR:OUT; SFP:1102; SCL:1; SRVR:SN1NAM02HT061;
	H:BL2PR03MB435.namprd03.prod.outlook.com; FPR:; SPF:None;
	LANG:en; 
x-ms-office365-filtering-correlation-id: b111a303-166e-407b-37c2-08d46fa8466a
x-microsoft-antispam: UriScan:; BCL:0; PCL:0;
	RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(1603101448)(1601125254)(1701031045);
	SRVR:SN1NAM02HT061; 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0;
	RULEID:(432015281)(444000031); SRVR:SN1NAM02HT061; BCL:0; PCL:0;
	RULEID:; SRVR:SN1NAM02HT061; 
x-forefront-prvs: 02524402D6
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_BL2PR03MB435F8B16B15BA7E0992DCA5EE3A0BL2PR03MB435namprd_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2017 15:46:28.9515 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT061
X-OriginalArrivalTime: 20 Mar 2017 15:46:30.0953 (UTC)
	FILETIME=[24F4F990:01D2A191]
X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 20 Mar 2017 15:50:02 +0000
Subject: Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR
 POWA): Protecting Bitcoin from malicious miners
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: Mon, 20 Mar 2017 15:46:33 -0000

--_000_BL2PR03MB435F8B16B15BA7E0992DCA5EE3A0BL2PR03MB435namprd_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

> By doing this you're significantly changing the economic incentives behin=
d bitcoin mining. How can you reliably invest in hardware if you have no id=
ea when or if your profitability is going to be cut by 50-75% based on a wh=
im?


Of course, that's why this is a last resort, successfully activated only in=
 response to a contentious hard fork. If it succeeds just once it should he=
lp prevent the same situation occurring in the future.


> You may also inadvertently create an entirely new attack vector if 50-75%=
 of the SHA256 hardware is taken offline and purchased by an entity who int=
ends to do harm to the network.

How so? If you have four proof of work methods, that 50-75% of SHA256 hashp=
ower would equate to 13-18% of total hashpower. If you can harm the network=
 with this much hashpower bitcoin was DOA.

________________________________
From: Andrew Johnson <andrew.johnson83@gmail.com>
Sent: Monday, March 20, 2017 3:38:01 PM
To: Bitcoin Protocol Discussion; John Hardy
Subject: Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA=
): Protecting Bitcoin from malicious miners

By doing this you're significantly changing the economic incentives behind =
bitcoin mining. How can you reliably invest in hardware if you have no idea=
 when or if your profitability is going to be cut by 50-75% based on a whim=
?

You may also inadvertently create an entirely new attack vector if 50-75% o=
f the SHA256 hardware is taken offline and purchased by an entity who inten=
ds to do harm to the network.

Bitcoin only works if most miners are honest, this has been known since the=
 beginning.

On Mon, Mar 20, 2017 at 9:50 AM John Hardy via bitcoin-dev <bitcoin-dev@lis=
ts.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote=
:

I=92m very worried about the state of miner centralisation in Bitcoin.

I always felt the centralising effects of ASIC manufacturing would resolve =
themselves once the first mover advantage had been exhausted and the indust=
ry had the opportunity to mature.

I had always assumed initial centralisation would be harmless since miners =
have no incentive to harm the network. This does not consider the risk of a=
 single entity with sufficient power and either poor, malicious or coerced =
decision making. I now believe that such centralisation poses a huge risk t=
o the security of Bitcoin and preemptive action needs to be taken to protec=
t the network from malicious actions by any party able to exert influence o=
ver a substantial portion of SHA256 hardware.

Inspired by UASF, I believe we should implement a Malicious miner Reactive =
Proof of Work Additions (MR POWA).

This would be a hard fork activated in response to a malicious attempt by a=
 hashpower majority to introduce a contentious hard fork.

The activation would occur once a fork was detected violating protocol (lik=
ely oversize blocks) with a majority of hashpower. The threshold and durati=
on for activation would need to be carefully considered.

I don=92t think we should eliminate SHA256 as a hashing method and change P=
OW entirely. That would be throwing the baby out with the bathwater and hur=
t the non-malicious miners who have invested in hardware, making it harder =
to gain their support.

Instead I believe we should introduce multiple new proofs of work that are =
already established and proven within existing altcoin implementations. As =
an example we could add Scrypt, Ethash and Equihash. Much of the code and m=
ining infrastructure already exists. Diversification of hardware (a mix of =
CPU and memory intensive methods) would also be positive for decentralisati=
on. Initial difficulty could simply be an estimated portion of existing inf=
rastructure.

This example would mean 4 proofs of work with 40 minute block target diffic=
ulty for each. There could also be a rule that two different proofs of work=
 must find a block before a method can start hashing again. This means ther=
e would only be 50% of hardware hashing at a time, and a sudden gain or dro=
p in hashpower from a particular method does not dramatically impact the fu=
nctioning of the network between difficulty adjustments. This also adds pro=
tection from attacks by the malicious SHA256 hashpower which could even be =
required to wait until all other methods have found a block before being al=
lowed to hash again.

50% hashing time would mean that the cost of electricity in relation to har=
dware would fall by 50%, reducing some of the centralising impact of subsid=
ised or inexpensive electricity in some regions over others.

Such a hard fork could also, counter-intuitively, introduce a block size in=
crease since while we=92re hard forking it makes sense to minimise the numb=
er of future hard forks where possible. It could also activate SegWit if it=
 hasn=92t already.

The beauty of this method is that it creates a huge risk to any malicious a=
ctor trying to abuse their position. Ideally, MR POWA would just serve as a=
 deterrent and never activate.

If consensus were to form around a hard fork in the future nodes would be a=
ble to upgrade and MR POWA, while automatically activating on non-upgraded =
nodes, would be of no economic significance: a vestigial chain immediately =
abandoned with no miner incentive.

I think this would be a great way to help prevent malicious use of hashpowe=
r to harm the network. This is the beauty of Bitcoin: for any road block th=
at emerges the economic majority can always find a way around.

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundat=
ion.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Andrew Johnson


--_000_BL2PR03MB435F8B16B15BA7E0992DCA5EE3A0BL2PR03MB435namprd_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
</head>
<body>
<style type=3D"text/css" style=3D"display:none;"><!-- P {margin-top:0;margi=
n-bottom:0;} --></style>
<div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font=
-family:Calibri,Arial,Helvetica,sans-serif;" dir=3D"ltr">
<p>&gt;&nbsp;<span style=3D"color: rgb(33, 33, 33); font-size: 15px;">By do=
ing this you're significantly changing the economic incentives behind bitco=
in mining. How can you reliably invest in hardware if you have no idea when=
 or if your profitability is going to be cut
 by 50-75% based on a whim?</span></p>
<p><span style=3D"color: rgb(33, 33, 33); font-size: 15px;"><br>
</span></p>
<p><span style=3D"color: rgb(33, 33, 33); font-size: 15px;">Of course, that=
's why this is a last resort, successfully activated only in response to a =
contentious hard fork. If it succeeds just once it should help prevent the =
same situation occurring in the future.</span></p>
<p><span style=3D"color: rgb(33, 33, 33); font-size: 15px;"><br>
</span></p>
<p><span style=3D"color: rgb(33, 33, 33); font-size: 15px;">&gt;&nbsp;<span=
 style=3D"color: rgb(33, 33, 33); font-size: 15px;">You may also inadverten=
tly create an entirely new attack vector if 50-75% of the SHA256 hardware i=
s taken offline and purchased by an entity who
 intends to do harm to the network.&nbsp;<br>
<br>
How so? If you have four proof of work methods, that 50-75% of SHA256 hashp=
ower would equate to 13-18% of total hashpower. If you can harm the network=
 with this much hashpower bitcoin was DOA.</span></span></p>
</div>
<hr style=3D"display:inline-block;width:98%" tabindex=3D"-1">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st=
yle=3D"font-size:11pt" color=3D"#000000"><b>From:</b> Andrew Johnson &lt;an=
drew.johnson83@gmail.com&gt;<br>
<b>Sent:</b> Monday, March 20, 2017 3:38:01 PM<br>
<b>To:</b> Bitcoin Protocol Discussion; John Hardy<br>
<b>Subject:</b> Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (=
MR POWA): Protecting Bitcoin from malicious miners</font>
<div>&nbsp;</div>
</div>
<div>
<div>By doing this you're significantly changing the economic incentives be=
hind bitcoin mining. How can you reliably invest in hardware if you have no=
 idea when or if your profitability is going to be cut by 50-75% based on a=
 whim?</div>
<div><br>
</div>
<div>You may also inadvertently create an entirely new attack vector if 50-=
75% of the SHA256 hardware is taken offline and purchased by an entity who =
intends to do harm to the network.&nbsp;</div>
<div><br>
</div>
<div>Bitcoin only works if most miners are honest, this has been known sinc=
e the beginning.&nbsp;</div>
<div><br>
</div>
<div>
<div class=3D"gmail_quote">
<div>On Mon, Mar 20, 2017 at 9:50 AM John Hardy via bitcoin-dev &lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfo=
undation.org</a>&gt; wrote:<br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div class=3D"gmail_msg">
<div id=3D"m_6451335042833672793divtagdefaultwrapper" style=3D"font-size:12=
pt;color:#000000;font-family:Calibri,Arial,Helvetica,sans-serif" class=3D"g=
mail_msg">
<p class=3D"gmail_msg"></p>
<div class=3D"gmail_msg">I=92m very worried about the state of miner centra=
lisation in Bitcoin.</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">I always felt the centralising effects of ASIC man=
ufacturing would resolve themselves once the first mover advantage had been=
 exhausted and the industry had the opportunity to mature.</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">I had always assumed initial centralisation would =
be harmless since miners have no incentive to harm the network. This does n=
ot consider the risk of a single entity with sufficient power and either po=
or, malicious or coerced decision
 making. I now believe that such centralisation poses a huge risk to the se=
curity of Bitcoin and preemptive action needs to be taken to protect the ne=
twork from malicious actions by any party able to exert influence over a su=
bstantial portion of SHA256 hardware.</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">Inspired by UASF, I believe we should implement a =
Malicious miner Reactive Proof of Work Additions (MR POWA).</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">This would be a hard fork activated in response to=
 a malicious attempt by a hashpower majority to introduce a contentious har=
d fork.</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">The activation would occur once a fork was detecte=
d violating protocol (likely oversize blocks) with a majority of hashpower.=
 The threshold and duration for activation would need to be carefully consi=
dered.</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">I don=92t think we should eliminate SHA256 as a ha=
shing method and change POW entirely. That would be throwing the baby out w=
ith the bathwater and hurt the non-malicious miners who have invested in ha=
rdware, making it harder to gain their
 support.</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">Instead I believe we should introduce multiple new=
 proofs of work that are already established and proven within existing alt=
coin implementations. As an example we could add Scrypt, Ethash and Equihas=
h. Much of the code and mining infrastructure
 already exists. Diversification of hardware (a mix of CPU and memory inten=
sive methods) would also be positive for decentralisation. Initial difficul=
ty could simply be an estimated portion of existing infrastructure.</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">This example would mean 4 proofs of work with 40 m=
inute block target difficulty for each. There could also be a rule that two=
 different proofs of work must find a block before a method can start hashi=
ng again. This means there would only
 be 50% of hardware hashing at a time, and a sudden gain or drop in hashpow=
er from a particular method does not dramatically impact the functioning of=
 the network between difficulty adjustments. This also adds protection from=
 attacks by the malicious SHA256
 hashpower which could even be required to wait until all other methods hav=
e found a block before being allowed to hash again.</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">50% hashing time would mean that the cost of elect=
ricity in relation to hardware would fall by 50%, reducing some of the cent=
ralising impact of subsidised or inexpensive electricity in some regions ov=
er others.</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">Such a hard fork could also, counter-intuitively, =
introduce a block size increase since while we=92re hard forking it makes s=
ense to minimise the number of future hard forks where possible. It could a=
lso activate SegWit if it hasn=92t already.</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">The beauty of this method is that it creates a hug=
e risk to any malicious actor trying to abuse their position. Ideally, MR P=
OWA would just serve as a deterrent and never activate.</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">If consensus were to form around a hard fork in th=
e future nodes would be able to upgrade and MR POWA, while automatically ac=
tivating on non-upgraded nodes, would be of no economic significance: a ves=
tigial chain immediately abandoned
 with no miner incentive.</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">I think this would be a great way to help prevent =
malicious use of hashpower to harm the network. This is the beauty of Bitco=
in: for any road block that emerges the economic majority can always find a=
 way around.</div>
<p class=3D"gmail_msg"></p>
</div>
</div>
_______________________________________________<br class=3D"gmail_msg">
bitcoin-dev mailing list<br class=3D"gmail_msg">
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" class=3D"gmail_msg=
" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D"g=
mail_msg">
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" class=3D"gmail_msg" target=3D"_blank">https://lists.linu=
xfoundation.org/mailman/listinfo/bitcoin-dev</a><br class=3D"gmail_msg">
</blockquote>
</div>
</div>
<div dir=3D"ltr">-- <br>
</div>
<div data-smartmail=3D"gmail_signature">Andrew Johnson<br>
<div><br>
</div>
</div>
</div>
</body>
</html>

--_000_BL2PR03MB435F8B16B15BA7E0992DCA5EE3A0BL2PR03MB435namprd_--