path: root/55/4e8fd50b37a8c6997042bec6247da6a4b9b35c

Return-Path: <adam@cypherspace.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 9BFF5C13
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 10 Sep 2015 17:48:46 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mout.perfora.net (mout.perfora.net [74.208.4.196])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AD814181
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 10 Sep 2015 17:48:44 +0000 (UTC)
Received: from mail-ig0-f170.google.com ([209.85.213.170]) by
	mrelay.perfora.net (mreueus002) with ESMTPSA (Nemesis) id
	0M7Zpp-1Yg5We2VtP-00xNKf for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 10 Sep 2015 19:48:43 +0200
Received: by igbkq10 with SMTP id kq10so26145050igb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 10 Sep 2015 10:48:42 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.118.71 with SMTP id kk7mr8719688igb.21.1441907322936;
	Thu, 10 Sep 2015 10:48:42 -0700 (PDT)
Received: by 10.50.132.195 with HTTP; Thu, 10 Sep 2015 10:48:42 -0700 (PDT)
Received: by 10.50.132.195 with HTTP; Thu, 10 Sep 2015 10:48:42 -0700 (PDT)
In-Reply-To: <CALqxMTEbRPsDLm=YkkEZWND6PnnWhS7DF5JNJdOF_AhsUPW1Ww@mail.gmail.com>
References: <CALqxMTEbRPsDLm=YkkEZWND6PnnWhS7DF5JNJdOF_AhsUPW1Ww@mail.gmail.com>
Date: Thu, 10 Sep 2015 18:48:42 +0100
Message-ID: <CALqxMTE-+YdjXCqmecsS5gOQ-zXCQq3qh_27wry1CHhWHj_Omw@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=089e0118372ec86dad051f68355a
X-Provags-ID: V03:K0:PFj7zOCl28qS6y+8n5B0+nzfz0fWNQcV1UmyEjCD02I812jCM17
	b4e9ROJovU1xUMGkuvnGlSg4NpGeSFinhw244fPQ+wAFdJsS2II+7gbO/ADz2Xk/BJyi+tE
	3IAo6Q1IX3JqzC2tfVXPxK09yebK0OddVjz0lweSTOCMIYSNPfjEaYwF6H+yfq1qwggJGxG
	50W+K8xGMQ+sT9j5pv1ow==
X-UI-Out-Filterresults: notjunk:1;V01:K0:aLXHMktba0Y=:h7M2WdXVfYUoWwCUARjfb4
	UnvruIVuZH3eX9BgdSiNpGbHynuLOs13xjx0kXrBkErTchi6qE8FJm1JgxbERgoI/D9BmTwaE
	S7+a0V3MvWaapDoUPJFWnHylgAEhw+VpajPdtOxBI9ou5V+my9oUscXPLgztsRnILe0//iaJX
	lqYDKk0vtG9oZeUw6428UP1NXcUE8kxuyoQVdyUOUlSvekRHITtR2grL294nXON3twOIyDZSd
	wwZ9pVLkh0G0uyL5j/559fZhhNv8uepGNfoTuek48y5RBnqFCBzX6LUM7gZ4meSjm9y6/vOKz
	nrOlXDlPlSEcEnp6fmlG12EYb7qaSY5wzvfoQGjVtxsfSj4sS9PrgcuHdrQueVk+36l9iKGPg
	+TxpxTLpjDdPUJGXhWuzC/+z3eL6Yk4iFrpQdfMHP4P20si+3Hzr1G2buHuOsTQa+lX5tlejB
	DHUQX0x3hTwLSrIMkBIc7SgQ+Ggw52GKLQn1ZXEWcKYfntfKnQzjXW/1+r4oleaflfbzZ03xM
	jpvsF4lgcUAOI4F8/YRct4edCesqVFfvTCj+BmyQVSkjte9jmXl0eRZsKbuyhl+IiN4b0NuM9
	urzC0Qtku4eViaDm1hR8tiR44422E4gtVdMU9v6PUhLLf/RC2i1mRJap2ujLgZXNvKaIhKEeZ
	CXknNJx6aVhQtg71eKTUluf0AS9WgNvqSW5VTI7/huofO+2M30xSDyN1vcP1kh8NWmBYpSFIS
	bvscGSq9YYJyDmNr
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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
Subject: [bitcoin-dev] Bitcoin threat modelling thread
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, 10 Sep 2015 17:48:46 -0000

--089e0118372ec86dad051f68355a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi

Came across this
https://groups.google.com/forum/m/#!topic/bitcoin-xt/zbPwfDf7UoQ useful
thread discussing Bitcoin threat modelling may reach wider audience on this
list.

Text from Mike Hearn:

 think the next stage is to build a threat model for Bitcoin.

This mail starts with background. If you already know what a threat model
is you can skip to the last section where I propose a first draft, as the
starting point for discussion.


An intro to threat modelling

In security engineering, a threat model
<https://en.wikipedia.org/wiki/Threat_model> is a document that informally
specifies:

Which adversaries (enemies) do you care about?What can they do?Why do they
want to attack you?As a result: what threats do they pose?How do you
prioritise these threats?

Establishing a threat model is an important part of any security
engineering project. In the early days of secure computing, threat
modelling hadn't been invented and as a result projects frequently hit the
following problem:

Every threat looked equally serious, so it became impossible to prioritise

Almost anything could become a threat, if you squinted right

So usability, performance, code maintainability etc were sacrificed over
and over to try and defend against absurd or very unlikely threats just
because someone identified one, in an endless race

The resulting product sucked and nobody used it, thus protecting people
from no threats at all

PGP is a good example of this problem in action.

Making good threat models isn't easy (see The Economist article,New Threat
Model Army
<http://www.economist.com/blogs/babbage/2013/11/internet-after-snowden>).
It can be controversial, because a threat model involves accepting that you
can't win all the time - there will exist adversaries that you
realistically cannot beat. Writing them down and not worrying about them
anymore liberates you to focus on other threats you might do a better job
at, or to work on usability, or features, or other things that users might
actually care about more.

You can make your threat model too weak, so it doesn't encompass real
threats your users are likely to encounter. But a much more common problem
is making the model too strong: including *too many* different kinds of
threats. Strangely, this can make your product *less* secure rather than
more.

One reason is that with too many threats in your model, you can lose your
ability to prioritise: every threat seems equally important even if perhaps
really they aren't, and then you can waste time solving "threats" that are
absurd or incredibly unlikely.

Even worse, once people add things in to a threat model they hate taking
them out, because it'd imply that previous efforts were wasted.

The Tor threat model

A good example of this is Tor. As you my know I have kind of a love/hate
relationship with Tor. It's a useful thing, but I often feel they could do
things differently.

The <https://www.torproject.org/about/overview.html.en#stayinganonymous>Tor
<https://www.torproject.org/about/overview.html.en#stayinganonymous>
project
<https://www.torproject.org/about/overview.html.en#stayinganonymous>*does
<https://www.torproject.org/about/overview.html.en#stayinganonymous>* have
a threat model
<https://www.torproject.org/about/overview.html.en#stayinganonymous>, and
it is a very strong one. Tor tries to protect you against adversaries that
care about very small leaks of application level data, like a browser
reporting your screen size, because it sees its mission as making all
traffic look identical, rather than just hiding your IP address. As a
consequence of this threat model Tor is meant to be used with apps that are
specifically "Torified", like their Tor Browser which is based on Firefox.
If a user takes the obvious approach of just downloading and running the
Tor Browser Bundle, their iTunes traffic won't be anonymised. The rationale
is it's useless to route traffic of random apps via Tor because even if
that hides the IP address, the apps might leak private data anyway as they
weren't designed for it.

This threat model has a couple of consequences:

It's extremely easy to think you're hiding your IP address when in fact you
aren't, due to using or accidentally running non-Torified apps.

The Tor Browser is based on Firefox. When Chrome came along it had a
clearly superior security architecture, because it was sandboxed, but the
Tor project had made a big investment in customising Firefox to anonymise
things like screen sizes. They didn't want to redo all that work.

The end result of this is that Tor's adversaries discovered they could just
break Tor completely by hacking the web browser, as Firefox is the least
secure browser and yet it's the one the Tor project recommends. The Snowden
files contain a bunch of references to this.

Interestingly, the Tor threat model explicitly *excludes* the NSA because
it can observe the whole network (it is the so-called "global passive
adversary"). Tor does this because they want to support low latency web
browsing, and nobody knows how to do that fast enough when your adversary
can watch the traffic between all Tor nodes. So they just exclude such
enemies from their threat model and that is why Tor is possible.

But even more interestingly, it turned out that their threat model
assumptions weren't quite correct. The NSA/GCHQ should, in theory, be able
to totally deanonymise Tor. But in practice they can't. When the time
finally came the 5 Eyes agencies attacked Tor by hacking the web browser,
not by exploiting their global observation abilities.

Tor has competitors - the commercial VPN providers. They have a rather
different threat model, where they explicitly don't care about application
level attacks like web sites looking at your screen size. They *only* care
about hiding your IP address. As a result their products work for every
app, and users can easily use Chrome or any other secure web browser.
Additionally they only add one hop of latency because the VPN provider does
not include itself in the threat model.

This solves for a different set of adversaries, but for many users it's
actually a more appropriate set and as a result VPNs are vastly more
popular than Tor is.

So to recap, we should build a threat model for Bitcoin because:

We have limited manpower and therefore must prioritise, sometimes brutally

Without a model anything can be a threat, so changes that are obvious or
look like technical no-brainers can get shot down due to the risk of absurd
or ridiculous attacks. This happens in Bitcoin Core *a lot*.

It will bring more formality and rigour to our thinking about security.



Proposed model

This is *a suggestion only*. I expect vigorous debate and for some people
to want a different (probably stronger) model. Models are just documents so
they can always be tweaked later, there's no need for v1 to be perfect.

OK. Adversaries I think we should care about in version 1, in priority
order:

Rational individuals and small groups, motivated by profit.

The "global passive adversary" as defined by the
<https://tools.ietf.org/html/rfc7624>IETF
<https://tools.ietf.org/html/rfc7624>, motivated by a desire to map Bitcoin
transactions to people in bulk.

And that's it.

*The GPA*

The "global passive adversary" can mean intelligence agencies *but only
sometimes*. Specifically, it assumes they only watch and they don't
actively interfere. This assumption is of course not entirely valid - IAs
do sometimes engage in active attacks. My suggested threat model doesn't
include that activity because (1) it's hard to do anything about it and (2)
they much prefer to stay stealthy anyway.

Of course, in the Bitcoin system, there may be other GPAs. Anyone who
watches the block chain can potentially be such an adversary. Note the
careful wording: you have to be doing deanonymization *in bulk* to be an
in-scope adversary. This is to avoid including block explorers that have
notes features, people who build lists of well known addresses etc. We
can't stop people doing that: it's up to Bitcoin users to avoid telling the
world which transactions are theirs. It also excludes exchanges that are
trying to monitor transactions going in and out of their platform for
compliance purposes: they are not attempting to do this for the entire
system, therefore, they are not adversaries in this threat model.

*Individuals and small groups*

They are assumed to have hacking skills that are considered good by the
standards of ordinary hackers - they are not script kiddies. However they
are also not state-level hackers: they do not have an endless bag of zero
days that can exploit any imaginable device.

These attackers are motivated by profit. An attack that yields only
worthless pieces of data is not interesting to these adversaries: they want
to monetise. Attacks that involve some incredibly convoluted process to
turn data into money is also uninteresting: we assume a level of
rationality that means they'll ignore attacks with very poor effort/reward
ratios.

*Examples*

Here are some examples of attackers that would be in-scope for this threat
model:

=E2=9C=93 A hacker who is attempting to steal the contents of your Bitcoin =
wallet

=E2=9C=93 A mugger at a conference who is trying to identify rich targets t=
o beat up

=E2=9C=93 A business owner who is attempting to discover the revenue of his
competitor

=E2=9C=93 A government attempting to build a map of every Bitcoin transacti=
on to
people

=E2=9C=93 Someone attempting to profit off a quick market panic by short se=
lling
BTC and then DoSing the network

.... and would not be in scope .....

=E2=9C=98 An actor who learns IP addresses of people using Bitcoin (reason:=
 not
profitable, mere fact of use is not enough to build a GPA map)

=E2=9C=98 A short seller who needs to successfully root a specific, well ru=
n server
to cause problems (reason: without zero days it's hard to attack a fully
patched and locked down machine)

=E2=9C=98 A bitcoin exchange that demands proof of where your money came fr=
om
(reason: not global adversary)

=E2=9C=98 A government who wants to shut down Bitcoin globally (reason: act=
ive
state adversary, can't realistically stop this as they can always mine a
bogus chain)

=E2=9C=98 A government who wants to shut down Bitcoin in their own territor=
y
(reason: active state adversary, can just find and arrest anyone
advertising BTC acceptance)

=E2=9C=98 A developer who wants to turn the block chain into a file sharing=
 network
(reason: not rational, the resulting product would be terrible)

=E2=9C=98 A random individual learning the balance of wallets on random IP
addresses (reason: can't monetise with any reasonable effort)

.... and could be argued either way .....

=E2=80=A2 A developer who wants to use the block chain for timestamping lot=
s of
data (can be seen as "motivated by profit", OTOH, actual threat is pretty
low)

=E2=80=A2 A miner who constantly tries to mine zero sized blocks or constan=
tly
double spends against high profile merchants (can be seen as "motivated by
profit" but also not rational behaviour as it'd tank the price of BTC)

Obviously this stuff is subjective. We can argue about what "rational"
means for miners, for instance.

The goal of the model is not to be 100% accurate or a perfect prediction of
the future. It's just there to help people prioritise development efforts.
Should I work on *this* new feature or addressing *that* threat? A threat
model can help you decide whether it's worth it. People can still choose to
work on threats that are outside of this model if they want to, and we can
also choose to ignore threats that might be inside it, if the cost/benefit
ratio is really bad.

The exclusion of many types of government adversary might be controversial.
It's for practical reasons: governments have lots of very effective ways to
interfere with Bitcoin that we can't do anything about, like bank
blockades, and so far most of them seem to be taking a wait-and-see stance
anyway.

--089e0118372ec86dad051f68355a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Hi</p>
<p dir=3D"ltr">Came across this <a href=3D"https://groups.google.com/forum/=
m/#!topic/bitcoin-xt/zbPwfDf7UoQ">https://groups.google.com/forum/m/#!topic=
/bitcoin-xt/zbPwfDf7UoQ</a> useful thread discussing Bitcoin threat modelli=
ng may reach wider audience on this list.=C2=A0 </p>
<p dir=3D"ltr">Text from Mike Hearn:</p>
<p dir=3D"ltr">=C2=A0think the next stage is to build a threat model for Bi=
tcoin.<br></p>
<p dir=3D"ltr">This mail starts with background. If you already know what a=
 threat model is you can skip to the last section where I propose a first d=
raft, as the starting point for discussion.<br><br><br></p>
<p dir=3D"ltr">An intro to threat modelling<br></p>
<p dir=3D"ltr">In security engineering, a=C2=A0<a href=3D"https://en.wikipe=
dia.org/wiki/Threat_model">threat model</a>=C2=A0is a document that informa=
lly specifies:</p>
<p dir=3D"ltr">Which adversaries (enemies) do you care about?What can they =
do?Why do they want to attack you?As a result: what threats do they pose?Ho=
w do you prioritise these threats?</p>
<p dir=3D"ltr">Establishing a threat model is an important part of any secu=
rity engineering project. In the early days of secure computing, threat mod=
elling hadn&#39;t been invented and as a result projects frequently hit the=
 following problem:</p>
<p dir=3D"ltr">Every threat looked equally serious, so it became impossible=
 to prioritise</p>
<p dir=3D"ltr">Almost anything could become a threat, if you squinted right=
</p>
<p dir=3D"ltr">So usability, performance, code maintainability etc were sac=
rificed over and over to try and defend against absurd or very unlikely thr=
eats just because someone identified one, in an endless race</p>
<p dir=3D"ltr">The resulting product sucked and nobody used it, thus protec=
ting people from no threats at all</p>
<p dir=3D"ltr">PGP is a good example of this problem in action.<br></p>
<p dir=3D"ltr">Making good threat models isn&#39;t easy (see The Economist =
article,<a href=3D"http://www.economist.com/blogs/babbage/2013/11/internet-=
after-snowden">New Threat Model Army</a>). It can be controversial, because=
 a threat model involves accepting that you can&#39;t win all the time - th=
ere will exist adversaries that you realistically cannot beat. Writing them=
 down and not worrying about them anymore liberates you to focus on other t=
hreats you might do a better job at, or to work on usability, or features, =
or other things that users might actually care about more.<br></p>
<p dir=3D"ltr">You can make your threat model too weak, so it doesn&#39;t e=
ncompass real threats your users are likely to encounter. But a much more c=
ommon problem is making the model too strong: including=C2=A0<i>too many</i=
>=C2=A0different kinds of threats. Strangely, this can make your product=C2=
=A0<b>less</b>=C2=A0secure=C2=A0rather than more.<br></p>
<p dir=3D"ltr">One reason is that with too many threats in your model, you =
can lose your ability to prioritise: every threat seems equally important e=
ven if perhaps really they aren&#39;t, and then you can waste time solving =
&quot;threats&quot; that are absurd or incredibly unlikely.<br></p>
<p dir=3D"ltr">Even worse, once people add things in to a threat model they=
 hate taking them out, because it&#39;d imply that previous efforts were wa=
sted.<br></p>
<p dir=3D"ltr">The Tor threat model<br></p>
<p dir=3D"ltr">A good example of this is Tor. As you my know I have kind of=
 a love/hate relationship with Tor. It&#39;s a useful thing, but I often fe=
el they could do things differently.<br></p>
<p dir=3D"ltr"><a href=3D"https://www.torproject.org/about/overview.html.en=
#stayinganonymous">The </a><a href=3D"https://www.torproject.org/about/over=
view.html.en#stayinganonymous">Tor</a><a href=3D"https://www.torproject.org=
/about/overview.html.en#stayinganonymous"> project=C2=A0</a><i><a href=3D"h=
ttps://www.torproject.org/about/overview.html.en#stayinganonymous">does</a>=
</i><a href=3D"https://www.torproject.org/about/overview.html.en#stayingano=
nymous">=C2=A0have a threat model</a>, and it is=C2=A0a very strong one. To=
r tries to protect you against adversaries that care about very small leaks=
 of application level data, like a browser reporting your screen size, beca=
use it sees its mission as making all traffic look identical, rather than j=
ust hiding your IP address. As a consequence of this threat model Tor is me=
ant to be used with apps that are specifically &quot;Torified&quot;, like t=
heir Tor Browser which is based on Firefox. If a user takes the obvious app=
roach of just downloading and running the Tor Browser Bundle, their iTunes =
traffic won&#39;t be anonymised. The rationale is it&#39;s useless to route=
 traffic of random apps via Tor because even if that hides the IP address, =
the apps might leak private data anyway as they weren&#39;t designed for it=
.=C2=A0<br></p>
<p dir=3D"ltr">This threat model has a couple of consequences:</p>
<p dir=3D"ltr">It&#39;s extremely easy to think you&#39;re hiding your IP a=
ddress when in fact you aren&#39;t, due to using or accidentally running no=
n-Torified apps.</p>
<p dir=3D"ltr">The Tor Browser is based on Firefox. When Chrome came along =
it had a clearly superior security architecture, because it was sandboxed, =
but the Tor project had made a big investment in customising Firefox to ano=
nymise things like screen sizes. They didn&#39;t want to redo all that work=
.</p>
<p dir=3D"ltr">The end result of this is that Tor&#39;s adversaries discove=
red they could just break Tor completely by hacking the web browser, as Fir=
efox is the least secure browser and yet it&#39;s the one the Tor project r=
ecommends. The Snowden files contain a bunch of references to this.</p>
<p dir=3D"ltr">Interestingly, the Tor threat model explicitly=C2=A0<i>exclu=
des</i>=C2=A0the NSA because it can observe the whole network (it is the so=
-called &quot;global passive adversary&quot;). Tor does this because they w=
ant to support low latency web browsing, and nobody knows how to do that fa=
st enough when your adversary can watch the traffic between all Tor nodes. =
So they just exclude such enemies from their threat model and that is why T=
or is possible.<br></p>
<p dir=3D"ltr">But even more interestingly, it turned out that their threat=
 model assumptions weren&#39;t quite correct. The NSA/GCHQ should, in theor=
y, be able to totally deanonymise Tor. But in practice they can&#39;t. When=
 the time finally came the 5 Eyes agencies attacked Tor by hacking the web =
browser, not by exploiting their global observation abilities.<br></p>
<p dir=3D"ltr">Tor has competitors - the commercial VPN providers. They hav=
e a rather different threat model, where they explicitly don&#39;t care abo=
ut application level attacks like web sites looking at your screen size. Th=
ey=C2=A0<i>only</i>=C2=A0care about hiding your IP address. As a result the=
ir products work for every app, and users can easily use Chrome or any othe=
r secure web browser. Additionally they only add one hop of latency because=
 the VPN provider does not include itself in the threat model.=C2=A0<br></p=
>
<p dir=3D"ltr">This solves for a different set of adversaries, but for many=
 users it&#39;s actually a more appropriate set and as a result VPNs are va=
stly more popular than Tor is.<br></p>
<p dir=3D"ltr">So to recap, we should build a threat model for Bitcoin beca=
use:</p>
<p dir=3D"ltr">We have limited manpower and therefore must prioritise, some=
times brutally</p>
<p dir=3D"ltr">Without a model anything can be a threat, so changes that ar=
e obvious or look like technical no-brainers can get shot down due to the r=
isk of absurd or ridiculous attacks. This happens in Bitcoin Core=C2=A0<i>a=
 lot</i>.</p>
<p dir=3D"ltr">It will bring more formality and rigour to our thinking abou=
t security.<br><br><br><br></p>
<p dir=3D"ltr">Proposed model<br></p>
<p dir=3D"ltr">This is=C2=A0<i>a suggestion only</i>. I expect vigorous deb=
ate and for some people to want a different (probably stronger) model. Mode=
ls are just documents so they can always be tweaked later, there&#39;s no n=
eed for v1 to be perfect.<br></p>
<p dir=3D"ltr">OK. Adversaries I think we should care about in version 1, i=
n priority order:</p>
<p dir=3D"ltr">Rational individuals and small groups, motivated by profit.=
=C2=A0</p>
<p dir=3D"ltr">The &quot;global passive adversary&quot;=C2=A0<a href=3D"htt=
ps://tools.ietf.org/html/rfc7624">as defined by the </a><a href=3D"https://=
tools.ietf.org/html/rfc7624">IETF</a>, motivated by a desire to map Bitcoin=
 transactions to people in bulk.</p>
<p dir=3D"ltr">And that&#39;s it.<br></p>
<p dir=3D"ltr"><b>The GPA</b><br></p>
<p dir=3D"ltr">The &quot;global passive adversary&quot; can mean intelligen=
ce agencies=C2=A0<i>but only sometimes</i>. Specifically, it assumes they o=
nly watch and they don&#39;t actively interfere. This assumption is of cour=
se not entirely valid - IAs do sometimes engage in active attacks. My sugge=
sted threat model doesn&#39;t include that activity because (1) it&#39;s ha=
rd to do anything about it and (2) they much prefer to stay stealthy anyway=
.<br></p>
<p dir=3D"ltr">Of course, in the Bitcoin system, there may be other GPAs. A=
nyone who watches the block chain can potentially be such an adversary. Not=
e the careful wording: you have to be doing deanonymization=C2=A0<i>in bulk=
</i>=C2=A0to be an in-scope adversary. This is to avoid including block exp=
lorers that have notes features, people who build lists of well known addre=
sses etc. We can&#39;t stop people doing that: it&#39;s up to Bitcoin users=
 to avoid telling the world which transactions are theirs. It also excludes=
 exchanges that are trying to monitor transactions going in and out of thei=
r platform for compliance purposes: they are not attempting to do this for =
the entire system, therefore, they are not adversaries in this threat model=
.<br><br></p>
<p dir=3D"ltr"><b>Individuals and small groups</b><br></p>
<p dir=3D"ltr">They are assumed to have hacking skills that are considered =
good by the standards of ordinary hackers - they are not script kiddies. Ho=
wever they are also not state-level hackers: they do not have an endless ba=
g of zero days that can exploit any imaginable device.<br></p>
<p dir=3D"ltr">These attackers are motivated by profit. An attack that yiel=
ds only worthless pieces of data is not interesting to these adversaries: t=
hey want to monetise. Attacks that involve some incredibly convoluted proce=
ss to turn data into money is also uninteresting: we assume a level of rati=
onality that means they&#39;ll ignore attacks with very poor effort/reward =
ratios.<br><br></p>
<p dir=3D"ltr"><b>Examples</b><br></p>
<p dir=3D"ltr">Here are some examples of attackers that would be in-scope f=
or this threat model:<br></p>
<p dir=3D"ltr">=E2=9C=93 A hacker who is attempting to steal the contents o=
f your Bitcoin wallet</p>
<p dir=3D"ltr">=E2=9C=93 A mugger at a conference who is trying to identify=
 rich targets to beat up</p>
<p dir=3D"ltr">=E2=9C=93 A business owner who is attempting to discover the=
 revenue of his competitor</p>
<p dir=3D"ltr">=E2=9C=93 A government attempting to build a map of every Bi=
tcoin transaction to people</p>
<p dir=3D"ltr">=E2=9C=93 Someone attempting to profit off a quick market pa=
nic by short selling BTC and then DoSing the network<br></p>
<p dir=3D"ltr">.... and would not be in scope .....<br></p>
<p dir=3D"ltr">=E2=9C=98 An actor who learns IP addresses of people using B=
itcoin (reason: not profitable, mere fact of use is not enough to build a G=
PA map)</p>
<p dir=3D"ltr">=E2=9C=98 A short seller who needs to successfully root a sp=
ecific, well run server to cause problems (reason: without zero days it&#39=
;s hard to attack a fully patched and locked down machine)</p>
<p dir=3D"ltr">=E2=9C=98 A bitcoin exchange that demands proof of where you=
r money came from (reason: not global adversary)</p>
<p dir=3D"ltr">=E2=9C=98 A government who wants to shut down Bitcoin global=
ly (reason: active state adversary, can&#39;t realistically stop this as th=
ey can always mine a bogus chain)</p>
<p dir=3D"ltr">=E2=9C=98 A government who wants to shut down Bitcoin in the=
ir own territory (reason: active state adversary, can just find and arrest =
anyone advertising BTC acceptance)</p>
<p dir=3D"ltr">=E2=9C=98 A developer who wants to turn the block chain into=
 a file sharing network (reason: not rational, the resulting product would =
be terrible)</p>
<p dir=3D"ltr">=E2=9C=98 A random individual learning the balance of wallet=
s on random IP addresses (reason: can&#39;t monetise with any reasonable ef=
fort)<br></p>
<p dir=3D"ltr">.... and could be argued either way .....<br></p>
<p dir=3D"ltr">=E2=80=A2 A developer who wants to use the block chain for t=
imestamping lots of data (can be seen as &quot;motivated by profit&quot;, O=
TOH, actual threat is pretty low)</p>
<p dir=3D"ltr">=E2=80=A2 A miner who constantly tries to mine zero sized bl=
ocks or constantly double spends against high profile merchants (can be see=
n as &quot;motivated by profit&quot; but also not rational behaviour as it&=
#39;d tank the price of BTC)<br></p>
<p dir=3D"ltr">Obviously this stuff is subjective. We can argue about what =
&quot;rational&quot; means for miners, for instance.<br></p>
<p dir=3D"ltr">The goal of the model is not to be 100% accurate or a perfec=
t prediction of the future. It&#39;s just there to help people prioritise d=
evelopment efforts. Should I work on=C2=A0<i>this</i>=C2=A0new feature or a=
ddressing=C2=A0<i>that</i>=C2=A0threat? A threat model can help you decide =
whether it&#39;s worth it. People can still choose to work on threats that =
are outside of this model if they want to, and we can also choose to ignore=
 threats that might be inside it, if the cost/benefit ratio is really bad.<=
br></p>
<p dir=3D"ltr">The exclusion of many types of government adversary might be=
 controversial. It&#39;s for practical reasons: governments have lots of ve=
ry effective ways to interfere with Bitcoin that we can&#39;t do anything a=
bout, like bank blockades, and so far most of them seem to be taking a wait=
-and-see stance anyway.<br>
</p>

--089e0118372ec86dad051f68355a--