summaryrefslogtreecommitdiff
path: root/76/18cc7146425b29a388dcff5ff443e064a34b08
blob: 859f598aec172604054635c782902e2d7725b48f (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
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 864C5FF
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Jul 2015 08:21:07 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com
	[209.85.192.178])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 668A98D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Jul 2015 08:21:06 +0000 (UTC)
Received: by pdbnt7 with SMTP id nt7so20684037pdb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Jul 2015 01:21:06 -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=i2qtKS/f1iggfje5rccLIhcEv4t7sp8IqYPM0kzm5Ho=;
	b=kwInZRcO3cq+lEI2+r1UehNP69nFNZZFz3DA7zJIgqBXSARzvZNgoEJDHxR5cdBBBq
	YLEA7UKpNBiEFUIMLzoDw6GPDq0xDa1uXCE0iLdItPh9kCys2+qI8+z0uBhARMkbq+WO
	6u5Xyui71wAwU3zJMZD86Wfoi3nGJHQqsmkANQ+osENt+6Pgv2O2f7j8g7ocTvOO+yCn
	VGYE7a6tJ6vcLTGP2fG5J+msxbkd7rBz/AyVNxpxOiNdeByqwpjDjWZLezbl9CP9M3Cm
	D+16I22mX8d9yiQqnWw7f5SnnvLILujb8JP7VMdJwjLKk0JEPwikrgxtm7gIGJih0Hcg
	RshA==
X-Received: by 10.70.103.98 with SMTP id fv2mr83164518pdb.9.1438244466117;
	Thu, 30 Jul 2015 01:21:06 -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 v3sm755654pdp.8.2015.07.30.01.21.03
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Thu, 30 Jul 2015 01:21:04 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_92CCBEA4-6237-4C46-9A6B-65935BBCC262";
	protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5
From: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <CAEX2NSc6FXsDLEpRq7YOxQErpBxS7tW8Afk-T9VUyeb2qS2brQ@mail.gmail.com>
Date: Thu, 30 Jul 2015 01:21:02 -0700
Message-Id: <74767203-7F7A-4848-9923-DE1DE60A28B4@gmail.com>
References: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com>
	<CA+w+GKTfPXkVPaCC+3ZsQv=_DPMHoRwbigS40Testpyq4rZxsw@mail.gmail.com>
	<D25BD175-7099-4A6B-89BB-A35E94F555A9@gmail.com>
	<CA+w+GKTZV5sgXNU_xoBby1_X6eae=5_vhENmyKY0yxWHcBiU5g@mail.gmail.com>
	<37D282C2-EF9C-4B8B-91E8-7D613B381824@phauna.org>
	<CAAS2fgSaRqxi3X0J3F05nA-tyRRikY1whkpAOuGJJpFSAR017w@mail.gmail.com>
	<COL131-DS222F0D512C6A5B47BF62C2CD8C0@phx.gbl>
	<55B94FAD.7040205@mail.bihthai.net>
	<COL131-DS95F86B1D5B93CE1275911CD8C0@phx.gbl>
	<CALqxMTEUAtNxkYMQwA9g9xH_LiX98yYOooGjUho1T3fMY2J5jQ@mail.gmail.com>
	<CAEX2NSc6FXsDLEpRq7YOxQErpBxS7tW8Afk-T9VUyeb2qS2brQ@mail.gmail.com>
To: Andrew LeCody <andrewlecody@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,
	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 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't
	temporary
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: Thu, 30 Jul 2015 08:21:07 -0000


--Apple-Mail=_92CCBEA4-6237-4C46-9A6B-65935BBCC262
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I usually avoid troll-infested Dunning-Kruger-gone-wild fests like =
reddit, so I=E2=80=99ll leave that to others.

But I do want to clarify a couple things here, though, Andrew.

First of all, the issue is not about whether it is affordable for a =
highly motivated, technically skilled person to continue running a node =
even if we increase block size by a factor of X. This misses the point =
for at least a couple reasons:

- Regardless of what that X is, it isn=E2=80=99t really going to be what =
makes this technology accessible to the masses. We would likely need the =
X to be in the thousands before we start to really take on players like =
Visa. Despite what people might have thought in 2009, it turns out =
Bitcoin is probably pretty ill-suited as a database in which to store =
the entire transaction history of the entire world. It=E2=80=99s looking =
to be more of a censorship-resistant dispute resolution mechanism that =
provides very well-defined settlement guarantees with the potential for =
encoding complex rules. It=E2=80=99s possible to build higher level =
tiers on top of it that DO support high volume transaction processing =
WITHOUT costing thousands of times more, and these approaches are =
looking quite promising. However, it doesn=E2=80=99t seem very many =
people in this space quite grasp this paradigm shift yet.

- What matters is not how a relatively small number of well-intentioned =
people in the network behave. What matters is how the network behaves as =
a whole=E2=80=A6and a number of the people most intimately familiar with =
the inner workings of the system (some of whom are in this thread) think =
that given what we now today about the Bitcoin network, increasing block =
size externalizes costs in dangerous ways. Remember that total cost =
includes not just equipment costs but also things like block propagation =
latency and specifically identified security risks. Some of these =
security risks were only appreciated relatively recently and were =
completely unknown in 2009.


> On Jul 29, 2015, at 9:51 PM, Andrew LeCody via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> tl;dr
> $100 worth of hardware and $1/mo of expenses, should be able to run a =
full
> Bitcoin node until 2020 with BIP101-size blocks.
>=20
> ----
>=20
> I got into Bitcoin in the summer of 2010. I'm not a cryptographer, up =
until
> recently my profession has been as a server administrator or systems
> engineer.
>=20
> I'd like to take a second to address the concern that larger blocks =
would
> make it harder to run a full node on limited hardware and would =
therefore
> hurt decentralization. I run two nodes today, one on server-grade =
hardware
> at a datacenter and another on a mini-ITX Atom (dual core) system at =
my
> home.
>=20
> I detailed the operational costs of my home node today on reddit:
> =
https://www.reddit.com/r/Bitcoin/comments/3f0h8e/mike_h_shuts_down_eric_ls=
_attempt_to_rewrite/ctkigpr
>=20
> If I was a new user, wanting to run a full node. The most cost =
effective
> way would likely be with a Raspberry Pi 2 and a 2TB external HDD. =
Total
> cost about $100, including charger, microSD card, etc. That is less =
than
> the cost of a TREZOR hardware wallet. As far as home projects go, not
> terribly expensive.
>=20
> Next, it will need power. According to the Wikipedia article, the rpi =
2
> model B uses 3.5 watts of power max. The 2TB external drive will draw =
about
> 5 watts at max. That's a total of 8.5 watts or 6.205 Kwh per month. In =
my
> area (North Texas) power is about $0.10/Kwh, which means my little =
node
> costs $0.62 per month in power.
>=20
> Last, lets look at bandwidth. It's difficult to quantify bandwidth =
cost in
> the same way because this is a home connection, mainly because I don't =
know
> how to price in the loss of enjoyment if the system impacts my =
Internet
> usage to a noticeable degree. Luckily, I have some real world data =
from my
> existing home node. Here is the last month:
> http://imgur.com/YmJwQpN
>=20
> This system averages 120 Kbps in and 544 Kbps out. Note, this data is
> somewhat skewed, because the system is also used for seeding torrents =
of
> various open source projects. The Bitcoin node itself is typically
> connected to about 20 peers at any given time (maxconnections=3D20).
>=20
> Subjectively, my wife and I have never noticed any degradation of
> performance due to my home server using too much bandwidth. I think =
it's
> safe to say that I can treat the bandwidth is uses as effectively =
free,
> since it's piggybacking on a connection I would be paying for even if =
I was
> not running a Bitcoin node. The bandwidth usage of this Bitcoin node =
could
> increase significantly, without any noticeable impact. If it did, I =
could
> always lower maxconnections back to 8.
>=20
> The only real constraint seems to be hard drive space, as the full
> blockchain and indexes take up about 50GB of space currently. If =
BIP101 is
> implemented, 2TB of storage should be enough for me to continue =
running my
> hypothetical $100 node until about 2020.
>=20
> It seems to me that at least for the next 5 years, the "small devices" =
of
> today can easily run Bitcoin nodes with BIP101-size blocks, with very
> little operational cost.
>=20
> If anyone would like more detailed data on my existing nodes, please =
let me
> know and I'll attempt to provide it (so long as it doesn't impact my
> privacy of course).
>=20
> On Wed, Jul 29, 2015 at 10:49 PM Adam Back via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
>> I dont think people consider other blockchains as a competitive
>> threat.  A PoW-blockchain is a largely singleton data structure for
>> security reasons (single highest hashrate), it is hard for an
>> alternative chain to bootstrap or provide meaningful security.
>> Secondly the world largely lacks expertise to maintain a blockchain =
to
>> bitcoin's security level, perhaps you can see a hint of this in the
>> recently disclosed security vulnerability by Pieter Wuille and =
Gregory
>> Maxwell.  Calls to this as an argument are not resonating and =
probably
>> not helping your argument.  Bitcoin has security properties, and a
>> competing system cant achieve better properties by bypassing =
security,
>> any blockchain faces the same fundamental security / decentralisation
>> limitations.
>>=20
>> Secondly Bitcoin can obviously compete with itself with different
>> parameters and defacto *does* today.  I think it is a safe estimate
>> that > 99% of Bitcoin transactions right now are happening in Bitcoin
>> related systems with various degrees of audit, reconciliation,
>> provable reserves etc.  I think we can expect this to continue and
>> become more secure via more reconciliation, and longer term via
>> lightning or Bitcoin sidechains with different parameters.  It is a
>> different story to have a single central system (Bitcoin with
>> parameters changed to the point of centralisation failure) vs having
>> multiple choices, because some transactions can more easily use
>> relatively centralised systems (eg micropayments), and more
>> interestingly the combination of a secure and decentralised layer 1
>> plus choices of less decentralised layer 2 options, can be =
interesting
>> because the layer 2 is provided cover from attack.  There is less to
>> be gained by attacking relatively centralised layer 2 because any
>> payments at risk of policy abuse (which is typically a small subset)
>> can easily switch to layer 1.  That in itself makes layer 2
>> transactions also less susceptible to policy abuse.  Further =
lightning
>> it appears from work so far should add significant scale while
>> retaining trustlessness and a good degree of decentralisation.
>>=20
>> Finally you seem to be focusing on "artificial" limits where that is
>> not the issue under consideration.  The limits are technical and
>> relating to decentralisation and security.  I wont go over them again
>> as this topic has been covered many times in recent months.  Any =
chain
>> that tried to go to extreme parameters (very low block intervals, or
>> very large blocksizes) would have the same decentralisation problems
>> as Bitcoin would if it did the same thing.  There are a number of alt
>> coins that have failed as a result of poor parameter choices, there
>> are inherent security limits.
>>=20
>> Adam
>>=20
>> ps Etiquette note for yourself and others: please dont be repetitive
>> or attempt to be forceful.  Many people have spent many years
>> understanding this very complex system, from my own experience it is
>> rare indeed to think of an entirely new concept or analysis, that
>> hasnt' been long considered and put to bed 3 or 4 years ago.
>> Thoughtful polite and constructive comments are welcome but I
>> recommend to not start from an assumption that you have a clear and
>> better insight than the entire technical community, because I have to
>> say from my own experience that is very rarely the case.  It can be
>> useful to test theories on #bitcoin IRC channel to find out what has
>> been already concluded, find the references and avoid having to have
>> that hashed out on this list which is trying to be focussed on
>> technical solutions.
>>=20
>>=20
>> On 29 July 2015 at 16:10, Raystonn . via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>> Cheapest way to send value? Is this what Bitcoin is trying to do? =
So
>>>> all of the smart contract, programmable money, consensus coding and
>>>> tremendous developer effort is bent to the consumer demand for =
cheaper
>>>> fees. Surely thou jests!
>>>=20
>>>=20
>>> These other features can be replicated into any alternative =
blockchain,
>>> including those with lower fees.  In the open-source world of
>>> cryptocurrency, no feature will remain a value-add for very long =
after it
>>> has been identified to be such.  Anything adding value will quickly =
be
>>> absorbed into competing alternative blockchains.  That will leave
>> economic
>>> policy as the distinguishing factor.
>>>=20
>>>> ... it is not the case ... that reluctance to concede
>>>> blocksize is an attempt to constrain capacity. Greg Maxwell =
thoroughly
>>>> explained in this thread that the protocol's current state of
>>>> development relies on  blocksize for security and, ultimately, as a
>>>> means of protecting its degree of decentralization.
>>>=20
>>>=20
>>> A slow or lack of increase to maximum transaction rate will cause
>> pressure
>>> on fees.  Whether this is the desired goal is not relevant.  =
Everyone has
>>> agreed this will be the outcome.  As to a smaller block size being =
needed
>>> for additional decentralization, one must simply ask how much we are =
all
>>> willing to pay for that additional decentralization.  It is likely =
that
>> the
>>> benefit thereto will have to be demonstrated by some power attacking =
and
>>> destroying a less decentralized currency before the benefit of this
>> feature
>>> is given monetary value by the market.  Until then, value will bleed =
to
>> the
>>> network with the least friction, because it will have the greatest
>> ability
>>> to grow its network effect.  That means the blockchain with adequate
>>> features and cheapest fees will eventually have the largest market =
share.
>>>=20
>>>=20
>>> -----Original Message----- From: Venzen Khaosan
>>> Sent: Wednesday, July 29, 2015 3:11 PM
>>> To: Raystonn .
>>> Cc: bitcoin-dev@lists.linuxfoundation.org
>>> Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure
>>> isn'ttemporary
>>>=20
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>=20
>>> Raystonn, I'm aware that you're addressing your question to Greg
>>> Maxwell, however a point you keep stating as fact calls for =
reference:
>>>=20
>>> On 07/30/2015 04:28 AM, Raystonn . via bitcoin-dev wrote:
>>> [snip]
>>>>=20
>>>> How do you plan to address the bleeding of value from Bitcoin to
>>>> alternative lower-fee blockchains created by the artificially-high
>>>> bitcoin transaction fees when users begin looking for the cheapest
>>>> way to send value?
>>>=20
>>> Cheapest way to send value? Is this what Bitcoin is trying to do? So
>>> all of the smart contract, programmable money, consensus coding and
>>> tremendous developer effort is bent to the consumer demand for =
cheaper
>>> fees. Surely thou jests!
>>>=20
>>>> Modern economic study has shown that liquidity moves to the
>>>> location of least friction.
>>>=20
>>> Modern economic study? Can you please provide a link or reference to
>>> the study you are referring to.
>>>=20
>>> "liquidity moves to the location of least friction"
>>>=20
>>> This sounds like "econo-speak" and makes no sense. The definition of
>>> Liquidity is the degree to which an asset/security can be bought or
>>> sold in the market without affecting the price.
>>>=20
>>> That is why bitcoin is said to have low liquidity: buying or selling
>>> only 100 BTC visibly affects the exchange price. You probably mean
>>> "people like cheap fees", which is true, but as others have said,
>>> because of Bitcoin's powerful features, they are willing to pay =
higher
>>> fees and wait longer for transactions to execute.
>>>=20
>>> As for your public cross-examination of Greg Maxwell, your case =
seems
>>> to  be made on the assumption that limiting the size of the =
blockchain
>>> is an attempt to artificially raise tx fees, but it is not the case
>>> (as you and others repeatedly argue) that reluctance to concede
>>> blocksize is an attempt to constrain capacity. Greg Maxwell =
thoroughly
>>> explained in this thread that the protocol's current state of
>>> development relies on  blocksize for security and, ultimately, as a
>>> means of protecting its degree of decentralization.
>>>=20
>>> Surely, this is an obvious concern even for those who are =
campaigning
>>> for the hare-brained ideal of making Bitcoin a "faster, cheaper
>>> alternative" to visa or paypal? If we lose decentralization, we lose
>>> the whole thing, right? Incorrect or correct?
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1
>>>=20
>>> iQEcBAEBAgAGBQJVuU+rAAoJEGwAhlQc8H1m9nkH/00xXJ53H4qvHjPrdNRniwvB
>>> RXi96QjbnVj/fxU2J2TBPYF1LxJ13avyL58bbaJF7GKqcpoYNZArCKLQyGaZGCTp
>>> h7Oe/0S+b1QCrvxcVK8Ikeb7a1h9wnhAPf1FvAWoJ1cFGx/qGHetKqx1dQTWkVWz
>>> Mp17vjaofmp2OhBzh0Smj+wV9hXn9w9giZKc6UGvC0Qc7Rf3GL/YVJzM2CZNvlLS
>>> YhQSqnnqduugYztqLV/NvNExF41zC2IMyNmA41q46v/nh8stNSIcJleD39csNMfx
>>> BXjrlnPfZ+JI4RhiH3I0qjOYWPtBH9od788DY509EOn3MT4vU+EVcQaxyuFqZyw=3D
>>> =3DlQvy
>>> -----END PGP SIGNATURE-----
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--Apple-Mail=_92CCBEA4-6237-4C46-9A6B-65935BBCC262
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

iQIcBAEBCgAGBQJVud5uAAoJEJNAI64YFENUz/cQALrf9GmKH3pHTc8nLfqYxlNq
I2fnHEbVp7MdbXj0gLITBfXbajghrSNTeLaIVkV0h9wiRytUdIBEh/6nHtoMo4GL
0qlHuteapyeXYKyy2cWUw4GTEcNGM2X4AcBJzyj6h7ouJw+OaiXmTxe1ArrXZfea
9Rx63RBbXLeYY3w2lqw+JA/hmPnEr60IJhCYuXjq5MPGjK0+ms6MeryLj14aC1ut
LxXVBCEUOAv4WziCrNl4Co6QOLY+GFlXV0GoOmF1cY1xJiX/gd2suLZs1bJFsGyR
6VdXfTX7ccYxwebGjI3cBfo6zNAPWIfS9XgO5g1QwlEtrX1Y4NnT9hOO1KwfvENi
/5IGOWZKtm1aYS00CgQClhTyQ4cs9esI032gN6G4Wj4QmtjbtLdH1QEMl+VGoXcg
NT73fCDEvnSJVJGL7OosVIKOGZlgywfDnY1P6LbOzpnIK1n0EPSxxZXmshxsPoD8
9VxesunM6mX8zZInNayW+YATLBKYV0VvCJKc81qisOtqBCzGBgzjt9zh6RaoSUHh
X5+7L6pLhAKatDNyM11mAS+Yvw7QKcic7qfs1FBxYdZ3VWMw1p8WEssqmzvDG9XT
w4nkphYBkIcfw9zDUx3aWCqDJzyeRlRA48/gSTGlzl0UsTHT3U80kuCGV6xLKjAt
yTUH24tuy9Wx7ZZ/iW6z
=zED1
-----END PGP SIGNATURE-----

--Apple-Mail=_92CCBEA4-6237-4C46-9A6B-65935BBCC262--