summaryrefslogtreecommitdiff
path: root/a0/a315469cfcd8ae34a8f99182731fc0b0ebf2da
blob: 5d93a0faadd09aa38ba721085a95e119a4f7e8f5 (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
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1XK74Y-0001ly-B9
	for bitcoin-development@lists.sourceforge.net;
	Wed, 20 Aug 2014 14:41:10 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.53 as permitted sender)
	client-ip=209.85.219.53; envelope-from=mh.in.england@gmail.com;
	helo=mail-oa0-f53.google.com; 
Received: from mail-oa0-f53.google.com ([209.85.219.53])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1XK74W-0001yc-Ir
	for bitcoin-development@lists.sourceforge.net;
	Wed, 20 Aug 2014 14:41:10 +0000
Received: by mail-oa0-f53.google.com with SMTP id j17so6451999oag.40
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 20 Aug 2014 07:41:03 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.52.5 with SMTP id p5mr48841988oeo.55.1408545663172; Wed,
	20 Aug 2014 07:41:03 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.97.132 with HTTP; Wed, 20 Aug 2014 07:41:03 -0700 (PDT)
In-Reply-To: <20140820125901.CB71CE043A5@quidecco.de>
References: <20140818164543.GB31175@localhost.localdomain>
	<20140820125901.CB71CE043A5@quidecco.de>
Date: Wed, 20 Aug 2014 16:41:03 +0200
X-Google-Sender-Auth: MOx8mIeDmj6KGow_Un7LlkWIYOs
Message-ID: <CANEZrP1RzLmSB74xdFZbePAE9nxjR-_hSCGQhNH81vRKSji2AQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Isidor Zeuner <cryptocurrencies@quidecco.de>
Content-Type: multipart/alternative; boundary=001a11332c8ee746630501109728
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: 1XK74W-0001yc-Ir
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Ivan Pustogarov <ivan.pustogarov@uni.lu>
Subject: Re: [Bitcoin-development] Proposal: PoW-based throttling of
 addresses (was: Outbound connections rotation)
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, 20 Aug 2014 14:41:10 -0000

--001a11332c8ee746630501109728
Content-Type: text/plain; charset=UTF-8

>
> Misbehaving addresses can have their connecting difficulty
> scaled up, which should make it uneconomic to try to DoS the usage of
> Tor exit nodes for connecting to Bitcoin.
>

You can't solve DoS by requiring all clients to do complicated work, all
that means is that weak clients (like users mobile phones and tablets) are
successfully DoSd whereas the attackers botnet of stolen computers sit
there solving PoWs.

The correct way to solve DoS is by having work prioritisation and queueing
mechanisms, then finding ways to distinguish "good" clients from "bad"
clients. Doing this whilst preserving privacy is hard. Long term the only
way to solve it may be to require clients to present some kind of cookie
during resource exhaustion events that prove they've been around for a
while, thus allowing them to jump the queue.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">Misbehaving addresses can have their connecting =
difficulty<br>

scaled up, which should make it uneconomic to try to DoS the usage of<br>
Tor exit nodes for connecting to Bitcoin.<br></blockquote><div><br></div><d=
iv>You can&#39;t solve DoS by requiring all clients to do complicated work,=
 all that means is that weak clients (like users mobile phones and tablets)=
 are successfully DoSd whereas the attackers botnet of stolen computers sit=
 there solving PoWs.</div>
<div><br></div><div>The correct way to solve DoS is by having work prioriti=
sation and queueing mechanisms, then finding ways to distinguish &quot;good=
&quot; clients from &quot;bad&quot; clients. Doing this whilst preserving p=
rivacy is hard. Long term the only way to solve it may be to require client=
s to present some kind of cookie during resource exhaustion events that pro=
ve they&#39;ve been around for a while, thus allowing them to jump the queu=
e.</div>
</div></div></div>

--001a11332c8ee746630501109728--