path: root/41/0445f5d072923a89eafd734eb4fdda2d0333cf

Return-Path: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 16E648A7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  3 Aug 2015 09:01:09 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com
	[209.85.220.48])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E0D2C143
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  3 Aug 2015 09:01:07 +0000 (UTC)
Received: by pasy3 with SMTP id y3so9921535pas.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 03 Aug 2015 02:01:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:message-id:references:to;
	bh=IPCmP0hTr9xNhv/HNOIWvd0lKq9mc7GZxThpyQx3jcQ=;
	b=cGp+K5sddqut6+Cj8R7Fo4s2/NXfahnCSA+7AooZ0XIzZ2vYW6ababXVUa93OJ1k+i
	fR0bIj5y1NTvYEnRYDmPYJAh+auUNeMFRxpKLguWm9VaZIa6rwFIlinZ6qN853hf0ggE
	drpUQqW6w/EXx4ftFtFkcQAzLvSddRGGB6d+ENQvVOzcd6LvdeksfaUuj4Gu93kxPAU1
	oEMvntx7lLUcpsXIfEy8zLSglidwWDEVSRYYmnwzRwYT3cncWd/S6yp2d6Rq2G2IfHV8
	/hGTrNbUg4LZ2con84dE0qXi7UQhnCnQIK21cORY70xesZyFHaAdEJdaCfz4ayKz9Fzt
	COHw==
X-Received: by 10.66.221.138 with SMTP id qe10mr32794071pac.45.1438592467602; 
	Mon, 03 Aug 2015 02:01:07 -0700 (PDT)
Received: from [192.168.1.107] (cpe-76-167-237-202.san.res.rr.com.
	[76.167.237.202]) by smtp.gmail.com with ESMTPSA id
	cr4sm16768026pac.10.2015.08.03.02.01.04
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 03 Aug 2015 02:01:05 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_1ED4908E-80B8-4F2A-B4A5-676D6BA5CE7E";
	protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5
From: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <CAAO2FKFkMHy0i3GV1aHXu8Hiw5uVnSE2pk17n2mCqOfY-D8Weg@mail.gmail.com>
Date: Mon, 3 Aug 2015 02:01:02 -0700
Message-Id: <9D6A80DF-83E6-4F98-B7C2-2EE2F79CB2D1@gmail.com>
References: <CANe1mWxsAPzWut_gDqe4R-SkDPBYM392NzeVqbUzjwh+pydsWQ@mail.gmail.com>
	<CALqxMTEMajz6oHnGvocxy=xDFMBc1LaX1iWYM=w1PF0rH3syFg@mail.gmail.com>
	<55BF153B.9030001@bitcartel.com>
	<CAAO2FKEBBS5wxefGCPcurcRGg76sORrBMHvd2SSNiW1q_zWBWQ@mail.gmail.com>
	<CALqxMTE69h5OcnDSqSMeK+BbzFaScEqouQG=pVuyWrqG17BeXQ@mail.gmail.com>
	<CAAO2FKHZa_3VzMhQ-EVK9MzSnNGCfwb_GcKJHV52bYcWayJvig@mail.gmail.com>
	<291F9D27-024C-4982-B638-1ACDC4FE0672@gmail.com>
	<CAAO2FKGGyjJT8UhW9m1ZMRY4gmjf3F05mjW1eZ2byT+dwM28Ow@mail.gmail.com>
	<9A5F47B8-AD42-46CB-993B-661BAD0E62AC@gmail.com>
	<CAAO2FKFkMHy0i3GV1aHXu8Hiw5uVnSE2pk17n2mCqOfY-D8Weg@mail.gmail.com>
To: Hector Chu <hectorchu@gmail.com>
X-Mailer: Apple Mail (2.2098)
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,FREEMAIL_REPLY,HTML_MESSAGE,
	RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A reason we can all agree on to increase block
	size
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: Mon, 03 Aug 2015 09:01:09 -0000


--Apple-Mail=_1ED4908E-80B8-4F2A-B4A5-676D6BA5CE7E
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_A6485220-5643-4509-9DE1-FB5C37267D62"


--Apple-Mail=_A6485220-5643-4509-9DE1-FB5C37267D62
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Aug 3, 2015, at 1:52 AM, Hector Chu <hectorchu@gmail.com> wrote:
>=20
> On 3 August 2015 at 09:38, Eric Lombrozo <elombrozo@gmail.com =
<mailto:elombrozo@gmail.com>> wrote:
> We already have much more efficient, far more scalable systems that =
allow this kind of cooperation you speak of without the inconveniences =
of blockchains and such.
>=20
> There is a degree of difference between cooperation in day-to-day =
usage of the system and cooperation in the rare cases the system has a =
bug.
>=20

If it=E2=80=99s an as-of-yet unidentified issue that comes up, =
yes=E2=80=A6obviously we can=E2=80=99t plan for everything and we=E2=80=99=
ll make some mistakes. But here we=E2=80=99re talking about specific =
well-known issues (or at least well-known today) for which several =
people have proposed potential solutions. However, these things have =
been all but ignored in the public discourse.

> These incidents do, fortunately, present some of the better sides of =
humanity=E2=80=A6but=E2=80=A6the design of the network *broke* - and for =
reasons that are now well understood to be only worsened by larger =
blocks. These incidents are *not supposed to happen* - and if they do, =
it means we=E2=80=99ve botched something up and need to fix it. And by =
fix it, I mean fix the protocol so that given our best understanding of =
things in the present we can significantly reduce the potential for its =
occurrence in the future.
>=20
> Distribution by consensus is inherently a fragile system. The network =
will continue to break again and again as long as programmers are =
fallible. But the types of bugs that occur will change over time as we =
learn the best practices for maintaining the system.

I agree. But again, once we=E2=80=99ve identified specific issues, it is =
irresponsible to continue to pretend they don=E2=80=99t exist=E2=80=A6and =
to more highly prioritize changes that can only make the problem worse.

Again, for the record, I am not against ultimately allowing bigger =
blocks. I think it would be a good thing to be able to do this=E2=80=A6and=
 my main concerns are not around things like equipment costs or typical =
household bandwidth. I just think security is a more important feature =
than greater throughput and prioritize it thusly.


> The correct incentives here were not due to people potentially losing =
a lot of money. The incentives here were well-intentioned altruism. Some =
miners lost money as a result of these actions=E2=80=A6and they didn=E2=80=
=99t put up a fight. if you want to design a system around the =
assumption that this is how all such incidents will be resolved, please =
don=E2=80=99t spoil this for the rest of us.
>=20
> Altruism is a facade that hides other motivations. The party =
cooperating with the miners losing money were doing so to maintain good =
relationships with those miners and to make sure those miners stay =
within the system and not attack it.

I don=E2=80=99t disagree=E2=80=A6clearly even the miners that lost money =
believed that consensus was more valuable to them than a few bitcoins. =
However, it seems to be EXTREMELY dangerous to assume that it will =
always work out this way. What=E2=80=99s to stop a mining majority from =
deciding on-the-fly they want to keep a particular consensus rule that =
benefits them even if the core developers disagree?

>=20
> - Eric
>=20
>> On Aug 3, 2015, at 1:31 AM, Hector Chu <hectorchu@gmail.com =
<mailto:hectorchu@gmail.com>> wrote:
>>=20
>> What's wrong with a little cooperation to resolve things now and =
then? Man is not an island unto himself, we compete with each other and =
we cooperate with each other occasionally if it's mutually beneficial.
>>=20
>> You said yourself that a lot of money would have been lost if the two =
hard forks cited weren't resolved - that's the correct incentives at =
work again.
>>=20
>> On 3 August 2015 at 09:20, Eric Lombrozo <elombrozo@gmail.com =
<mailto:elombrozo@gmail.com>> wrote:
>> There have already been two notable incidents requiring manual =
intervention and good-faith cooperation between core devs and mining =
pool operators that would have either never gotten resolved alone or =
would have ended up costing a lot of people a lot of money had no action =
been taken (March 2013 and July 2015). They were both caused by =
consensus disagreement that directly or indirectly were brought about by =
bigger blocks. There is *strong* evidence=E2=80=A6and a great deal of =
theory explaining it=E2=80=A6that links larger blocks with the =
propensity for consensus forks that require manual intervention.
>>=20
>> Please, can we stop saying this is merely about decentralization and =
trustlessness? The very model upon which the security of the system is =
based *broke*=E2=80=A6as in, we were only able to recover because a few =
individuals deliberately manipulated the consensus rules to fix it =
manually. Shouldn=E2=80=99t we more highly prioritize fixing the issues =
that can lead to these incidents than trying to increase throughput? =
Increasing block size cannot possibly make these forking tendencies =
better=E2=80=A6but it very well could make them worse.
>>=20
>> - Eric
>>=20
>>> On Aug 3, 2015, at 1:06 AM, Hector Chu via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>>>=20
>>> On 3 August 2015 at 08:53, Adam Back <adam@cypherspace.org =
<mailto:adam@cypherspace.org>> wrote:
>>> Again this should not be a political or business compromise model - =
we
>>> must focus on scientific evaluation, technical requirements and
>>> security.
>>>=20
>>> I will assert that the block size is political because it affects =
nearly all users to some degree and not all those users are technically =
inclined or care to keep decentralisation in the current configuration =
as you do. This debate has forgotten the current and future users of =
Bitcoin. Most of them think the hit to node count in the short term =
preferable to making it expensive and competitive to transact.
>>>=20
>>> We all need a little faith that the system will reorganise and =
readjust after the move to big blocks in a way that still has a =
reasonable degree of decentralisation and trustlessness. The incentives =
of Bitcoin remain, so everyone's decentralised decision throughout the =
system, from miners, merchants and users, will continue to act according =
to those incentives.
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev =
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>>=20
>>=20
>=20
>=20


--Apple-Mail=_A6485220-5643-4509-9DE1-FB5C37267D62
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div =
class=3D"">On Aug 3, 2015, at 1:52 AM, Hector Chu &lt;<a =
href=3D"mailto:hectorchu@gmail.com" class=3D"">hectorchu@gmail.com</a>&gt;=
 wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div =
dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div =
class=3D"gmail_quote">On 3 August 2015 at 09:38, Eric Lombrozo <span =
dir=3D"ltr" class=3D"">&lt;<a href=3D"mailto:elombrozo@gmail.com" =
target=3D"_blank" class=3D"">elombrozo@gmail.com</a>&gt;</span> =
wrote:<br class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
style=3D"word-wrap:break-word" class=3D""><div class=3D"">We already =
have much more efficient, far more scalable systems that allow this kind =
of cooperation you speak of without the inconveniences of blockchains =
and such.</div></div></blockquote><div class=3D""><br =
class=3D""></div><div class=3D"">There is a degree of difference between =
cooperation in day-to-day usage of the system and cooperation in the =
rare cases the system has a bug.</div><div class=3D""><br =
class=3D""></div></div></div></div></div></blockquote><div><br =
class=3D""></div><div>If it=E2=80=99s an as-of-yet unidentified issue =
that comes up, yes=E2=80=A6obviously we can=E2=80=99t plan for =
everything and we=E2=80=99ll make some mistakes. But here we=E2=80=99re =
talking about specific well-known issues (or at least well-known today) =
for which several people have proposed potential solutions. However, =
these things have been all but ignored in the public discourse.</div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
style=3D"word-wrap:break-word" class=3D""><div class=3D"">These =
incidents do, fortunately, present some of the better sides of =
humanity=E2=80=A6but=E2=80=A6the design of the network *broke* - and for =
reasons that are now well understood to be only worsened by larger =
blocks. These incidents are *not supposed to happen* - and if they do, =
it means we=E2=80=99ve botched something up and need to fix it. And by =
fix it, I mean fix the protocol so that given our best understanding of =
things in the present we can significantly reduce the potential for its =
occurrence in the future.</div></div></blockquote><div class=3D""><br =
class=3D""></div><div class=3D"">Distribution by consensus is inherently =
a fragile system. The network will continue to break again and again as =
long as programmers are fallible. But the types of bugs that occur will =
change over time as we learn the best practices for maintaining the =
system.</div></div></div></div></div></blockquote><div><br =
class=3D""></div>I agree. But again, once we=E2=80=99ve identified =
specific issues, it is irresponsible to continue to pretend they don=E2=80=
=99t exist=E2=80=A6and to more highly prioritize changes that can only =
make the problem worse.</div><div><br class=3D""></div><div>Again, for =
the record, I am not against ultimately allowing bigger blocks. I think =
it would be a good thing to be able to do this=E2=80=A6and my main =
concerns are not around things like equipment costs or typical household =
bandwidth. I just think security is a more important feature than =
greater throughput and prioritize it thusly.<br class=3D""><div><br =
class=3D""></div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
style=3D"word-wrap:break-word" class=3D""><div class=3D"">The correct =
incentives here were not due to people potentially losing a lot of =
money. The incentives here were well-intentioned altruism. Some miners =
lost money as a result of these actions=E2=80=A6and they didn=E2=80=99t =
put up a fight. if you want to design a system around the assumption =
that this is how all such incidents will be resolved, please don=E2=80=99t=
 spoil this for the rest of us.<br =
class=3D""></div></div></blockquote><div class=3D""><br =
class=3D""></div><div class=3D"">Altruism is a facade that hides other =
motivations. The party cooperating with the miners losing money were =
doing so to maintain good relationships with those miners and to make =
sure those miners stay within the system and not attack =
it.</div></div></div></div></blockquote><div><br class=3D""></div>I =
don=E2=80=99t disagree=E2=80=A6clearly even the miners that lost money =
believed that consensus was more valuable to them than a few bitcoins. =
However, it seems to be EXTREMELY dangerous to assume that it will =
always work out this way. What=E2=80=99s to stop a mining majority from =
deciding on-the-fly they want to keep a particular consensus rule that =
benefits them even if the core developers disagree?</div><div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
style=3D"word-wrap:break-word" class=3D""><div class=3D""></div><span =
class=3D"HOEnZb"><font color=3D"#888888" class=3D""><div class=3D""><br =
class=3D""></div><div class=3D"">- Eric</div></font></span><div =
class=3D""><div class=3D"h5"><div class=3D""><br class=3D""><div =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On Aug =
3, 2015, at 1:31 AM, Hector Chu &lt;<a href=3D"mailto:hectorchu@gmail.com"=
 target=3D"_blank" class=3D"">hectorchu@gmail.com</a>&gt; =
wrote:</div><br class=3D""><div class=3D""><div dir=3D"ltr" =
class=3D"">What's wrong with a little cooperation to resolve things now =
and then? Man is not an island unto himself, we compete with each other =
and we cooperate with each other occasionally if it's mutually =
beneficial.<div class=3D""><br class=3D""></div><div class=3D"">You said =
yourself that a lot of money would have been lost if the two hard forks =
cited weren't resolved - that's the correct incentives at work =
again.</div></div><div class=3D"gmail_extra"><br class=3D""><div =
class=3D"gmail_quote">On 3 August 2015 at 09:20, Eric Lombrozo <span =
dir=3D"ltr" class=3D"">&lt;<a href=3D"mailto:elombrozo@gmail.com" =
target=3D"_blank" class=3D"">elombrozo@gmail.com</a>&gt;</span> =
wrote:<br class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
style=3D"word-wrap:break-word" class=3D"">There have already been two =
notable incidents requiring manual intervention and good-faith =
cooperation between core devs and mining pool operators that would have =
either never gotten resolved alone or would have ended up costing a lot =
of people a lot of money had no action been taken (March 2013 and July =
2015). They were both caused by consensus disagreement that directly or =
indirectly were brought about by bigger blocks. There is *strong* =
evidence=E2=80=A6and a great deal of theory explaining it=E2=80=A6that =
links larger blocks with the propensity for consensus forks that require =
manual intervention.<div class=3D""><br class=3D""></div><div =
class=3D"">Please, can we stop saying this is merely about =
decentralization and trustlessness? The very model upon which the =
security of the system is based *broke*=E2=80=A6as in, we were only able =
to recover because a few individuals deliberately manipulated the =
consensus rules to fix it manually. Shouldn=E2=80=99t we more highly =
prioritize fixing the issues that can lead to these incidents than =
trying to increase throughput? Increasing block size cannot possibly =
make these forking tendencies better=E2=80=A6but it very well could make =
them worse.</div><span class=3D""><font color=3D"#888888" class=3D""><div =
class=3D""><br class=3D""></div><div class=3D"">- =
Eric</div></font></span><div class=3D""><br class=3D""><div =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
class=3D""><div class=3D"">On Aug 3, 2015, at 1:06 AM, Hector Chu via =
bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
target=3D"_blank" class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt;=
 wrote:</div><br class=3D""></div></div><div class=3D""><div =
class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div =
class=3D"gmail_extra"><div class=3D"gmail_quote">On 3 August 2015 at =
08:53, Adam Back <span dir=3D"ltr" class=3D"">&lt;<a =
href=3D"mailto:adam@cypherspace.org" target=3D"_blank" =
class=3D"">adam@cypherspace.org</a>&gt;</span> wrote:<br =
class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">Again this should not =
be a political or business compromise model - we<br class=3D"">
must focus on scientific evaluation, technical requirements and<br =
class=3D"">
security.<br class=3D""></blockquote><div class=3D""><br =
class=3D""></div>I will assert that the block size is political because =
it affects nearly all users to some degree and not all those users are =
technically inclined or care to keep decentralisation in the current =
configuration as you do. This debate has forgotten the current and =
future users of Bitcoin. Most of them think the hit to node count in the =
short term preferable to making it expensive and competitive to =
transact.</div><div class=3D"gmail_quote"><br class=3D""></div><div =
class=3D"gmail_quote">We all need a little faith that the system will =
reorganise and readjust after the move to big blocks in a way that still =
has a reasonable degree of decentralisation and trustlessness. The =
incentives of Bitcoin remain, so everyone's decentralised decision =
throughout the system, from miners, merchants and users, will continue =
to act according to those incentives.</div></div></div></div></div><span =
class=3D"">
_______________________________________________<br class=3D"">bitcoin-dev =
mailing list<br class=3D""><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D""><a =
href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
target=3D"_blank" =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/a><br class=3D""></span></div></blockquote></div><br =
class=3D""></div></div></blockquote></div><br class=3D""></div>
</div></blockquote></div><br =
class=3D""></div></div></div></div></blockquote></div><br =
class=3D""></div></div>
</div></blockquote></div><br class=3D""></body></html>=

--Apple-Mail=_A6485220-5643-4509-9DE1-FB5C37267D62--

--Apple-Mail=_1ED4908E-80B8-4F2A-B4A5-676D6BA5CE7E
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVvy3OAAoJEJNAI64YFENUcb0P/3nOiopGk2CoFksA2C+2iTdv
p3DUS/Z+m8/CfkekJjlojUCtH5sfZNmG/9/Kp4ds94ug/IPD/KuEYYuGiJ7VJ2OF
+8iRUi2Pny1uI6yhDtWMiX7R52K22pU2HjX0gAh+Nrkkt2jqF4KfXNi/H82zS9p5
h6McHwSNbIqAJRFi/QEwS25OjY06nAA91Rm8yMbk4m6CdqWlgonyu969FTTX5XHw
ZtbQ590Ugs3UUZiDJMoSpjv2aaVB3ORdX67O6hdSc2EripKYP5I2cBG6r64hsJJu
HPZhzPfPY3NUSRCqO6RP/mZhKrenAd2TTylqvLSLGg44vJd3qcPb5BoxZ/RbMaOM
As8RSoUrwUJdL8c83YzE3SlnurF7A+BB6PGksJJM3+mvsrLgZobU5SdjMlhZnxGz
8xLApaE3b/AM0ADSI6nkuBvYkK7Ucklh4fF3CXhzrkF2MKuMrQHy1uMcKv+lm9dd
8/vPkjyC/zUl4DpvhwxmoR/7Dh4VFfSUlFQyAAaRxqVKxJVThQnlN7Bl3RHKhgQv
6fK5aVwnbhP9I3voNSFTuld8WfFR0AxXizd73JpjOXC5n6JEELfztlZ222JUHjww
dsx7pEYTl84ipgtag8gR+N8ymiRB716kM54JSWXrry9aVQjRWlLOHlDeAcINAnxP
MhSEmx4oaOOOxq1tMiB5
=Wmhe
-----END PGP SIGNATURE-----

--Apple-Mail=_1ED4908E-80B8-4F2A-B4A5-676D6BA5CE7E--