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
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <peter@coinlab.com>) id 1SbML3-0007zm-LF
for bitcoin-development@lists.sourceforge.net;
Mon, 04 Jun 2012 01:44:09 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of coinlab.com
designates 209.85.214.175 as permitted sender)
client-ip=209.85.214.175; envelope-from=peter@coinlab.com;
helo=mail-ob0-f175.google.com;
Received: from mail-ob0-f175.google.com ([209.85.214.175])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
(Exim 4.76) id 1SbML2-00046P-Gg
for bitcoin-development@lists.sourceforge.net;
Mon, 04 Jun 2012 01:44:09 +0000
Received: by obhx4 with SMTP id x4so7888111obh.34
for <bitcoin-development@lists.sourceforge.net>;
Sun, 03 Jun 2012 18:44:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-type:x-gm-message-state;
bh=x76WxmxlZKa7765b/cLar1zTx0FizQWt8M5kH7qSqQ8=;
b=iCBzb/vx39ioRHA2/UPOBFujVpffgIz3bcvNHAakfMuO1nbpbui8JNXWM5s7IHk1Xy
AXz6KOIlKmmRQ7ztmawxB78Hc0izgiBHbpCrSx9zLnJv3liyBA0/FsHWWMBrg8Mul++d
Vvk8dXVAYfx/agkoHejZ6wQC4YEz7WlHaMlyt3z+0DYk+GQ14E+evxb+n4qmcqrxGMyJ
6irysD5+JphzfZoKWIqlwHXsS5SiQZwNXgwHmnfZvOy6XkecK/Cq3Bbl/ty/N1JlONbj
PXmRoGxfQ8fgk6tYkzidep5Z7A5anq+PVljDL4tcdNZe9LtlDJeZsfvXOp1huXy1m/NV
DvMw==
Received: by 10.60.14.41 with SMTP id m9mr10213586oec.57.1338774242881; Sun,
03 Jun 2012 18:44:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.41.200 with HTTP; Sun, 3 Jun 2012 18:43:42 -0700 (PDT)
In-Reply-To: <201206030052.17128.luke@dashjr.org>
References: <201206030052.17128.luke@dashjr.org>
From: Peter Vessenes <peter@coinlab.com>
Date: Sun, 3 Jun 2012 21:43:42 -0400
Message-ID: <CAMGNxUu7SbnfpU8L+qp7KUmFLSU=VqcYGu2GhzRaYhkTT3Nz7A@mail.gmail.com>
To: Luke-Jr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=e89a8fb1fac02e72aa04c19babec
X-Gm-Message-State: ALoCoQlRrC/1snxKDowJsT3bzXJaxdb1w5h3pZpAF9vtsQnkNQmer5z3Ai7tLkvJVqq8KP2hwrTO
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 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1SbML2-00046P-Gg
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Defeating the block withholding attack
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: Mon, 04 Jun 2012 01:44:09 -0000
--e89a8fb1fac02e72aa04c19babec
Content-Type: text/plain; charset=ISO-8859-1
On Sat, Jun 2, 2012 at 8:52 PM, Luke-Jr <luke@dashjr.org> wrote:
> Analysis, comments, constructive criticism, etc welcome for the following:
>
> ==Background==
> At present, an attacker can harm a pool by intentionally NOT submitting
> shares
> that are also valid blocks. All pools are vulnerable to this attack,
> whether
> centralized or decentralized and regardless of reward system used. The
> attack's effectiveness is proportional to ratio of the attacker's hashrate
> to
> the rest of the pool.
>
>
I'm unclear on the economics of this attack; we spent a bit of time talking
about it a few months ago at CoinLab and decided not to worry about it for
right now.
Does it have asymmetric payoff for an attacker, that is, over time does it
pay them more to spend their hashes attacking than just mining?
My gut is that it pays less well than mining, meaning I think this is
likely a small problem in the aggregate, and certainly not something we
should try and fork the blockchain for until there's real pain.
Consider, for instance, whether it pays better than just mining bitcoins
and spending those on 'bonuses' for getting users to switch from a pool you
hate.
Watson, I don't believe the attack signature you mention is a factor here,
since the pool controls the merkle, only that pool will benefit from block
submission. The nonce / coinbase combo is worthless otherwise, and so this
attack is just in brief "get lucky, but don't submit."
So, can anyone enlighten me as to some actual estimates of badness for this
attack?
Peter
--e89a8fb1fac02e72aa04c19babec
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br><div class=3D"gmail_quote">On Sat, Jun 2, 2012 at 8:52 PM, Luke-Jr =
<span dir=3D"ltr"><<a href=3D"mailto:luke@dashjr.org" target=3D"_blank">=
luke@dashjr.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Analysis, comments, constructive criticism, etc welcome for the following:<=
br>
<br>
=3D=3DBackground=3D=3D<br>
At present, an attacker can harm a pool by intentionally NOT submitting sha=
res<br>
that are also valid blocks. All pools are vulnerable to this attack, whethe=
r<br>
centralized or decentralized and regardless of reward system used. The<br>
attack's effectiveness is proportional to ratio of the attacker's h=
ashrate to<br>
the rest of the pool.<br><br></blockquote><div><br></div><div>I'm uncle=
ar on the economics of this attack; we spent a bit of time talking about it=
a few months ago at CoinLab and decided not to worry about it for right no=
w.</div>
<div><br></div><div>Does it have asymmetric payoff for an attacker, that is=
, over time does it pay them more to spend their hashes attacking than just=
mining?=A0</div><div><br></div><div>My gut is that it pays less well than =
mining, meaning I think this is likely a small problem in the aggregate, an=
d certainly not something we should try and fork the blockchain for until t=
here's real pain.</div>
<div><br></div><div>Consider, for instance, whether it pays better than jus=
t mining bitcoins and spending those on 'bonuses' for getting users=
to switch from a pool you hate.</div><div>=A0</div><div>Watson, I don'=
t believe the attack signature you mention is a factor here, since the pool=
controls the merkle, only that pool will benefit from block submission. Th=
e nonce / coinbase combo is worthless otherwise, and so this attack is just=
in brief "get lucky, but don't submit."</div>
<div><br></div><div>So, can anyone enlighten me as to some actual estimates=
of badness for this attack?</div><div><br></div><div>Peter</div></div>
--e89a8fb1fac02e72aa04c19babec--
|
