path: root/4c/12f67f3d7cc4d4d4db7d77e71e73b53460d6fc

Return-Path: <daniele.pinna@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id A612CBB6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 19 Feb 2018 13:41:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pl0-f44.google.com (mail-pl0-f44.google.com
	[209.85.160.44])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C964FE4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 19 Feb 2018 13:41:23 +0000 (UTC)
Received: by mail-pl0-f44.google.com with SMTP id x18so92690pln.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 19 Feb 2018 05:41:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=8BIG38ypVmVXmtQyMlmqH5QOkr7KL+TeMZ9rLvtyH9A=;
	b=Wny4FXoPezoFyZsRwb7tgxTpv7qe9MnEHaaoCU9RBlLB7AO2pO/g3oBewOSgwDAaWf
	TBLcFhsaOTRGQIqJVKdbc5ANxrSAJRv8ke9UTdGmfGrU/1e6wr/ao4cWzt9KvIxZeN9c
	EGk72if1iIupwkT+tuRP73yUfEO4Su0pAvqS5HMMMJpkX0q99UlnBhsGL53XVGRBgxtP
	049c8XENmJ1+ROIjM04WUk70jPbSlho0YNYVFirL8SLiQJLSjGWheOqo8cRoySGCFGdf
	0iyj9mZC4Yeacv7wPvu8Gok/Ub4o8Jjebq7qgbBPyDpMNuhipKzAcsh85kWBjyMvM6Ml
	vkdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=8BIG38ypVmVXmtQyMlmqH5QOkr7KL+TeMZ9rLvtyH9A=;
	b=a5LUVEkRAV1nuo7JYYJy/1crK6rL68ltj+peds/tfBT1yzQRo0/HSkVODQU2JCLlVt
	B6hwxSm4seWgUHzy8o3XyaVP5y3PuojmR3I1cWTL/p5tDTw6TzM/vWiFkNzDPE39zsCh
	g221knXOwLhuNPHxoPnXsVII/6H7jyc7imZpe+3DG71oAPuc18jh6XaG41HvcdNaIKsE
	phv09wGnB4aS9/iSBi5xMtT/na4ZZzOYfkqQFEdODu6P9D3ZYhmaaZjw38l20vcSY7QJ
	e2XyW/7xNySVJ22rryWyA75KsNxEZK/8rdEnS/AzLTnheUFyOFRleLtXCBmbwiY9PchC
	fDYg==
X-Gm-Message-State: APf1xPBPxliLaqbuQapn7SPqs8+20YaUVf4HRKPaf3R8kHHn+kXWNJCf
	oBgdz+U6tAYQRpnkGtbhzM4yRvnYWmESmxZHmJAjGg==
X-Google-Smtp-Source: AH8x224F/S7EWtS+DrkTEHVGdPIEmKqyCOQ5IkRJml4Bvq6velsoME9ZO4TC1wJpY0d8wi6gWGs8AKUSU3dRBST4SVU=
X-Received: by 2002:a17:902:5a4a:: with SMTP id
	f10-v6mr14250706plm.308.1519047683121; 
	Mon, 19 Feb 2018 05:41:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.160.69 with HTTP; Mon, 19 Feb 2018 05:41:21 -0800 (PST)
Received: by 10.100.160.69 with HTTP; Mon, 19 Feb 2018 05:41:21 -0800 (PST)
In-Reply-To: <CAEgR2PEEgoY2y33-rmHuNDxprvAiAzP0H=ByCGmzd+zMA=QFVQ@mail.gmail.com>
References: <CAEgR2PGV7NdJ79uh80GdZ5nP2ehkH1J3v=Tv6c0g6OLE+sL7LQ@mail.gmail.com>
	<CAEgR2PHSSGx-JHhw+sCdeVTacba=P4X6+ZZhihS85HZsAL1gmg@mail.gmail.com>
	<CAEgR2PEUam3rwOxW1kKv6k5=WJ=p2PWzto3UCAuF3zgZn9NkWQ@mail.gmail.com>
	<CAEgR2PE0aX+UOoSPyB+YEsT_BiDe3qO20X1EVn763uxOoJHpww@mail.gmail.com>
	<CAEgR2PHM1WxNkUvvNKacBD0XX3VFKEyYWaKR+HOF-ZrrijLQ4A@mail.gmail.com>
	<CAEgR2PHqDcLaMnoONJgGrC51g+kjhCjU1GnSh+YzU-HLjkUJsw@mail.gmail.com>
	<CAEgR2PGfhK0WKVipTpwThnK8d-pPj9O5ZCVna3oO5Wi_rEA-Eg@mail.gmail.com>
	<CAEgR2PHuD2ZQeaqo2cArw7rR17755V3jAEHW34B+CUnaBjTqSA@mail.gmail.com>
	<CAEgR2PEof7Z1x0CSuEQUbmjs8_s2-y9ipDOa0utEuTnysnqEPA@mail.gmail.com>
	<CAEgR2PHvK+HXAKygysUXV0BoG851E-a1kiD7JDVuCDSvAx41RQ@mail.gmail.com>
	<CAEgR2PEpHnvCSFLckARHMM_5uhUP8KXE4MjyB1KPOjSRng01tg@mail.gmail.com>
	<CAEgR2PHatZ0_0006=7QtapJ=_DV975DPY91Bd0f3yYgE_r+srg@mail.gmail.com>
	<CAEgR2PFuOgFbJtfq9CLxNNSn+99Y6yRfYg=BvOCY_=vO+=pukw@mail.gmail.com>
	<CAEgR2PFM7W9StLiWGRT8g6-iFR904QJzCUUa_MdT58p1SsYxYw@mail.gmail.com>
	<CAEgR2PF7Ke1VENpsq+7jyn=Xen3S5pWBWLwhTJa=eAYT396yNQ@mail.gmail.com>
	<CAEgR2PE+BZUXwtaRgKybk5szeSvmg_tQHzxJHO3LQO-QOR2Sxg@mail.gmail.com>
	<CAEgR2PE5+xB2hr9-_hRftz_F4kGBTKy_oHpLbdDJyGmJgV_Xbw@mail.gmail.com>
	<CAEgR2PH=NuZv0ULP6=tiEjb15_Z37FvfmLBbiRYo1ht+2Radfw@mail.gmail.com>
	<CAEgR2PHVWfV5bVBGeCv5oP_k5kfEcs592gv=VKUYBKC8EXZw_Q@mail.gmail.com>
	<CAEgR2PFyYgZRyNbOGQhx1PR-rgpXDFgSOGGYUCBkG32YZ2+=KQ@mail.gmail.com>
	<CAEgR2PG8enwcyfkTGkPxD9Qcvmvypr5WJCCe=qMg1er0Ty+5Mg@mail.gmail.com>
	<CAEgR2PFFFfWeuhyPk6doj-jOeJcxXVfZ5CUDEWZPcnf3BG61=g@mail.gmail.com>
	<CAEgR2PFkxbXU_v6DgDCue4_5cM7FftAhNiwPgfvdQ2FLg+3drg@mail.gmail.com>
	<CAEgR2PHes8J85d4m6yB0JoPsA95zEts-fsJPaPds0mFHt8dnOA@mail.gmail.com>
	<CAEgR2PFALKvgdc7NVCsL=eCyWoBxu8gsFMPcfkffAB9Bay1+cw@mail.gmail.com>
	<CAEgR2PE4YMdFnjJ6kYA-CFBY2fW0GED-1RXM8iXzFv_xJEikHw@mail.gmail.com>
	<CAEgR2PGG-+epbAsOxVn29qcHcVLJ+X0js5Xzu0sN0uSEPj1hfQ@mail.gmail.com>
	<CAEgR2PHx=RmwV5HK-B33v8fbzqWMSAW-6ef-s7iiYGQT=PYVwA@mail.gmail.com>
	<CAEgR2PG6+5uT1dQLO9EbqTxB=1xHtS7nmpr4TUDO+bNzAiyhHg@mail.gmail.com>
	<CAEgR2PGezGVKYHrHS9RgvyNJiKPA_uqRYbhWjhzCw_PaXtDv+A@mail.gmail.com>
	<CAEgR2PFWZebe0fXiUcGD7q371a_OLb2JvJyX+1jZHUYZhChi=w@mail.gmail.com>
	<CAEgR2PF0VRxwHNkJinDCOWgVCojg=DSZHqYiYR_Cqa3OUNg8EA@mail.gmail.com>
	<CAEgR2PGs18xm6QSCwdzHRZt89pCCXpMFD+YAxZrhztoY8EdGJQ@mail.gmail.com>
	<CAEgR2PEEgoY2y33-rmHuNDxprvAiAzP0H=ByCGmzd+zMA=QFVQ@mail.gmail.com>
From: Daniele Pinna <daniele.pinna@gmail.com>
Date: Mon, 19 Feb 2018 14:41:21 +0100
Message-ID: <CAEgR2PH_HJ08SiYRfWLvm4c=edTzeFiJK98C8_Ae11zJVE9+yw@mail.gmail.com>
To: Contact@taoeffect.com, Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000008ca667056590d96a"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 19 Feb 2018 14:28:09 +0000
Subject: Re: [bitcoin-dev] Some thoughts on removing timestamps in PoW
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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, 19 Feb 2018 13:41:24 -0000

--0000000000008ca667056590d96a
Content-Type: text/plain; charset="UTF-8"

Granted that removing the 21M coin cap is basically a non-starter in de
bitcoin community I'd like to respond to a couple points in your proposal.

The Y% difficulty adjustment should still be calculated through some
averaging of a certain number N of past blocks. Otherwise two lucky high
difficulty blocks in a row could potentially grind the network to a halt.
Just imagine what would happen to the bitcoin network if the difficulty
target was magically increased by 40% all of a sudden. This is certainly
not likely but must be considered imo.

The second, and most interesting (to me at least) is how the reward should
scale with difficulty. By making the reward scale concavely
(logarithmically for example) with difficulty as well as depend on past
average difficulty AND total # of mined coins, it might be possible to
retain something close to the 21M coin cap while also disincentivizing
mining blocks with excessively large difficulties.

Let D and D_0 be the difficulty of the mind block and some reference
initial difficulty respectively. S and S_0 the total floating coin supply
and the reference initial supply. Then the reward function could look
something like this:

R(D, S; D_0,S_0) =R_0(S/S_0)*Log[1+D/D_0]/Log[2]

Where R_0(S/S_0) can be some decaying exponential function of the ratio
S/S_0 such that initially (when S=S_0) R_0=12.5.

But... As I said, this is solely for sake of argument.

Daniele

---------- Forwarded message ----------
From: Tao Effect <contact@taoeffect.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Cc:
Bcc:
Date: Sun, 18 Feb 2018 20:29:50 -0500
Subject: [bitcoin-dev] Some thoughts on removing timestamps in PoW
Copied from: https://github.com/WebOfTrustInfo/rebooting-the-
web-of-trust-spring2018/pull/13


# Blockchain Timestamps Unnecessary In Proof-of-Work?

*Author: Greg Slepak ([@taoeffect@mastodon.social](https://mastodon.social/@
taoeffect))*

----

The Bitcoin blockchain has a 10-minute target blocktime that is achieved by
a difficulty adjustment algorithm.

I assert, or rather, pose the hypothesis, that the use of timestamps in
Bitcoin's blockchain may be unnecessary, and that Bitcoin can operate with
the same security guarantees without it (except as noted in [Risks and
Mitigations](#risks-and-mitigations)), and therefore does not need miners
to maintain global clock synchronization.

The alternative difficulty adjustment algorithm would work according to the
following principles:

- The incentive for miners is and always has been to maximize profit.
- The block reward algorithm is now modified to issue coins into perpetuity
(no maximum). Any given block can issue _up to_ `X` number of coins per
block.
- The number of coins issued per block is now tied directly to the
difficulty of the block, and the concept of "epocs" or "block reward
halving" is removed.
- The chain selection rule remains "chain with most proof of work"
- The difficulty can be modified by miners in an arbitrary direction (up or
down), but is limited in magnitude by some maximum percentage (e.g. no more
than 20% deviation from the previous block), we call this `Y%`.

### Observations

- Miners are free to mine blocks of whatever difficulty they choose, up to
a maximum deviation
- The blockchain may at times produce blocks very quickly, and at other
times produce blocks more slowly
- Powerful miners are incentivized to raise the difficulty to remove
competitors (as is true today)
- Whether miners choose to produce blocks quickly or slowly is entirely up
to them. If they produce blocks quickly, each block has a lower reward, but
there are more of them. If they produce blocks slowly, each block has a
higher reward, but there are fewer of them. So an equilibrium will be
naturally reached to produce blocks at a rate that should minimize orphans.

A timestamp may still be included in blocks, but it no longer needs to be
used for anything, or represent anything significant other than metadata
about when the miner claims to have produced the block.

### Risks and Mitigations

Such a system may introduce risks that require further modification of the
protocol to mitigate.

The most straightforward risk comes from the potential increase in total
transaction throughput that such a change would introduce (these are the
same concerns that exist with respect to raising the blocksize). The
removal of timestamps would allow a cartel of miners to produce
high-difficulty blocks at a fast rate, potentially resulting in additional
centralization pressures not only on miners but also on full nodes who then
would have greater difficulty keeping up with the additional bandwidth and
storage demands.

Two equally straightforward mitigations exist to address this if we are
given the liberty of modifying the protocol as we wish:

1. Introducing state checkpoints into the chain itself could make it
possible for full nodes to skip verification of large sections of
historical data when booting up.
2. A sharded protocol, where each shard uses a "sufficiently different" PoW
algorithm, would create an exit for users should the primary blockchain
become captured by a cartel providing poor quality-of-service.


--
Please do not email me anything that you are not comfortable also sharing with
the NSA.

--0000000000008ca667056590d96a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div dir=3D"auto">Granted that removing the 21M coin cap =
is basically a non-starter in de bitcoin community I&#39;d like to respond =
to a couple points in your proposal.=C2=A0</div><div dir=3D"auto"><br></div=
><div dir=3D"auto">The Y% difficulty adjustment should still be calculated =
through some averaging of a certain number N of past blocks. Otherwise two =
lucky high difficulty blocks in a row could potentially grind the network t=
o a halt. Just imagine what would happen to the bitcoin network if the diff=
iculty target was magically increased by 40% all of a sudden. This is certa=
inly not likely but must be considered imo.=C2=A0</div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">The second, and most interesting (to me at least)=
 is how the reward should scale with difficulty. By making the reward scale=
 concavely (logarithmically for example) with difficulty as well as depend =
on past average difficulty AND total # of mined coins, it might be possible=
 to retain something close to the 21M coin cap while also disincentivizing =
mining blocks with excessively large difficulties.=C2=A0</div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">Let D and D_0 be the difficulty of the min=
d block and some reference initial difficulty respectively. S and S_0 the t=
otal floating coin supply and the reference initial supply. Then the reward=
 function could look something like this:</div><div dir=3D"auto"><br></div>=
<div dir=3D"auto">R(D, S; D_0,S_0) =3DR_0(S/S_0)*Log[1+D/D_0]/Log[2]</div><=
div dir=3D"auto"><br></div><div dir=3D"auto">Where R_0(S/S_0) can be some d=
ecaying exponential function of the ratio S/S_0 such that initially (when S=
=3DS_0) R_0=3D12.5.</div><div dir=3D"auto"><br></div><div dir=3D"auto">But.=
.. As I said, this is solely for sake of argument.=C2=A0</div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">Daniele=C2=A0</div><div dir=3D"auto"><br s=
tyle=3D"font-family:sans-serif;font-size:12.8px"><span style=3D"font-family=
:sans-serif;font-size:12.8px">---------- Forwarded message ----------</span=
><br style=3D"font-family:sans-serif;font-size:12.8px"><span style=3D"font-=
family:sans-serif;font-size:12.8px">From:=C2=A0Tao Effect &lt;<a href=3D"ma=
ilto:contact@taoeffect.com">contact@taoeffect.com</a>&gt;</span><br style=
=3D"font-family:sans-serif;font-size:12.8px"><span style=3D"font-family:san=
s-serif;font-size:12.8px">To:=C2=A0Bitcoin Protocol Discussion &lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfo=
undation.org</a>&gt;</span><br style=3D"font-family:sans-serif;font-size:12=
.8px"><span style=3D"font-family:sans-serif;font-size:12.8px">Cc:=C2=A0</sp=
an><br style=3D"font-family:sans-serif;font-size:12.8px"><span style=3D"fon=
t-family:sans-serif;font-size:12.8px">Bcc:=C2=A0</span><br style=3D"font-fa=
mily:sans-serif;font-size:12.8px"><span style=3D"font-family:sans-serif;fon=
t-size:12.8px">Date:=C2=A0Sun, 18 Feb 2018 20:29:50 -0500</span><br style=
=3D"font-family:sans-serif;font-size:12.8px"><span style=3D"font-family:san=
s-serif;font-size:12.8px">Subject:=C2=A0[bitcoin-dev] Some thoughts on remo=
ving timestamps in PoW</span><br style=3D"font-family:sans-serif;font-size:=
12.8px"><div style=3D"font-family:sans-serif;font-size:12.8px;word-wrap:bre=
ak-word" dir=3D"auto"><div>Copied from:=C2=A0<a href=3D"https://github.com/=
WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/pull/13" style=3D"text=
-decoration-line:none;color:rgb(66,133,244)">https://github.com/<wbr>WebOfT=
rustInfo/rebooting-the-<wbr>web-of-trust-spring2018/pull/<wbr>13</a></div><=
div><br></div><div><br></div><div># Blockchain Timestamps Unnecessary In Pr=
oof-of-Work?</div><div><br></div><div>*Author: Greg Slepak ([@<a href=3D"ma=
ilto:taoeffect@mastodon.social" style=3D"text-decoration-line:none;color:rg=
b(66,133,244)">taoeffect@mastodon.social</a>](<a href=3D"https://mastodon.s=
ocial/@taoeffect" style=3D"text-decoration-line:none;color:rgb(66,133,244)"=
><wbr>https://mastodon.social/@<wbr>taoeffect</a>))*</div><div><br></div><d=
iv>----</div><div><br></div><div>The Bitcoin blockchain has a 10-minute tar=
get blocktime that is achieved by a difficulty adjustment algorithm.</div><=
div><br></div><div>I assert, or rather, pose the hypothesis, that the use o=
f timestamps in Bitcoin&#39;s blockchain may be unnecessary, and that Bitco=
in can operate with the same security guarantees without it (except as note=
d in [Risks and Mitigations](#risks-and-<wbr>mitigations)), and therefore d=
oes not need miners to maintain global clock synchronization.</div><div><br=
></div><div>The alternative difficulty adjustment algorithm would work acco=
rding to the following principles:</div><div><br></div><div>- The incentive=
 for miners is and always has been to maximize profit.</div><div>- The bloc=
k reward algorithm is now modified to issue coins into perpetuity (no maxim=
um). Any given block can issue _up to_ `X` number of coins per block.</div>=
<div>- The number of coins issued per block is now tied directly to the dif=
ficulty of the block, and the concept of &quot;epocs&quot; or &quot;block r=
eward halving&quot; is removed.</div><div>- The chain selection rule remain=
s &quot;chain with most proof of work&quot;</div><div>- The difficulty can =
be modified by miners in an arbitrary direction (up or down), but is limite=
d in magnitude by some maximum percentage (e.g. no more than 20% deviation =
from the previous block), we call this `Y%`.</div><div><br></div><div>### O=
bservations</div><div><br></div><div>- Miners are free to mine blocks of wh=
atever difficulty they choose, up to a maximum deviation</div><div>- The bl=
ockchain may at times produce blocks very quickly, and at other times produ=
ce blocks more slowly</div><div>- Powerful miners are incentivized to raise=
 the difficulty to remove competitors (as is true today)</div><div>- Whethe=
r miners choose to produce blocks quickly or slowly is entirely up to them.=
 If they produce blocks quickly, each block has a lower reward, but there a=
re more of them. If they produce blocks slowly, each block has a higher rew=
ard, but there are fewer of them. So an equilibrium will be naturally reach=
ed to produce blocks at a rate that should minimize orphans.</div><div><br>=
</div><div>A timestamp may still be included in blocks, but it no longer ne=
eds to be used for anything, or represent anything significant other than m=
etadata about when the miner claims to have produced the block.</div><div><=
br></div><div>### Risks and Mitigations</div><div><br></div><div>Such a sys=
tem may introduce risks that require further modification of the protocol t=
o mitigate.</div><div><br></div><div>The most straightforward risk comes fr=
om the potential increase in total transaction throughput that such a chang=
e would introduce (these are the same concerns that exist with respect to r=
aising the blocksize). The removal of timestamps would allow a cartel of mi=
ners to produce high-difficulty blocks at a fast rate, potentially resultin=
g in additional centralization pressures not only on miners but also on ful=
l nodes who then would have greater difficulty keeping up with the addition=
al bandwidth and storage demands.</div><div><br></div><div>Two equally stra=
ightforward mitigations exist to address this if we are given the liberty o=
f modifying the protocol as we wish:</div><div><br></div><div>1. Introducin=
g state checkpoints into the chain itself could make it possible for full n=
odes to skip verification of large sections of historical data when booting=
 up.</div><div>2. A sharded protocol, where each shard uses a &quot;suffici=
ently different&quot; PoW algorithm, would create an exit for users should =
the primary blockchain become captured by a cartel providing poor quality-o=
f-service.</div><div><br></div><div><span style=3D"font-family:helvetica;fo=
nt-size:14px;font-variant-numeric:normal;font-variant-east-asian:normal;lin=
e-height:normal"><br>--</span><br style=3D"font-family:helvetica;font-size:=
14px;font-variant-numeric:normal;font-variant-east-asian:normal;line-height=
:normal"><span style=3D"font-family:helvetica;font-size:14px;font-variant-n=
umeric:normal;font-variant-east-asian:normal;line-height:normal">Please do =
not email me anything that you are not comfortable also sharing</span><span=
 style=3D"font-family:helvetica;font-size:14px;font-variant-numeric:normal;=
font-variant-east-asian:normal;line-height:normal">=C2=A0with the NSA.</spa=
n></div></div><br></div></div>

--0000000000008ca667056590d96a--