path: root/cc/fe11015b0b6bb9a989341b31771b50f170ac0e

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 A613B408
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jul 2015 19:17:50 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com
	[209.85.192.179])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 670FC191
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jul 2015 19:17:49 +0000 (UTC)
Received: by pdbnt7 with SMTP id nt7so72289541pdb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jul 2015 12:17:49 -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=NlcCyRCHk2283Ba/JAgxa4nPQNtShn3bCW4QU8+p5iM=;
	b=puNaAzbMHMgHmGco+3XAnq83mr1lSnjwc3P26OzcPYBBysdElq5UxCnzkV2GF6Pfh5
	DmfgRDFzbKriVAMs71R4pFNrPODH6el6/xl3YYuXPkr+sCOeXhmo79WYUZkzY+kbVkie
	H2giqbjIF6pJyKxZepTT218pGZjs7bItsDzTJwKiaHHFwDL/SZTerxPsTGHUckOyj+/1
	HQt/qPn4Q0nAH96TvB8ZGWPHOO2b5VBtiPXQ5iLpgJyDrYPRnEY5txOA+0rKbPwdOntI
	MUjJi88MGRLVzl1aDKUbGAGeyZZUfsisfNqEbZ/V0n87JJevdTvOT32dZ/izAfHZKqPb
	JfWA==
X-Received: by 10.70.31.5 with SMTP id w5mr9120881pdh.3.1437592668938;
	Wed, 22 Jul 2015 12:17:48 -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
	kw5sm4747410pab.29.2015.07.22.12.17.46
	(version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 22 Jul 2015 12:17:47 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_02174A37-04FB-4D42-8176-339E93D1AE0C";
	protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5b6
From: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <CADm_WcbnQQGZoQ92twfUvbzqGwu__xLn+BYOkHPZY_YT1pFrbA@mail.gmail.com>
Date: Wed, 22 Jul 2015 12:17:44 -0700
Message-Id: <D93173FE-B018-4CD8-A31D-714364ADFE80@gmail.com>
References: <CAPg+sBgs-ouEMu=LOVCmOyCGwfM1Ygxooz0shyvAuHDGGZYfJw@mail.gmail.com>
	<CAPg+sBgugLSVEwDLXhgey86_rM2fTjGWXFuXsiZioJKCZiHiNg@mail.gmail.com>
	<CADm_WcbnQQGZoQ92twfUvbzqGwu__xLn+BYOkHPZY_YT1pFrbA@mail.gmail.com>
To: Jeff Garzik <jgarzik@gmail.com>
X-Mailer: Apple Mail (2.2098)
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks
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: Wed, 22 Jul 2015 19:17:50 -0000


--Apple-Mail=_02174A37-04FB-4D42-8176-339E93D1AE0C
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_9E02F14E-0A66-4E19-8AA3-11D40A49CEA5"


--Apple-Mail=_9E02F14E-0A66-4E19-8AA3-11D40A49CEA5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Jul 22, 2015, at 10:33 AM, Jeff Garzik via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> On Wed, Jul 22, 2015 at 9:52 AM, Pieter Wuille via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> Some people have called the prospect of limited block space and the =
development of a fee market a change in policy compared to the past. I =
respectfully disagree with that. Bitcoin Core is not running the Bitcoin =
economy, and its developers have no authority to set its rules. Change =
in economics is always happening, and should be expected. Worse, =
intervening in consensus changes would make the ecosystem more dependent =
on the group taking that decision, not less.
>=20
>=20
>=20
> This completely ignores reality, what users have experienced for the =
past ~6 years.
>=20
> "Change in economics is always happening" does not begin to approach =
the scale of the change.
>=20
> For the entirety of bitcoin's history, absent long blocks and traffic =
bursts, fee pressure has been largely absent.

This is only because of the fact that only a negligible portion of miner =
income comes from fees - the vast majority still continues to be =
subsidized by block rewards. The original design of the protocol was =
such that this subsidy would be decreased over time to let fees become =
the predominant source of income for miners. Until we have fee =
pressures, there=E2=80=99s no incentive for the industry to find =
solutions to real problems that need solving. I think you underestimate =
the ingenuity of people when pressed for real solutions. The main =
barrier to Bitcoin adoption is NOT this issue=E2=80=A6and I believe the =
priorities are misplaced here. We=E2=80=99ve had over six years to start =
working on solutions but we keep =E2=80=9Ckicking the can down the =
road=E2=80=9D - until when?!?! I believe unless there=E2=80=99s a strong =
need to find a solution no solutions will really be found.

>=20
> Moving to a new economic policy where fee pressure is consistently =
present is radically different from what users, markets, and software =
have experienced and lived.
>=20
> Analysis such as [1][2] and more shows that users will hit a "painful" =
"wall" and market disruption will occur - eventually settling to a new =
equilibrium after a period of chaos - when blocks are consistently full.
>=20
> [1] http://hashingit.com/analysis/34-bitcoin-traffic-bulletin =
<http://hashingit.com/analysis/34-bitcoin-traffic-bulletin>
> [2] =
http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent =
<http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent>
>=20
> First, users & market are forced through this period of chaos by "let =
a fee market develop" as the whole market changes to a radically =
different economic policy, once the network has never seen before.
>=20
> Next, when blocks are consistently full, the past consensus was that =
block size limit will be increased eventually.  What happens at that =
point?
>=20
> Answer - Users & market are forced through a second period of chaos =
and disruption as the fee market is rebooted again by changing the block =
size limit.
>=20
> The average user hears a lot of noise on both sides of the block size =
debate, and really has no idea that the new "let a fee market develop" =
Bitcoin Core policy is going to raise fees on them.
>=20
> It is clear that
> - "let the fee market develop, Right Now" has not been thought through
> - Users are not prepared for a brand new economic policy
> - Users are unaware that a brand new economic policy will be foisted =
upon them
>=20

The current userbase and market is still tiny - we have to think bigger =
than this. We already go through loads of pain to use the current =
system=E2=80=A6and quite frankly, there are a number of other =
significant issues that I think are far bigger obstacles to widespread =
adoption than =E2=80=9CI have to pay a fee=E2=80=9D. For example, the =
current cost of verification is too high to continue to ensure the =
security of the network (as the July 4th fork clearly illustrated)=E2=80=A6=
and places huge centralization pressures on validation=E2=80=A6and =
simply will not support hundreds of millions of users or billions of =
users. Increasing block size actually worsens the scaling properties, it =
does not improve them. We need better scaling solutions - almost =
certainly this will require avoiding the need for global consensus for =
the vast majority of transactions (nested consensus or off-chain direct =
party-to-party contract negotiation, the lightning network, etc. The =
focus on reducing fee pressure by increasing block size is a distraction =
from far more fundamental issues, IMHO.

>=20
> So to point out what I consider obvious: if Bitcoin requires central =
control over its rules by a group of developers, it is completely =
uninteresting to me. Consensus changes should be done using consensus, =
and the default in case of controversy is no change.
>=20
>=20
> False.
>=20
> All that has to do be done to change bitcoin to a new economic policy =
- not seen in the entire 6 year history of bitcoin - is to stonewall =
work on block size.
>=20
> Closing size increase PRs and failing to participate in planning for a =
block size increase accomplishes your stated goal of changing bitcoin to =
a new economic policy.
>=20

Wrong - the economic policy of bitcoin has always been, from the =
beginning, to subsidize blocks initially and transition to fees. =
Artificially continuing to rely on block reward subsidies is what is a =
new economic policy. We=E2=80=99re already six years in, pretty soon =
another halving is coming - how long are we going to wait to start =
transitioning? The lower block reward subsidies are, the more pain fee =
pressures will cause.


> "no [code] change"... changes bitcoin to a brand new economic policy, =
picking economic winners & losers.  Some businesses will be priced out =
of bitcoin, etc.
>=20
> Stonewalling size increase changes is just as much as a Ben =
Bernanke/FOMC move as increasing the hard limit by hard fork.
>=20
>=20
> My personal opinion is that we - as a community - should indeed let a =
fee market develop, and rather sooner than later, and that "kicking the =
can down the road" is an incredibly dangerous precedent: if we are =
willing to go through the risk of a hard fork because of a fear of =
change of economics, then I believe that community is not ready to deal =
with change at all. And some change is inevitable, at any block size. =
Again, this does not mean the block size needs to be fixed forever, but =
its intent should be growing with the evolution of technology, not a =
panic reaction because a fear of change.
>=20
> But I am not in any position to force this view. I only hope that =
people don't think a fear of economic change is reason to give up =
consensus.
>=20
>=20
> Actually you are.
>=20
> When size increase progress gets frozen out of Bitcoin Core, that just =
increases the chances that progress must be made through a contentious =
hard fork.
>=20
> Further, it increases the market disruption users will experience, as =
described above.
>=20
> Think about the users.  Please.
>=20

I think about the billions of people out there in the world that could =
be using this technology that simply have no access to it right now. The =
majority or them which are unbanked, etc=E2=80=A6

More the reason to go through the steps needed while we=E2=80=99re still =
small to correct the core issues.

>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--Apple-Mail=_9E02F14E-0A66-4E19-8AA3-11D40A49CEA5
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 Jul 22, 2015, at 10:33 AM, Jeff Garzik via bitcoin-dev =
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" =
class=3D"">On Wed, Jul 22, 2015 at 9:52 AM, Pieter Wuille via =
bitcoin-dev <span dir=3D"ltr" class=3D"">&lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> =
wrote:<br class=3D""><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><p dir=3D"ltr" class=3D"">Some people =
have called the prospect of limited block space and the development of a =
fee market a change in policy compared to the past. I respectfully =
disagree with that. Bitcoin Core is not running the Bitcoin economy, and =
its developers have no authority to set its rules. Change in economics =
is always happening, and should be expected. Worse, intervening in =
consensus changes would make the ecosystem more dependent on the group =
taking that decision, not less.<br class=3D""></p><div class=3D""><br =
class=3D"webkit-block-placeholder"></div></blockquote><div class=3D""><br =
class=3D""></div><div class=3D"">This completely ignores <i =
class=3D"">reality</i>, what users have experienced for the past ~6 =
years.</div><div class=3D""><br class=3D""></div><div class=3D"">"Change =
in economics is always happening" does not begin to approach the scale =
of the change.</div><div class=3D""><br class=3D""></div><div =
class=3D"">For the entirety of bitcoin's history, absent long blocks and =
traffic bursts, fee pressure has been largely =
absent.</div></div></div></div></div></blockquote><div><br =
class=3D""></div><div>This is only because of the fact that only a =
negligible portion of miner income comes from fees - the vast majority =
still continues to be subsidized by block rewards. The original design =
of the protocol was such that this subsidy would be decreased over time =
to let fees become the predominant source of income for miners. Until we =
have fee pressures, there=E2=80=99s no incentive for the industry to =
find solutions to real problems that need solving. I think you =
underestimate the ingenuity of people when pressed for real solutions. =
The main barrier to Bitcoin adoption is NOT this issue=E2=80=A6and I =
believe the priorities are misplaced here. We=E2=80=99ve had over six =
years to start working on solutions but we keep =E2=80=9Ckicking the can =
down the road=E2=80=9D - until when?!?! I believe unless there=E2=80=99s =
a strong need to find a solution no solutions will really be =
found.</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"><div class=3D""><br class=3D""></div><div =
class=3D"">Moving to a new economic policy where fee pressure is =
consistently present is radically different from what users, markets, =
and software have experienced and <i =
class=3D"">lived.</i></div></div></div></div></div></blockquote><blockquot=
e type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" =
class=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div =
class=3D""><br class=3D""></div><div class=3D"">Analysis such as [1][2] =
and more shows that users will hit a "painful" "wall" and market =
disruption will occur - eventually settling to a new equilibrium after a =
period of chaos - when blocks are consistently full.</div><div =
class=3D""><br class=3D""></div><div class=3D"">[1]&nbsp;<a =
href=3D"http://hashingit.com/analysis/34-bitcoin-traffic-bulletin" =
class=3D"">http://hashingit.com/analysis/34-bitcoin-traffic-bulletin</a></=
div><div class=3D"">[2]&nbsp;<a =
href=3D"http://gavinandresen.ninja/why-increasing-the-max-block-size-is-ur=
gent" =
class=3D"">http://gavinandresen.ninja/why-increasing-the-max-block-size-is=
-urgent</a></div><div class=3D""><br class=3D""></div><div =
class=3D"">First, users &amp; market are forced through this period of =
chaos by "let a fee market develop" as the whole market changes to a =
radically different economic policy, once the network has never seen =
before.</div><div class=3D""><br class=3D""></div><div class=3D"">Next, =
when blocks are consistently full, the past consensus was that block =
size limit will be increased eventually.&nbsp; What happens at that =
point?</div><div class=3D""><br class=3D""></div><div class=3D"">Answer =
- Users &amp; market are forced through a second period of chaos and =
disruption as the fee market is rebooted <i class=3D"">again</i> by =
changing the block size limit.</div><div class=3D""><br =
class=3D""></div><div class=3D"">The average user hears a lot of noise =
on both sides of the block size debate, and really has no idea that the =
new "let a fee market develop" Bitcoin Core policy is going to <i =
class=3D"">raise fees</i>&nbsp;on them.</div><div class=3D""><br =
class=3D""></div><div class=3D"">It is clear that</div><div class=3D"">- =
"let the fee market develop, Right Now" has not been thought =
through</div><div class=3D"">- Users are not prepared for a brand new =
economic policy</div><div class=3D"">- Users are unaware that a brand =
new economic policy will be foisted upon them</div><div class=3D""><br =
class=3D""></div></div></div></div></div></blockquote><div><br =
class=3D""></div><div>The current userbase and market is still tiny - we =
have to think bigger than this. We already go through loads of pain to =
use the current system=E2=80=A6and quite frankly, there are a number of =
other significant issues that I think are far bigger obstacles to =
widespread adoption than =E2=80=9CI have to pay a fee=E2=80=9D. For =
example, the current cost of verification is too high to continue to =
ensure the security of the network (as the July 4th fork clearly =
illustrated)=E2=80=A6and places huge centralization pressures on =
validation=E2=80=A6and simply will not support hundreds of millions of =
users or billions of users. Increasing block size actually worsens the =
scaling properties, it does not improve them. We need better scaling =
solutions - almost certainly this will require avoiding the need for =
global consensus for the vast majority of transactions (nested consensus =
or off-chain direct party-to-party contract negotiation, the lightning =
network, etc. The focus on reducing fee pressure by increasing block =
size is a distraction from far more fundamental issues, IMHO.</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"></div></div></div></blockquote><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"><div =
class=3D"">&nbsp;</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><p dir=3D"ltr" class=3D"">So to point out =
what I consider obvious: if Bitcoin requires central control over its =
rules by a group of developers, it is completely uninteresting to me. =
Consensus changes should be done using consensus, and the default in =
case of controversy is no change.</p></blockquote><div class=3D""><br =
class=3D""></div><div class=3D"">False.</div><div class=3D""><br =
class=3D""></div><div class=3D"">All that has to do be done to change =
bitcoin to a new economic policy - not seen in the entire 6 year history =
of bitcoin - is to stonewall work on block size.</div><div class=3D""><br =
class=3D""></div><div class=3D"">Closing size increase PRs and failing =
to participate in planning for a block size increase accomplishes your =
stated goal of changing bitcoin to a new economic policy.</div><div =
class=3D""><br =
class=3D""></div></div></div></div></div></blockquote><div><br =
class=3D""></div><div>Wrong - the economic policy of bitcoin has always =
been, from the beginning, to subsidize blocks initially and transition =
to fees. Artificially continuing to rely on block reward subsidies is =
what is a new economic policy. We=E2=80=99re already six years in, =
pretty soon another halving is coming - how long are we going to wait to =
start transitioning? The lower block reward subsidies are, the more pain =
fee pressures will cause.</div><div><br class=3D""></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"><div class=3D"">"no [code] change"... changes =
bitcoin to a brand new economic policy, picking economic winners &amp; =
losers.&nbsp; Some businesses will be priced out of bitcoin, =
etc.</div><div class=3D""><br class=3D""></div><div =
class=3D"">Stonewalling size increase changes is just as much as a Ben =
Bernanke/FOMC move as increasing the hard limit by hard fork.</div><div =
class=3D""><br class=3D""></div><div class=3D"">&nbsp;</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><p dir=3D"ltr" class=3D"">My personal =
opinion is that we - as a community - should indeed let a fee market =
develop, and rather sooner than later, and that "kicking the can down =
the road" is an incredibly dangerous precedent: if we are willing to go =
through the risk of a hard fork because of a fear of change of =
economics, then I believe that community is not ready to deal with =
change at all. And some change is inevitable, at any block size. Again, =
this does not mean the block size needs to be fixed forever, but its =
intent should be growing with the evolution of technology, not a panic =
reaction because a fear of change.<br class=3D""></p><p dir=3D"ltr" =
class=3D"">But I am not in any position to force this view. I only hope =
that people don't think a fear of economic change is reason to give up =
consensus.</p></blockquote><div class=3D""><br class=3D""></div><div =
class=3D"">Actually you are.</div><div class=3D""><br =
class=3D""></div><div class=3D"">When size increase progress gets frozen =
out of Bitcoin Core, that just <i class=3D"">increases</i>&nbsp;the =
chances that progress must be made through a contentious hard =
fork.</div><div class=3D""><br class=3D""></div><div class=3D"">Further, =
it increases the market disruption users will experience, as described =
above.</div><div class=3D""><br class=3D""></div><div class=3D"">Think =
about the users.&nbsp; Please.</div><div class=3D""><br =
class=3D""></div></div></div></div></div></blockquote><div><br =
class=3D""></div><div>I think about the billions of people out there in =
the world that could be using this technology that simply have no access =
to it right now. The majority or them which are unbanked, =
etc=E2=80=A6</div><div><br class=3D""></div><div>More the reason to go =
through the steps needed while we=E2=80=99re still small to correct the =
core issues.</div><br class=3D""><blockquote type=3D"cite" class=3D""><div=
 class=3D""><div dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><br =
class=3D""></div></div>
_______________________________________________<br class=3D"">bitcoin-dev =
mailing list<br class=3D""><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
br class=3D""></div></blockquote></div><br class=3D""></body></html>=

--Apple-Mail=_9E02F14E-0A66-4E19-8AA3-11D40A49CEA5--

--Apple-Mail=_02174A37-04FB-4D42-8176-339E93D1AE0C
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

iQIcBAEBCgAGBQJVr+xYAAoJEJNAI64YFENUlSIP/0hb1bq4BlWOu2DAAZNlgY1u
l6TPlrU/R0zwTuuGSEc6aCgYHb26NJS4i/JmOT+fFsZG9cBckXEZ6mwmxskadi0j
Tk8iZEJqjqg1uCPtUAF3X/rgVJWJj4vMGe7cazZjmHOxNG2zOH8OmSM/navET0HN
1cna2rpKSXoyyt0CqIcsvf8jFcd2By7NhfCQfjEHKExImETJC84Tqyh+7/7eykzn
Vu1nbScuSeEorLsJI0C6OaA0HdHgJtpj8UW4oMjjKcEQZrSZgDglwwd7ihRrWSWR
dJkfeOvCRVBnZ99wxUhLuefyGFcM5gJ/P4nkWjAp9Fs405GWdqpj5BqJpVk5tCWj
ZIU9ZczIlBIxmOVW3wz/mlghwjaXu1cBc4PwTYojEh7R6HS8jcfzJkNUIa1h7FM5
czuNQdfiRlLXD8lXFw9ijBph921zSr08ozMlRaWNTGy/7DY0PgGvgl4mOrK00tMw
g+Z20bW7SGFJGP4bvKfdhV4dcJcZWa1gMNNCdCi0hFjGp6mHGdN2fTN3GX8aN+8C
CsMUyIrJc5SGketWQ/6u+HKy9VAaXhqd6dt0u+peo+BspEgqLChtcxeAE09hbXL0
llffSpriKtThcsgK7cM3tuZzlrcSenrvhlq12LbWZ939oeqpcTccVLnRFOlVoEom
ZkK+bDbCQ3zEd40SYmyC
=GUxJ
-----END PGP SIGNATURE-----

--Apple-Mail=_02174A37-04FB-4D42-8176-339E93D1AE0C--