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
|
Return-Path: <keatonatron@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 563A1892
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 31 Aug 2016 19:49:02 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f178.google.com (mail-qt0-f178.google.com
[209.85.216.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DEA91286
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 31 Aug 2016 19:49:01 +0000 (UTC)
Received: by mail-qt0-f178.google.com with SMTP id 52so31069391qtq.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 31 Aug 2016 12:49:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=QlA2W/hzyd2yOS5xT+l4O4R3fS9ve9a2bDRSnpln4Wg=;
b=vfckuRkJcxRH7aDQuXqC4Kece1T2hkzwnbJFJFuX672IgfU/t94CFWpJXx4pwqU1Kf
gjOmwDlIuTBrKY+BYt5JHXUvMllSp6tXIOnQAiTkepQQaNjVgE76vRBZwOrB6XxW/xCS
oCJYbYjLU/PpVqDpJ8BYczzuKfK3A/IACKvMm3UbllWZdN5fhcbx4AzTVAF4ieybDgcg
rzS/lKWio+u0IIoE5F1AVSZjH79/vi2mfT3LOqDoUY44fpbQBM/yRk0pjudoGV61JKn+
gWYaPuDDVzcb5z2hn8GMSjzrCXHFb1ftnDUl2m5qYBOj4Fw5+JG5e3VlB72JqLaVdJfH
Vuww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=QlA2W/hzyd2yOS5xT+l4O4R3fS9ve9a2bDRSnpln4Wg=;
b=RTddD01kx7y72PhCvLUO5WUgtFHJLh7HifR0ZSe5gJlyCUij6LfaEE9a82VcPh1MFA
apVqMO1gGX5ueiAZc9WzcoDqNDOIaIignl87hZ1CMPAtFiueNoGG+gQfXY3kvBBi/Ly6
+0fzgph37gQ9lp4MvaIQaW5OwodLf4q9bbn9vQEx6WzgUdRwMRk8cMGOxjfTLSip+ZY4
FWmbW6W9UTgoX9nnrA95KZhAFcOWVV+Z2/eYmsat5KqV6fNHYmKNG7Hhf/7mauziCd3H
xgcsm7xuTAYY0p0XeAd9MLeN4UjIEszioEm+ixCsmtv9e0/fFiSOy1EYRVw8LGLJpZB+
OfiQ==
X-Gm-Message-State: AE9vXwOoCMcyyOpUr5rnWipp2+vI9SvzJm1Zh9ZCZ34EWljtSLpvxUdWLpTeTEvR7APGlQujANC4o8vzMDOUEA==
X-Received: by 10.237.37.99 with SMTP id w32mr6988008qtc.59.1472672941125;
Wed, 31 Aug 2016 12:49:01 -0700 (PDT)
MIME-Version: 1.0
References: <20160824014634.GA19905@fedora-21-dvm>
<CAH+Axy4ahvQOG5=jGn68u0m5dTTmFCJ0isfOEt-Be=63ot55dg@mail.gmail.com>
<82507740-C4A3-4AF2-BA02-3B29E5FECDE4@petertodd.org>
In-Reply-To: <82507740-C4A3-4AF2-BA02-3B29E5FECDE4@petertodd.org>
From: James MacWhyte <macwhyte@gmail.com>
Date: Wed, 31 Aug 2016 19:48:50 +0000
Message-ID: <CAH+Axy6eOtqoLt5A40qYQG4S6UgFfEQeaM3Dgo677ZaH3NhQ5Q@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11420f8286b462053b63630e
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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
Cc: Jeff Coleman <jeff@ledgerlabs.io>
Subject: Re: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth"
Doublespending Protection
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: Wed, 31 Aug 2016 19:49:02 -0000
--001a11420f8286b462053b63630e
Content-Type: text/plain; charset=UTF-8
>
> >I've always assumed honeypots were meant to look like regular, yet
> >poorly-secured, assets.
>
> Not at all. Most servers have zero reason to have any Bitcoin's accessible
> via them, so the presence of BTC privkeys is a gigantic red flag that they
> are part of a honeypot.
>
I was talking about the traditional concept. From Wikipedia: "Generally, a
honeypot consists of data (for example, in a network site) that appears to
be a legitimate part of the site but is actually isolated and monitored,
and that seems to contain information or a resource of value to attackers,
which are then blocked."
I would argue there are ways to make it look like it is not a honeypot
(plenty of bitcoin services have had their hot wallets hacked before, and
if the intruder only gains access to one server they wouldn't know that all
the servers have the same honeypot on them). But I was just confirming that
the proposal is for an obvious honeypot.
> Re-read my last section on the "scorched earth" disincentive to
> doublespend the intruder.
>
> The first time I read it I didn't realize that the second transaction the
intruder has is designed to waste the honeypot AND additional funds
belonging to the honeypot creator. That's pretty good, from a game theory
perspective.
--001a11420f8286b462053b63630e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_quote"><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><br>
>I've always assumed honeypots were meant to look like regular, yet<=
br>
>poorly-secured, assets.<br>
<br>
Not at all. Most servers have zero reason to have any Bitcoin's accessi=
ble via them, so the presence of BTC privkeys is a gigantic red flag that t=
hey are part of a honeypot.<br></blockquote><div><br></div><div>I was talki=
ng about the traditional concept. From Wikipedia: "Generally, a honeyp=
ot consists of data (for example, in a network site) that appears to be a l=
egitimate part of the site but is actually isolated and monitored, and that=
seems to contain information or a resource of value to attackers, which ar=
e then blocked."<br><span style=3D"line-height:1.5"><br>I would argue =
there are ways to make it look like it is not a honeypot (plenty of bitcoin=
services have had their hot wallets hacked before, and if the intruder onl=
y gains access to one server they wouldn't know that all the servers ha=
ve the same honeypot on them). But=C2=A0I was just confirming that the prop=
osal is for an obvious honeypot.<br><br></span></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><br>
Re-read my last section on the "scorched earth" disincentive to d=
oublespend the intruder.<br>
<br></blockquote><div>The first time I read it I didn't realize that th=
e second transaction the intruder has is designed to waste the honeypot AND=
additional funds belonging to the honeypot creator. That's pretty good=
, from a game theory perspective.</div></div></div>
--001a11420f8286b462053b63630e--
|
