path: root/51/97786897278896e125fa18a9d74180b5544bfc

Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1W3ZJF-0000Fv-5p
	for bitcoin-development@lists.sourceforge.net;
	Wed, 15 Jan 2014 22:51:41 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.173 as permitted sender)
	client-ip=209.85.215.173; envelope-from=mh.in.england@gmail.com;
	helo=mail-ea0-f173.google.com; 
Received: from mail-ea0-f173.google.com ([209.85.215.173])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1W3ZJD-0005aO-9h
	for bitcoin-development@lists.sourceforge.net;
	Wed, 15 Jan 2014 22:51:41 +0000
Received: by mail-ea0-f173.google.com with SMTP id o10so766059eaj.32
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 15 Jan 2014 14:51:33 -0800 (PST)
X-Received: by 10.15.35.194 with SMTP id g42mr7209805eev.20.1389826292927;
	Wed, 15 Jan 2014 14:51:32 -0800 (PST)
Received: from [192.168.1.102] (84-75-251-165.dclient.hispeed.ch.
	[84.75.251.165]) by mx.google.com with ESMTPSA id
	o13sm13834518eex.19.2014.01.15.14.51.30
	for <bitcoin-development@lists.sourceforge.net>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 15 Jan 2014 14:51:31 -0800 (PST)
Sender: Mike Hearn <mh.in.england@gmail.com>
From: Mike Hearn <mike@plan99.net>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_01340681-1782-4989-AAD7-C6ECAB5C893C";
	protocol="application/pkcs7-signature"; micalg=sha1
Message-Id: <5747D5DF-879B-4A60-8BD6-18251E7D5F47@plan99.net>
Date: Wed, 15 Jan 2014 23:51:21 +0100
To: bitcoin-development@lists.sourceforge.net
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
X-Mailer: Apple Mail (2.1827)
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(mh.in.england[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1W3ZJD-0005aO-9h
Subject: [Bitcoin-development] Tor / SPV
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2014 22:51:41 -0000


--Apple-Mail=_01340681-1782-4989-AAD7-C6ECAB5C893C
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_00AA894D-AF71-4024-B559-552757363EB1"


--Apple-Mail=_00AA894D-AF71-4024-B559-552757363EB1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

intro text starts here, protocol upgrade proposal starts further down

Recently on IRC we have discussed what it'd take to use SSL on P2P =
connections, the goal being encryption and authentication of traffic to =
help avoid passive wiretapping and sybil attacks.

Gregory pointed out - very reasonably - that OpenSSL is huge and very =
old-school C, meaning that using it to implement SSL would put a big =
piece of code exposed to the internet into the same process as people=92s =
wallets. This would be not excellent. Also, even with encryption, with =
SSL you only get some resistance to traffic analysis. And it'd be a =
complicated upgrade.

Tor is an option, but it has other disadvantages:

1) Also a giant piece of C that is likely to contain bugs
2) Breaks our anti-sybil heuristics when connecting to hidden services
3) MITM very likely when not connecting to hidden services
4) Is not usable as a library at all. Convention to use Tor is "tell =
user to start TorBrowser and connect to the SOCKS port".

The latter point means in reality hardly anyone will ever connect via =
Tor, as you'd have to do extra setup and most people are lazy. =
Especially it's not going to work on mobile. It=92s not worth doing =
something complicated if hardly anyone would use it.

But recently I discovered this interesting piece of code:

   http://www.subgraph.com/orchid.html

It is a pure Java implementation of the Tor protocol (client only, no =
relays), easily usable as a library. Sure enough after about an hour of =
fiddling around, I now have a bitcoinj that connects via Tor with no =
other software running.

Suddenly making MultiBit, the Android Bitcoin Wallet app, Hive and other =
bitcoinj based wallets use Tor by default seems very plausible.

So I started thinking about what it'd take to switch this on for =
everyone. The biggest problem is that SPV wallets can't verify =
unconfirmed/pending transactions for themselves, so they rely on =
counting the number of peers that announced it and assuming that their =
internet connections aren't being tampered with. Mostly this assumption =
is a good one - we have never heard anyone report that they were paid =
with a fake pending tx using a MITM attack.

However, with Tor the chance of being MITMd goes up dramatically. Lots =
of people have reported exit nodes that are doing SSL stripping. Being =
sybilled when using exit nodes seems rather likely.

Connecting to hidden services solve the MITM problem but screws you in a =
different way. Bitcoin Core has some weak heuristics in the code to try =
and ensure we don=92t accidentally connect to nodes all controlled by =
the same guys =85 mostly by trying to keep a good mix of /16s. This is =
probably not very hard to defeat, but it does at least raise the bar =
beyond =93buy lots of amazon VMs=94. With hidden services we lose that. =
Also, there aren=92t very many nodes running as hidden services - if all =
bitcoinjs started hitting them simultaneously they=92d probably die.

tl;dr the proposal starts here

Let=92s fix this so SPV wallets can use Tor by default. Downgrading =
things is not an option, it must be pure upgrade. We can do it like =
this:

1) Firstly, we observe that MITM only matters when we=92re trying to =
count pending transaction announcements, but most of the load SPV =
wallets impose on the network is chain filtering. So it=92s OK to =
download the chain from any arbitrary clearnet IP via Tor because we=92re =
checking Merkle branches.  This ensures we won=92t put excessive load on =
hidden service nodes.

2) Secondly, we bump the protocol version, add a service flag and =
introduce a new P2P protocol command =93tor?=94. If a client sends a =
tor? message to a node that has the new service flag set, it will =
respond with a new =93tor=94 message that contains a regular addr =
packet, with a single address, the IPv6-ified version of its hidden =
service name.

3) SPV wallets that want to get a good mix of nodes for measuring =
pending transactions identify nodes on the clearnet via their addr =
announcements+service flag, in the normal way. They select some of these =
nodes using the standard clearnet anti-sybil heuristics and connect =
without using Tor. They proceed to query them for their hidden service =
key. After they=92ve done that, they record the public IP->hidden =
service mapping and can go ahead and connect back to them at any later =
time via Tor itself.

This would seem to be pointless - did we not just go ahead and bypass =
Tor entirely, thus making neither node hidden? Is it not a dead cert =
that the next connection the node gets via Tor is likely the same =
computer? Yes, but it only matters the first time. As long as those =
nodes are somewhat stable the mapping will be recorded on disk and the =
next time the wallet starts, it=92ll skip straight to using Tor.

The goal of all that is that we get to keep our existing IPv4 based =
anti-sybil heuristics, so we can=92t possibly make anything worse, only =
better. Plus, we=92ve now set things up so in future if/when we come up =
with a better anti-sybil system based on anonymous identities or other =
fancy crypto, we can take out the =93connect via clearnet=94 step and go =
straight to using hidden services with only a very small set of code =
changes and no new protocol work.

I like this idea for several reasons:

It feels implementable to me in about a couple of weeks wall-time. The =
tasks are small - the new tor? p2p message is super easy to implement =
because a node already knows if it=92s a hidden service or not. On the =
bitcoinj side, it=92d take a bit of work to implement the extra storage =
of IPv4->onion mappings and ensure the right kind of connection is used =
at the right time, but it=92s not all that hard.
We could switch Tor on by default for a lot of users.
On the bitcoind side, Tor runs as a separate process and because it =
initiates connections to bitcoind, it can be easily sandboxed, e.g. ran =
as a different UNIX user or even run inside a chroot/ptrace jail. Even =
though Tor is likely to contain exploits, we can easily keep them away =
from the wallet. So there=92s not much additional surface area.
Obviously as it=92s pure Java and client only, Orchid is immune to =
buffer overflows/double frees and other such security problems.
It=92s optional for all parties. Wallet clients can try to fall back to =
non-Tor usage if their access to Tor seems to be blocked somehow.
Tor is the gold standard for resisting traffic analysis - we know thanks =
to Snowden that it=92s good at this task.

To launch I=92d probably have a percentage throttle hosted on some SSLd =
website, so we can control the load placed on the existing hidden =
service nodes.

Feedback welcome.







--Apple-Mail=_00AA894D-AF71-4024-B559-552757363EB1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><div><font color=3D"#222222" face=3D"arial" =
size=3D"2"><b>intro text starts here, protocol upgrade proposal starts =
further down</b></font></div><span style=3D"color: rgb(34, 34, 34); =
font-family: arial; font-size: small; background-color: rgb(255, 255, =
255);"><div><span style=3D"color: rgb(34, 34, 34); font-family: arial; =
font-size: small; background-color: rgb(255, 255, =
255);"><br></span></div>Recently on IRC we have discussed what it'd take =
to use SSL on P2P connections, the goal being encryption and =
authentication of traffic to help avoid passive wiretapping and sybil =
attacks.</span><div style=3D"color: rgb(34, 34, 34); font-family: arial; =
font-size: small;"><br></div><div style=3D"color: rgb(34, 34, 34); =
font-family: arial; font-size: small;">Gregory pointed out - very =
reasonably - that OpenSSL is huge and very old-school C, meaning that =
using it to implement SSL would put a big piece of code exposed to the =
internet into the same process as people=92s wallets. This would be not =
excellent. Also, even with encryption, with SSL you only get some =
resistance to traffic analysis. And it'd be a complicated =
upgrade.</div><div style=3D"color: rgb(34, 34, 34); font-family: arial; =
font-size: small;"><br></div><div style=3D"color: rgb(34, 34, 34); =
font-family: arial; font-size: small;">Tor is an option, but it has =
other disadvantages:</div><div style=3D"color: rgb(34, 34, 34); =
font-family: arial; font-size: small;"><br></div><div style=3D"color: =
rgb(34, 34, 34); font-family: arial; font-size: small;">1) Also a giant =
piece of C that is likely to contain bugs</div><div style=3D"color: =
rgb(34, 34, 34); font-family: arial; font-size: small;">2) Breaks our =
anti-sybil heuristics when connecting to hidden services</div><div =
style=3D"color: rgb(34, 34, 34); font-family: arial; font-size: =
small;">3) MITM very likely when not connecting to hidden =
services</div><div style=3D"color: rgb(34, 34, 34); font-family: arial; =
font-size: small;">4) Is not usable as a library at all. Convention to =
use Tor is "tell user to start TorBrowser and connect to the SOCKS =
port".</div><div style=3D"color: rgb(34, 34, 34); font-family: arial; =
font-size: small;"><br></div><div style=3D"color: rgb(34, 34, 34); =
font-family: arial; font-size: small;">The latter point means in reality =
hardly anyone will ever connect via Tor, as you'd have to do extra setup =
and most people are lazy. Especially it's not going to work on mobile. =
It=92s not worth doing something complicated if hardly anyone would use =
it.</div><div style=3D"color: rgb(34, 34, 34); font-family: arial; =
font-size: small;"><br></div><div style=3D"color: rgb(34, 34, 34); =
font-family: arial; font-size: small;">But recently I discovered this =
interesting piece of code:</div><div style=3D"color: rgb(34, 34, 34); =
font-family: arial; font-size: small;"><br></div><div style=3D"color: =
rgb(34, 34, 34); font-family: arial; font-size: small;">&nbsp; &nbsp;<a =
href=3D"http://www.subgraph.com/orchid.html">http://www.subgraph.com/orchi=
d.html</a><br></div><div style=3D"color: rgb(34, 34, 34); font-family: =
arial; font-size: small;"><br></div><div style=3D"color: rgb(34, 34, =
34); font-family: arial; font-size: small;">It is a pure Java =
implementation of the Tor protocol (client only, no relays), easily =
usable as a library. Sure enough after about an hour of fiddling around, =
I now have a bitcoinj that connects via Tor with no other software =
running.</div><div style=3D"color: rgb(34, 34, 34); font-family: arial; =
font-size: small;"><br></div><div style=3D"color: rgb(34, 34, 34); =
font-family: arial; font-size: small;">Suddenly making MultiBit, the =
Android Bitcoin Wallet app, Hive and other bitcoinj based wallets use =
Tor by default seems very plausible.</div><div style=3D"color: rgb(34, =
34, 34); font-family: arial; font-size: small;"><br></div><div =
style=3D"color: rgb(34, 34, 34); font-family: arial; font-size: =
small;">So I started thinking about what it'd take to switch this on for =
everyone. The biggest problem is that SPV wallets can't verify =
unconfirmed/pending transactions for themselves, so they rely on =
counting the number of peers that announced it and assuming that their =
internet connections aren't being tampered with. Mostly this assumption =
is a good one - we have never heard anyone report that they were paid =
with a fake pending tx using a MITM attack.</div><div style=3D"color: =
rgb(34, 34, 34); font-family: arial; font-size: small;"><br></div><div =
style=3D"color: rgb(34, 34, 34); font-family: arial; font-size: =
small;">However, with Tor the chance of being MITMd goes up =
dramatically. Lots of people have reported exit nodes that are doing SSL =
stripping. Being sybilled when using exit nodes seems rather =
likely.</div><div style=3D"color: rgb(34, 34, 34); font-family: arial; =
font-size: small;"><br></div><div style=3D"color: rgb(34, 34, 34); =
font-family: arial; font-size: small;">Connecting to hidden services =
solve the MITM problem but screws you in a different way. Bitcoin Core =
has some weak heuristics in the code to try and ensure we don=92t =
accidentally connect to nodes all controlled by the same guys =85 mostly =
by trying to keep a good mix of /16s. This is probably not very hard to =
defeat, but it does at least raise the bar beyond =93buy lots of amazon =
VMs=94. With hidden services we lose that. Also, there aren=92t very =
many nodes running as hidden services - if all bitcoinjs started hitting =
them simultaneously they=92d probably die.</div><div style=3D"color: =
rgb(34, 34, 34); font-family: arial; font-size: small;"><br></div><div =
style=3D"color: rgb(34, 34, 34); font-family: arial; font-size: =
small;"><b>tl;dr the proposal starts here</b></div><div style=3D"color: =
rgb(34, 34, 34); font-family: arial; font-size: =
small;"><b><br></b></div><div style=3D"color: rgb(34, 34, 34); =
font-family: arial; font-size: small;">Let=92s fix this so SPV wallets =
can use Tor by default. Downgrading things is not an option, it must be =
pure upgrade. We can do it like this:</div><div style=3D"color: rgb(34, =
34, 34); font-family: arial; font-size: small;"><br></div><div =
style=3D"color: rgb(34, 34, 34); font-family: arial; font-size: =
small;">1) Firstly, we observe that MITM only matters when we=92re =
trying to count pending transaction announcements, but most of the load =
SPV wallets impose on the network is chain filtering. So it=92s OK to =
download the chain from any arbitrary clearnet IP via Tor because we=92re =
checking Merkle branches. &nbsp;This ensures we won=92t put excessive =
load on hidden service nodes.</div><div style=3D"color: rgb(34, 34, 34); =
font-family: arial; font-size: small;"><br></div><div style=3D"color: =
rgb(34, 34, 34); font-family: arial; font-size: small;">2) Secondly, we =
bump the protocol version, add a service flag and introduce a new P2P =
protocol command =93tor?=94. If a client sends a tor? message to a node =
that has the new service flag set, it will respond with a new =93tor=94 =
message that contains a regular addr packet, with a single address, the =
IPv6-ified version of its hidden service name.</div><div style=3D"color: =
rgb(34, 34, 34); font-family: arial; font-size: small;"><br></div><div =
style=3D"color: rgb(34, 34, 34); font-family: arial; font-size: =
small;">3) SPV wallets that want to get a good mix of nodes for =
measuring pending transactions identify nodes on the clearnet via their =
addr announcements+service flag, in the normal way. They select some of =
these nodes using the standard clearnet anti-sybil heuristics and =
connect&nbsp;<i>without using Tor</i>. They proceed to query them for =
their hidden service key. After they=92ve done that, they record the =
public IP-&gt;hidden service mapping and can go ahead and connect back =
to them at any later time via Tor itself.</div><div style=3D"color: =
rgb(34, 34, 34); font-family: arial; font-size: small;"><br></div><div =
style=3D"color: rgb(34, 34, 34); font-family: arial; font-size: =
small;">This would seem to be pointless - did we not just go ahead and =
bypass Tor entirely, thus making neither node hidden? Is it not a dead =
cert that the next connection the node gets via Tor is likely the same =
computer? Yes, but it only matters the first time. As long as those =
nodes are somewhat stable the mapping will be recorded on disk and the =
next time the wallet starts, it=92ll skip straight to using =
Tor.</div><div style=3D"color: rgb(34, 34, 34); font-family: arial; =
font-size: small;"><br></div><div style=3D"color: rgb(34, 34, 34); =
font-family: arial; font-size: small;">The goal of all that is that we =
get to keep our existing IPv4 based anti-sybil heuristics, so we can=92t =
possibly make anything worse, only better. Plus, we=92ve now set things =
up so in future if/when we come up with a better anti-sybil system based =
on anonymous identities or other fancy crypto, we can take out the =
=93connect via clearnet=94 step and go straight to using hidden services =
with only a very small set of code changes and no new protocol =
work.</div><div style=3D"color: rgb(34, 34, 34); font-family: arial; =
font-size: small;"><br></div><div style=3D"color: rgb(34, 34, 34); =
font-family: arial; font-size: small;">I like this idea for several =
reasons:</div><div style=3D"color: rgb(34, 34, 34); font-family: arial; =
font-size: small;"><br></div><div><ol class=3D"MailOutline"><li><span =
style=3D"color: rgb(34, 34, 34); font-family: arial; font-size: =
small;">It feels implementable to me in about a couple of weeks =
wall-time. The tasks are small - the new tor? p2p message is super easy =
to implement because a node already knows if it=92s a hidden service or =
not. On the bitcoinj side, it=92d take a bit of work to implement the =
extra storage of IPv4-&gt;onion mappings and ensure the right kind of =
connection is used at the right time, but it=92s not all that =
hard.</span></li><li><span style=3D"color: rgb(34, 34, 34); font-family: =
arial; font-size: small;">We could switch Tor on by default for a lot of =
users.</span></li><li><font color=3D"#222222" face=3D"arial" size=3D"2">On=
 the bitcoind side, Tor runs as a separate process and because it =
initiates connections to bitcoind, it can be easily sandboxed, e.g. ran =
as a different UNIX user or even run inside a chroot/ptrace jail. Even =
though Tor is likely to contain exploits, we can easily keep them away =
from the wallet. So there=92s not much additional surface =
area.</font></li><li><font color=3D"#222222" face=3D"arial" =
size=3D"2">Obviously as it=92s pure Java and client only, Orchid is =
immune to buffer overflows/double frees and other such security =
problems.</font></li><li><font color=3D"#222222" face=3D"arial" =
size=3D"2">It=92s optional for all parties. Wallet clients can try to =
fall back to non-Tor usage if their access to Tor seems to be blocked =
somehow.</font></li><li><font color=3D"#222222" face=3D"arial" =
size=3D"2">Tor is the gold standard for resisting traffic analysis - we =
know thanks to Snowden that it=92s good at this =
task.</font></li></ol></div><div style=3D"color: rgb(34, 34, 34); =
font-family: arial; font-size: small;"><br></div><div style=3D"color: =
rgb(34, 34, 34); font-family: arial; font-size: small;">To launch I=92d =
probably have a percentage throttle hosted on some SSLd website, so we =
can control the load placed on the existing hidden service =
nodes.</div><div style=3D"color: rgb(34, 34, 34); font-family: arial; =
font-size: small;"><br></div><div style=3D"color: rgb(34, 34, 34); =
font-family: arial; font-size: small;">Feedback welcome.</div><div =
style=3D"color: rgb(34, 34, 34); font-family: arial; font-size: =
small;"><br></div><div style=3D"color: rgb(34, 34, 34); font-family: =
arial; font-size: small;"><br></div><div style=3D"color: rgb(34, 34, =
34); font-family: arial; font-size: small;"><br></div><div style=3D"color:=
 rgb(34, 34, 34); font-family: arial; font-size: small;"><br></div><div =
style=3D"color: rgb(34, 34, 34); font-family: arial; font-size: =
small;"><br></div><div style=3D"color: rgb(34, 34, 34); font-family: =
arial; font-size: small;"><br></div></body></html>=

--Apple-Mail=_00AA894D-AF71-4024-B559-552757363EB1--

--Apple-Mail=_01340681-1782-4989-AAD7-C6ECAB5C893C
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIZmzCCBjQw
ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX
DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK
75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC
+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD
z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr
/+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc
fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG
XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt
UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R
HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv
sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s
sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq
+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT
zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq
Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1
9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGNjCCBR6g
AwIBAgIDBnIfMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN
MTMwNDIxMDExNDU0WhcNMTQwNDIyMTMyMjMzWjBVMRkwFwYDVQQNExBraUxnVHZjUWRZY0IySldQ
MRgwFgYDVQQDDA9taWtlQHBsYW45OS5uZXQxHjAcBgkqhkiG9w0BCQEWD21pa2VAcGxhbjk5Lm5l
dDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANLeGOyJFqq/jERHs+8X/CwcZ+NRs80U
dYZOTblQaE5+mELLNCnL+55EWyfre8zUVHXcRdnaGETCC5S5edkBxjDxbfPD6o8R4zIoZyHpxjFd
+j98rCEsHUkvjygw2ALGp5vV3pBaLmYa323J4E+VCV6wfpQsBaQgZe9yLE44hRfJ12ObpwVIJrao
To6ehX++Kn/tKMhe4WQuPm4gDHGFQHzisIf9/03Dn9kRIeqhxjfIXT6osiQPhdLi76Ijzi2UabHr
jGpivhWQoY+hdLTuPsCKw3Z/Mp2K7nGjPPuHIyRshbPys9Epcx/h81XJGTAFqbswHJwfu6tdV0Gp
FOHwzq0CAwEAAaOCAtUwggLRMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsG
AQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUyEcJY3IWy2yXzEK+hzh7tO19psUwHwYDVR0jBBgw
FoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwGgYDVR0RBBMwEYEPbWlrZUBwbGFuOTkubmV0MIIBTAYD
VR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj
b3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy
dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu
IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0w
K6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEB
BIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2Ns
aWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNs
YXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAd9sNcxjNTqAQyyRBCsaZKAQKVlT7zN4wqw8DTfnP4wXh6ycgayxg
5Ga6qy85aitivfMcyJuM7ojAWXBjBAlKIFYL+dlPByWFFVxaAsYD/rhhLP1t+nGHLA06YLtz+pJo
icODvOoyxlPTp66qeu/TMT8WTaO5Qpdr0Tn3MLPMwJN7BewLng8zpxoOV/u/xrmpkMV2PwlpTonb
L9VNUWYI0VsBG/0MDiLEQw6rg668gMRK06bM8GovzLU7i2z2Q0tz1kKeYKHAluC1N84qrO3V9tkp
oNDFPHlGfdmdkJDZeW7gF99+kCQVqr5pIadbp0Tmj7Kttwou1juSa/iaDgoMyDCCBm8wggRXoAMC
AQICEADVy4nCkwCb7b0BS9wQlgIwDQYJKoZIhvcNAQEFBQAwSTELMAkGA1UEBhMCQ0gxFTATBgNV
BAoTDFN3aXNzU2lnbiBBRzEjMCEGA1UEAxMaU3dpc3NTaWduIFBsYXRpbnVtIENBIC0gRzIwHhcN
MTAwMzA4MTQwNTA0WhcNMjUwMzA0MTQwNTA0WjBXMQswCQYDVQQGEwJDSDEVMBMGA1UEChMMU3dp
c3NTaWduIEFHMTEwLwYDVQQDEyhTd2lzc1NpZ24gU3Vpc3NlSUQgUGxhdGludW0gQ0EgMjAxMCAt
IEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4cSEEXIyNDHcWYj3QrVO/5OBfrIU
aK4au+FEcSFe4MvQ9/wV3p9DGSTf8vljcgHNPIYo4iHYh8xJVn7HK7PG6yS+JnoQsl5c8DI7UE5Z
W/kjfHj45W+rDmyhntQqG7FjPZQoPWdlC2lGkV2NEtenU+U0jXf2NpQw3LiPtF3CjliXr8BdusJk
vUm0ItfaJabF4+ygFa9qAm9YLGYaMNck17CoKsCVtDdaFKjBm3ColZeB5GAEZTwdBwFnHNp9fXvn
+QuNwhE5wMZT46pVXNbJlCrnEdblmiWEhei9jB5381hSsKai/zLaldVQ/aSu10WYg5KKkUfSWVVS
cT+j6PtM2QIDAQABo4ICQzCCAj8wDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw
HQYDVR0OBBYEFOlEhoCS6k5Qd8nnkghC11/AwiVCMB8GA1UdIwQYMBaAFFCvzAeHFUdvOMW0ZdHe
larp35zMMIH/BgNVHR8EgfcwgfQwR6BFoEOGQWh0dHA6Ly9jcmwuc3dpc3NzaWduLm5ldC81MEFG
Q0MwNzg3MTU0NzZGMzhDNUI0NjVEMURFOTVBQUU5REY5Q0NDMIGooIGloIGihoGfbGRhcDovL2Rp
cmVjdG9yeS5zd2lzc3NpZ24ubmV0L0NOPTUwQUZDQzA3ODcxNTQ3NkYzOEM1QjQ2NUQxREU5NUFB
RTlERjlDQ0MlMkNPPVN3aXNzU2lnbiUyQ0M9Q0g/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9i
YXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MGEGA1UdIARaMFgwVgYEVR0gADBO
MEwGCCsGAQUFBwIBFkBodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3NpZ24uY29tL1N3aXNzU2lnbi1Q
bGF0aW51bS1DUC1DUFMtUjMucGRmMHQGCCsGAQUFBwEBBGgwZjBkBggrBgEFBQcwAoZYaHR0cDov
L3N3aXNzc2lnbi5uZXQvY2dpLWJpbi9hdXRob3JpdHkvZG93bmxvYWQvNTBBRkNDMDc4NzE1NDc2
RjM4QzVCNDY1RDFERTk1QUFFOURGOUNDQzANBgkqhkiG9w0BAQUFAAOCAgEAOoY+H9Ann9SpqVsH
Be34r3tt2coVn5386F0UiH1IhaWNMVZoq0/sKjXuWp+kZrkNAqWwhvk4qghllxtngI7DSG4+1/9S
Gnpe8DTvngRHesAzVkbHfCoNqlKGBnjCp6i+cdmzOb3opj0MCd5kQkPksw3YTkBXJDiNaU43YRRX
b1uEAgQbizKkBgxZGpjDa4FSs5ry+Yq2rXeaUlPWmCR9wZS5kZ1anyfwyRSmFQK/bPMikCw9ySe2
8Dtz9nMNwZmHNGvhGYUF+F0QHMb+sdbGx6TD465fqdYe5M7/YpElRvS6jKOPScqUZoq0xxrBakc4
XPQgNOCrCRu0PKgROWeUGv3zZw8uY5Xy5DJoe7F7anxEJgTw9A41S0WDh75Iwjr9l91S9IzeiGR3
g6S6hrek98PWjdHmAfIo9FHGCSXbJFfa958h82QKnydUy79enXwRcPbvlw1FoTkBWgc0uceIx3jV
MlU7NyE+0PCiMIWM/YBbn0B0KmTYb2hdde8YDGp2M+qbW2wQv1gjC9vtm0Ens1bemN3GgeWQxQXM
AYXDJWb+dFy1sOIwvhzp31ei06x4C3EuiQXINzkQdgOL/7b5e5r23M4xWdISv9IEHwPc4IuXJ2NB
rB8zk9RmZRcQOjeHdwDM7n+i3FlPjL2/StV28qIuPiwzYjQhzQOBQM+7xd4wggayMIIFmqADAgEC
Ag8A3Hz8Etjr03yOomWvEiEwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMCQ0gxFTATBgNVBAoT
DFN3aXNzU2lnbiBBRzExMC8GA1UEAxMoU3dpc3NTaWduIFN1aXNzZUlEIFBsYXRpbnVtIENBIDIw
MTAgLSBHMjAeFw0xMzExMjExNDI5NDhaFw0xNDExMjExNDI5NDhaMGcxJzAlBgNVBAMTHk1pY2hh
ZWwgSGVhcm4gKEF1dGhlbnRpY2F0aW9uKTEeMBwGCSqGSIb3DQEJARYPbWlrZUBwbGFuOTkubmV0
MRwwGgYDVQQFExMxMzAwLTgwMTUtMTU4Ni05MTE4MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAhgAkK5PH/nRIcQcBZamR4P7jkS96g+ud/Tqi32bElgSzuuW6aWzOE0n/XR5HWf40mDx1
dRj0WM3dt/7Cl1KomoShfIsNxHxcG420vpeoQNQd8r8TokojCX6Y5l+TlAvSPdGhIyEOXG3puryO
4XBZNYHVkZ9fwhC7bau1sbn7mcU2qba/TwkRDGIFSiCml6z8rBMiJ/cSII2QcNgS+ziv82Uhz4i4
GVNPOmegboHkE8qT+gouEeVWMLivXDbAwQF1fBaE75z/Wr+w0K6YJtS7oAbgwIEJpe8/1/OS8HI8
46+02eMxThD+vqwnxcQo+EpicvoqmOsjnLErQG1cTA556QIDAQABo4IDaTCCA2UwTwYDVR0RBEgw
RoEPbWlrZUBwbGFuOTkubmV0oDMGCisGAQQBgjcUAgOgJQwjMTMwMC04MDE1LTE1ODYtOTExOEB1
cG4uc3Vpc3NlaWQuY2gwDgYDVR0PAQH/BAQDAgeAMCkGA1UdJQQiMCAGCCsGAQUFBwMCBggrBgEF
BQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUp8JGBqJ9qpKjNlth17DhQ+pIAG8wHwYDVR0jBBgw
FoAU6USGgJLqTlB3yeeSCELXX8DCJUIwgf8GA1UdHwSB9zCB9DBHoEWgQ4ZBaHR0cDovL2NybC5z
d2lzc3NpZ24ubmV0L0U5NDQ4NjgwOTJFQTRFNTA3N0M5RTc5MjA4NDJENzVGQzBDMjI1NDIwgaig
gaWggaKGgZ9sZGFwOi8vZGlyZWN0b3J5LnN3aXNzc2lnbi5uZXQvQ049RTk0NDg2ODA5MkVBNEU1
MDc3QzlFNzkyMDg0MkQ3NUZDMEMyMjU0MiUyQ089U3dpc3NTaWduJTJDQz1DSD9jZXJ0aWZpY2F0
ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwgbYG
A1UdIASBrjCBqzCBmwYIYIV0BRoBAQIwgY4wTAYIKwYBBQUHAgEWQGh0dHA6Ly9yZXBvc2l0b3J5
LnN3aXNzc2lnbi5jb20vU3dpc3NTaWduLVBsYXRpbnVtLUNQLUNQUy1SMy5wZGYwPgYIKwYBBQUH
AgIwMhowU3Vpc3NlSUQgaWRlbnRpdHkgYW5kIGF1dGhlbnRpY2F0aW9uIGNlcnRpZmljYXRlMAsG
CWCFdAFZAQEBATCB2wYIKwYBBQUHAQEEgc4wgcswZAYIKwYBBQUHMAKGWGh0dHA6Ly9zd2lzc3Np
Z24ubmV0L2NnaS1iaW4vYXV0aG9yaXR5L2Rvd25sb2FkL0U5NDQ4NjgwOTJFQTRFNTA3N0M5RTc5
MjA4NDJENzVGQzBDMjI1NDIwYwYIKwYBBQUHMAGGV2h0dHA6Ly9wbGF0aW51bS1zdWlzc2VpZC1n
Mi5vY3NwLnN3aXNzc2lnbi5uZXQvRTk0NDg2ODA5MkVBNEU1MDc3QzlFNzkyMDg0MkQ3NUZDMEMy
MjU0MjANBgkqhkiG9w0BAQUFAAOCAQEAQENx9hsahnGo3u/8ksy53OxZkaSISe6e4XT1i/o0qZ6D
Kd9noZ2LvbclyyNo3Q9W4TU1pP41yf4JcL25sx1z7U/e9Ze7vTZN/GZ+gv20gaCqm/cQWF19PjzT
PqYXvJjGK6euiQzACN/IEjxeuzaiml02jpFnH1VrNvgfib/WQCL9y1dK6aLx9noP3CXCnd0ZWhYI
dh1e4NZXetRFKII1z/iAlevHmEdLAv0XgKFA6RnBdxCFdw6E7cz2TUS3m59IkrE3z/3swGV+lg7Q
60ZNMAeskg1+zhNpaY9FyBdRDXk2K43ItgE5Mr8+LCdGwoIofXubME12En6DuOnQ38mqGzGCA0Qw
ggNAAgEBMGowVzELMAkGA1UEBhMCQ0gxFTATBgNVBAoTDFN3aXNzU2lnbiBBRzExMC8GA1UEAxMo
U3dpc3NTaWduIFN1aXNzZUlEIFBsYXRpbnVtIENBIDIwMTAgLSBHMgIPANx8/BLY69N8jqJlrxIh
MAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X
DTE0MDExNTIyNTEyMlowIwYJKoZIhvcNAQkEMRYEFHLpdx7yG1lUOrBhxFwwoM+5lk6xMIGlBgkr
BgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBnIfMIGnBgsqhkiG
9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp
BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMGch8wDQYJKoZIhvcN
AQEBBQAEggEAgaw/6YEr2aQ7xYd0rYcLPRFMCfYUUD+CvSG2H4TvXRHsgWKqcb9WHcfOucVRQdng
9wc+Z519DtapjFSfGu7XcfCqPTfIt9mdRL2jHTRhMZV/j5tXscHgWD2h3XybnlDevzgg69zeZrs/
9ev61XDr4N/ljbHx1mpz6QOkMFge+3QJE2Ew+vJLwKOmmZpBvPi6VR3JQ/A7OeyWCxCpX0l/AiiT
9qQl/5UXXqd7/VxYn7zV+JMEMbctj1pHpAJE0/CVmfVm/PNiuZI3t9J5BWi0+s/i2PTcrTeSt2P0
S4jwLfVap7YOJX7R1YQs0Y+zaZqCF4KV/88sMtnddchptIsa6wAAAAAAAA==

--Apple-Mail=_01340681-1782-4989-AAD7-C6ECAB5C893C--