path: root/47/32749bdb5ebc9e181d81d853eb1552051d3099

Return-Path: <david@artlery.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id B94BBF67
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  6 Feb 2016 21:28:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yw0-f175.google.com (mail-yw0-f175.google.com
	[209.85.161.175])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B2C7A106
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  6 Feb 2016 21:28:29 +0000 (UTC)
Received: by mail-yw0-f175.google.com with SMTP id g127so77990106ywf.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 06 Feb 2016 13:28:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=artlery-com.20150623.gappssmtp.com; s=20150623;
	h=content-type:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=/5SLygB+7it10m9CZnypvVcRbIH3EHzMuQZ3DGdxOuo=;
	b=m+hOfFwov3gF3TrP41BmU29Q0e5D4yOrplm3ReDwr+8hzJ3y60euk2Ul1SqFdtRzTS
	efq35eFHVOENkE3YSDT8ztMpIl0mFGBVMJ1zgI0MwLo3UBjBAaMUcu3ewiz6ktACYFx1
	qngIZfOoioENbvNJQLIpTwa25ddFJojghrIVJfHrrU9mnTwPuuvQ1O0XSqAqTe1iig8p
	TwQLmppETFiLCuHe4BtJ1fCP4/e8GfQx4+6jaqyixsA3RenGYw+AiP0Lr7CkHQM13ASu
	fQtUVlT4uSA0frZsIHRkQyHQDUvQp0kva3mmSjAblyIvCb0h3kmn1JzgoVaWcnRbcV59
	qETQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:content-type:mime-version:subject:from
	:in-reply-to:date:cc:content-transfer-encoding:message-id:references
	:to; bh=/5SLygB+7it10m9CZnypvVcRbIH3EHzMuQZ3DGdxOuo=;
	b=D7vxPiGLVphtlxrdfNXBU5/hwBHXP9EO1Pr7PfdWWOLGvZgAM7HkrGcnSiQ0VkLHpE
	WCF4k5AY+AaUUsUvdYcwdlFvkECDy43swimiL9t9SJEZAMEWN2VXifqKyJZ6TZoCf2An
	8SR9VE8SB1kGUixa+Zt1hCT1AwzGT4/t8kpwEFX2cb+/eJt9wkoTVwk4XIhzPPpjGe8q
	UyeTNosbtd7A/qqXPnm1E9lE+QjkJoxrIy3y1GqL1s5fpf0dvuvz25mxanJu1b789rxT
	oXrPVi2U91D00uiJ8kMICwn2o1BFkaCB2ldWUv9FOr6MMzVhYoSVCuwqZYylSlPBvbkb
	2zVA==
X-Gm-Message-State: AG10YOQtYl7uDPIg7NLpaqGqTYW212eyURBqXz9ZZejh6jj3FreNkyOOE0qrXPZZt6S4tA==
X-Received: by 10.129.152.9 with SMTP id p9mr1372840ywg.85.1454794108905;
	Sat, 06 Feb 2016 13:28:28 -0800 (PST)
Received: from [100.119.122.105] (150.sub-70-192-33.myvzw.com. [70.192.33.150])
	by smtp.gmail.com with ESMTPSA id
	k186sm15388635ywf.14.2016.02.06.13.28.24
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 06 Feb 2016 13:28:28 -0800 (PST)
Content-Type: multipart/alternative;
	boundary=Apple-Mail-EB8059C0-6ED2-408E-B58B-B06E3D1F2FA0
Mime-Version: 1.0 (1.0)
From: David Thomson <david@artlery.com>
X-Mailer: iPhone Mail (13D15)
In-Reply-To: <CABsx9T2AUwDdz3JowpQYeusDgCBwfNFCDz0Kfut9ffT6gSaGeQ@mail.gmail.com>
Date: Sat, 6 Feb 2016 16:28:22 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <E17AC2D4-AA22-48CD-9065-7D2071A3D8EA@artlery.com>
References: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.com>
	<201602060012.26728.luke@dashjr.org>
	<CABm2gDrns0+eZdLyNk=tDNbnMsC1tT1MfEY93cJf1V_8TPjmLA@mail.gmail.com>
	<CABsx9T2LuMZciXpMiY24+rPzhj1VT6j=HJ5STtnQmnfnA_XFUw@mail.gmail.com>
	<CALqxMTGu1EtVxRYTxLBpE-0zWH59dnQa1zst9p9vdmbCckBjtQ@mail.gmail.com>
	<CABsx9T2AUwDdz3JowpQYeusDgCBwfNFCDz0Kfut9ffT6gSaGeQ@mail.gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, HTML_MESSAGE, MIME_QP_LONG_LINE,
	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
X-Mailman-Approved-At: Sat, 06 Feb 2016 21:33:26 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2
	megabytes
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Sat, 06 Feb 2016 21:28:30 -0000


--Apple-Mail-EB8059C0-6ED2-408E-B58B-B06E3D1F2FA0
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Gavin,

I saw this in your blog post:

"Miners producing up-version blocks is a coordination mechanism. Other coord=
ination mechanisms are possible=E2=80=93 there could be a centrally determin=
ed =E2=80=9Cflag day=E2=80=9D or =E2=80=9Cflag block=E2=80=9D when everybody=
 (or almost everybody) agrees that a change will happen."

Can you describe this a bit more? How would either a "flag day" or "flag blo=
ck" work as an alternative and why did you decide against them?

More thoughts and questions inline, thanks!

On Feb 6, 2016, at 12:45 PM, Gavin Andresen via bitcoin-dev <bitcoin-dev@lis=
ts.linuxfoundation.org> wrote:

>> On Sat, Feb 6, 2016 at 12:01 PM, Adam Back <adam@cypherspace.org> wrote:
>>=20
>> It would probably be a good idea to have a security considerations
>> section
>=20
> Containing what?  I'm not aware of any security considerations that are an=
y different from any other consensus rules change.

Can you explain and justify why that is the case? It would be nice to see th=
at rationale laid out more fully as to why it's no different.

>=20
> (I can write a blog post summarizing our slack discussion of SPV security i=
mmediately after the first greater-than-1mb-block if you like).

I'm not familiar with the context of your slack discussion, but why would yo=
u wait to summarize that only after the first-greater-than-1mb-block?

>=20
> =20
>> , also, is there a list of which exchange, library, wallet,
>> pool, stats server, hardware etc you have tested this change against?
>=20
> That testing is happening by the exchange, library, wallet, etc providers t=
hemselves. There is a list on the Classic home page:
>=20
> https://bitcoinclassic.com/

Is there a way to provide more transparency and visibility into that process=
 and level of readiness? Is there an expectation of certain levels of readin=
ess here before certain other things happen? I was thinking it would be real=
ly useful to have a visual timeline of events associated with all of this. M=
aybe you could add that to one of your web pages?

> =20
>>=20
>> Do you have a rollback plan in the event the hard-fork triggers via
>> false voting as seemed to be prevalent during XT?  (Or rollback just
>> as contingency if something unforseen goes wrong).
>=20
> The only voting in this BIP is done by the miners, and that cannot be fake=
d.
>=20
> Are you talking about people spinning up pseudo-full-nodes that fake the u=
ser-agent?
>=20
> As I said, there are people who have said they will spin up thousands of f=
ull nodes to help prevent possible Sybil attacks which would become marginal=
ly easier to accomplish immediately after the first >1mb block was produced a=
nd full nodes that hadn't upgraded were left behind.
>=20
> Would Blockstream be willing to help out by running a dozen or two extra f=
ull nodes?
>=20
> I can't imagine any even-remotely-likely sequence of events that would req=
uire a rollback, can you be more specific about what you are imagining?  Min=
ers suddenly getting cold feet?

Well that, but also past performance isn't an indication of future performan=
ce, necessarily. They might have gone out of business, to give one example. T=
here is surely assumed self-interest, but I have also seen rumors floating a=
round of this being used as an arbitrage opportunity. Would suck to imagine t=
hat ever happening, but since this seems like it's being managed on more han=
dshake type of deals (or conversations), are there any legal documents backi=
ng those commitments up? Or is that definitely overkill?

Maybe it's worth documenting the full range of possible series of events and=
 then their presumed level of unlikelihood? "What can go wrong will go wrong=
", "Black Swan" events, type of considerations. :) Often when people discuss=
 unlikely things like crypto being broken, it's like, "Assuming processing p=
ower of x, increasing at a rate of x, and a known age of the universe of x, i=
t would take a billion times the known length of the universe for that to ha=
ppen".

Certainly not everything fits so easily into that framing, but it would be r=
eally helpful to see the "what could possibly go wrong" things fully enumera=
ted.

Thanks!!

Dave

> =20
>> How do you plan to monitor and manage security through the hard-fork?
>=20
> I don't plan to monitor or manage anything; the Bitcoin network is self-mo=
nitoring and self-managing. Services like statoshi.infowill do the monitorin=
g, and miners and people and businesses will manage the network, as they do e=
very day.
>=20
> --=20
> --
> Gavin Andresen
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--Apple-Mail-EB8059C0-6ED2-408E-B58B-B06E3D1F2FA0
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><div><span style=3D"background-color: r=
gba(255, 255, 255, 0);">Gavin,</span></div><div><span style=3D"background-co=
lor: rgba(255, 255, 255, 0);"><br></span></div><div><span style=3D"backgroun=
d-color: rgba(255, 255, 255, 0);">I saw this in your blog post:</span></div>=
<div><span style=3D"background-color: rgba(255, 255, 255, 0);"><br></span></=
div><div><span style=3D"background-color: rgba(255, 255, 255, 0);">"Miners p=
roducing up-version blocks is a coordination mechanism. Other coordination m=
echanisms are possible=E2=80=93 there could be a centrally determined =E2=80=
=9Cflag day=E2=80=9D or =E2=80=9Cflag block=E2=80=9D when everybody (or almo=
st everybody) agrees that a change will happen."</span></div><div><span styl=
e=3D"background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span s=
tyle=3D"background-color: rgba(255, 255, 255, 0);">Can you describe this a b=
it more? How would either a "flag day" or "flag block" work as an alternativ=
e and why did you decide against them?</span></div><div><span style=3D"backg=
round-color: rgba(255, 255, 255, 0);"><br></span></div><div><div><span style=
=3D"background-color: rgba(255, 255, 255, 0);">More thoughts and questions i=
nline, thanks!</span></div><div><span style=3D"background-color: rgba(255, 2=
55, 255, 0);"><br></span></div><span style=3D"background-color: rgba(255, 25=
5, 255, 0);">On Feb 6, 2016, at 12:45 PM, Gavin Andresen via bitcoin-dev &lt=
;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a>&gt; wrote:<br><br></span></div><blockquote type=3D"c=
ite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote type=3D"cite"><font color=3D"#000000"><span style=3D"background-=
color: rgba(255, 255, 255, 0);">On Sat, Feb 6, 2016 at 12:01 PM, Adam Back&n=
bsp;<span dir=3D"ltr">&lt;<a href=3D"mailto:adam@cypherspace.org" target=3D"=
_blank">adam@cypherspace.org</a>&gt;</span>&nbsp;wrote:<br></span></font></b=
lockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8=
ex; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><font color=3D=
"#000000"><span style=3D"background-color: rgba(255, 255, 255, 0);"><br>It w=
ould probably be a good idea to have a security considerations<br>section</s=
pan></font></blockquote><div><font color=3D"#000000"><span style=3D"backgrou=
nd-color: rgba(255, 255, 255, 0);"><br></span></font></div><div><font color=3D=
"#000000"><span style=3D"background-color: rgba(255, 255, 255, 0);">Containi=
ng what?&nbsp; I'm not aware of any security considerations that are any dif=
ferent from any other consensus rules change.</span></font></div></div></div=
></div></blockquote><div><span style=3D"background-color: rgba(255, 255, 255=
, 0);"><br></span></div><span style=3D"background-color: rgba(255, 255, 255,=
 0);">Can you explain and justify why that is the case? It would be nice to s=
ee that rationale laid out more fully as to why it's no different.</span><di=
v><span style=3D"background-color: rgba(255, 255, 255, 0);"><br></span><bloc=
kquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D=
"gmail_quote"><div><font color=3D"#000000"><span style=3D"background-color: r=
gba(255, 255, 255, 0);"><br></span></font></div><div><font color=3D"#000000"=
><span style=3D"background-color: rgba(255, 255, 255, 0);">(I can write a bl=
og post summarizing our slack discussion of SPV security immediately after t=
he first greater-than-1mb-block if you like).</span></font></div></div></div=
></div></blockquote><div><span style=3D"background-color: rgba(255, 255, 255=
, 0);"><br></span></div><div><span style=3D"background-color: rgba(255, 255,=
 255, 0);">I'm not familiar with the context of your slack discussion, but w=
hy would you wait to summarize that only after the first-greater-than-1mb-bl=
ock?</span></div><span style=3D"background-color: rgba(255, 255, 255, 0);"><=
br></span><blockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><div><font color=3D"#000000"><span style=3D"b=
ackground-color: rgba(255, 255, 255, 0);"><br></span></font></div><div><font=
 color=3D"#000000"><span style=3D"background-color: rgba(255, 255, 255, 0);"=
>&nbsp;</span></font></div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0px 0px 0px 0.8ex; border-left-color: rgb(204, 204, 204); padding-left: 1e=
x;"><font color=3D"#000000"><span style=3D"background-color: rgba(255, 255, 2=
55, 0);">, also, is there a list of which exchange, library, wallet,<br>pool=
, stats server, hardware etc you have tested this change against?</span></fo=
nt></blockquote><div><font color=3D"#000000"><span style=3D"background-color=
: rgba(255, 255, 255, 0);"><br></span></font></div><div><font color=3D"#0000=
00"><span style=3D"background-color: rgba(255, 255, 255, 0);">That testing i=
s happening by the exchange, library, wallet, etc providers themselves. Ther=
e is a list on the Classic home page:</span></font></div><div><font color=3D=
"#000000"><span style=3D"background-color: rgba(255, 255, 255, 0);"><br></sp=
an></font></div><div><a href=3D"https://bitcoinclassic.com/" style=3D"backgr=
ound-color: rgba(255, 255, 255, 0);"><font color=3D"#000000">https://bitcoin=
classic.com/</font></a></div></div></div></div></blockquote><div><span style=
=3D"background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span s=
tyle=3D"background-color: rgba(255, 255, 255, 0);">Is there a way to provide=
 more transparency and visibility into that process and level of readiness? I=
s there an expectation of certain levels of readiness here before certain ot=
her things happen? I was thinking it would be really useful to have a visual=
 timeline of events associated with all of this. Maybe you could add that to=
 one of your web pages?</span></div><span style=3D"background-color: rgba(25=
5, 255, 255, 0);"><br></span><blockquote type=3D"cite"><div dir=3D"ltr"><div=
 class=3D"gmail_extra"><div class=3D"gmail_quote"><div><font color=3D"#00000=
0"><span style=3D"background-color: rgba(255, 255, 255, 0);">&nbsp;<br></spa=
n></font></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0p=
x 0.8ex; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><font co=
lor=3D"#000000"><span style=3D"background-color: rgba(255, 255, 255, 0);"><b=
r>Do you have a rollback plan in the event the hard-fork triggers via<br>fal=
se voting as seemed to be prevalent during XT?&nbsp; (Or rollback just<br>as=
 contingency if something unforseen goes wrong).</span></font></blockquote><=
div><font color=3D"#000000"><span style=3D"background-color: rgba(255, 255, 2=
55, 0);"><br></span></font></div><div><font color=3D"#000000"><span style=3D=
"background-color: rgba(255, 255, 255, 0);">The only voting in this BIP is d=
one by the miners, and that cannot be faked.</span></font></div><div><font c=
olor=3D"#000000"><span style=3D"background-color: rgba(255, 255, 255, 0);"><=
br></span></font></div><div><font color=3D"#000000"><span style=3D"backgroun=
d-color: rgba(255, 255, 255, 0);">Are you talking about people spinning up p=
seudo-full-nodes that fake the user-agent?</span></font></div><div><font col=
or=3D"#000000"><span style=3D"background-color: rgba(255, 255, 255, 0);"><br=
></span></font></div><div><font color=3D"#000000"><span style=3D"background-=
color: rgba(255, 255, 255, 0);">As I said, there are people who have said th=
ey will spin up thousands of full nodes to help prevent possible Sybil attac=
ks which would become marginally easier to accomplish immediately after the f=
irst &gt;1mb block was produced and full nodes that hadn't upgraded were lef=
t behind.</span></font></div><div><font color=3D"#000000"><span style=3D"bac=
kground-color: rgba(255, 255, 255, 0);"><br></span></font></div><div><font c=
olor=3D"#000000"><span style=3D"background-color: rgba(255, 255, 255, 0);">W=
ould Blockstream be willing to help out by running a dozen or two extra full=
 nodes?</span></font></div><div><font color=3D"#000000"><span style=3D"backg=
round-color: rgba(255, 255, 255, 0);"><br></span></font></div><div><font col=
or=3D"#000000"><span style=3D"background-color: rgba(255, 255, 255, 0);">I c=
an't imagine any even-remotely-likely sequence of events that would require a=
 rollback, can you be more specific about what you are imagining?&nbsp; Mine=
rs suddenly getting cold feet?</span></font></div></div></div></div></blockq=
uote><div><span style=3D"background-color: rgba(255, 255, 255, 0);"><br></sp=
an></div><div><span style=3D"background-color: rgba(255, 255, 255, 0);">Well=
 that, but also past performance isn't an indication of future performance, n=
ecessarily. They might have gone out of business, to give one example. There=
 is surely assumed self-interest, but I have also seen rumors floating aroun=
d of this being used as an arbitrage opportunity. Would suck to imagine that=
 ever happening, but since this seems like it's being managed on more handsh=
ake type of deals (or conversations), are there any legal documents backing t=
hose commitments up? Or is that definitely overkill?</span></div><div><span s=
tyle=3D"background-color: rgba(255, 255, 255, 0);"><br></span></div><div><sp=
an style=3D"background-color: rgba(255, 255, 255, 0);">Maybe it's worth docu=
menting the full range of possible series of events and then their presumed l=
evel of unlikelihood? "What can go wrong will go wrong", "Black Swan" events=
, type of considerations. :) Often when people discuss unlikely things like c=
rypto being broken, it's like, "Assuming processing power of x, increasing a=
t a rate of x, and a known age of the universe of x, it would take a billion=
 times the known length of the universe for that to happen".</span></div><di=
v><span style=3D"background-color: rgba(255, 255, 255, 0);"><br></span></div=
><div><span style=3D"background-color: rgba(255, 255, 255, 0);">Certainly no=
t everything fits so easily into that framing, but it would be really helpfu=
l to see the "what could possibly go wrong" things fully enumerated.</span><=
/div><div><span style=3D"background-color: rgba(255, 255, 255, 0);"><br></sp=
an></div><div><span style=3D"background-color: rgba(255, 255, 255, 0);">Than=
ks!!</span></div><div><span style=3D"background-color: rgba(255, 255, 255, 0=
);"><br></span></div><div><span style=3D"background-color: rgba(255, 255, 25=
5, 0);">Dave</span></div><span style=3D"background-color: rgba(255, 255, 255=
, 0);"><br></span><blockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"g=
mail_extra"><div class=3D"gmail_quote"><div><font color=3D"#000000"><span st=
yle=3D"background-color: rgba(255, 255, 255, 0);">&nbsp;</span></font></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border=
-left-color: rgb(204, 204, 204); padding-left: 1ex;"><font color=3D"#000000"=
><span style=3D"background-color: rgba(255, 255, 255, 0);">How do you plan t=
o monitor and manage security through the hard-fork?</span></font></blockquo=
te><div><font color=3D"#000000"><span style=3D"background-color: rgba(255, 2=
55, 255, 0);"><br></span></font></div><div><font color=3D"#000000"><span sty=
le=3D"background-color: rgba(255, 255, 255, 0);">I don't plan to monitor or m=
anage anything; the Bitcoin network is self-monitoring and self-managing. Se=
rvices like&nbsp;<a href=3D"http://statoshi.info/">statoshi.info</a>will do t=
he monitoring, and miners and people and businesses will manage the network,=
 as they do every day.</span></font></div><div><font color=3D"#000000"><span=
 style=3D"background-color: rgba(255, 255, 255, 0);"><br></span></font></div=
></div><font color=3D"#000000"><span style=3D"background-color: rgba(255, 25=
5, 255, 0);">--&nbsp;<br></span></font><div class=3D"gmail_signature"><div d=
ir=3D"ltr"><div dir=3D"ltr"><div><font color=3D"#000000"><span style=3D"back=
ground-color: rgba(255, 255, 255, 0);">--<br>Gavin Andresen<br></span></font=
></div><div><font color=3D"#000000"><span style=3D"background-color: rgba(25=
5, 255, 255, 0);"><br></span></font></div></div></div></div></div></div></bl=
ockquote><blockquote type=3D"cite"><font color=3D"#000000"><span style=3D"ba=
ckground-color: rgba(255, 255, 255, 0);">___________________________________=
____________<br>bitcoin-dev mailing list<br><a href=3D"mailto:bitcoin-dev@li=
sts.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br><a hre=
f=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https:/=
/lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a></span></font></b=
lockquote></div></div></body></html>=

--Apple-Mail-EB8059C0-6ED2-408E-B58B-B06E3D1F2FA0--