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
|
Return-Path: <nbvfour@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3259DE9C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Dec 2015 03:44:01 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com
[209.85.213.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9ACA2EC
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Dec 2015 03:44:00 +0000 (UTC)
Received: by mail-ig0-f178.google.com with SMTP id ph11so17287481igc.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Dec 2015 19:44:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:date:message-id:subject
:from:to:cc:content-type;
bh=zuKDuEACzociBQtEfXp0IE7skDGTlCBupNppWNDOMTE=;
b=ieJlT0GLhRZRMGK5RyILrptd4PIPLWW+Hcu5cU6l6ZvbmsAHxv0AvGhPF1/ZHl8Mvr
PYWTFFTexNNzLFuyaV0rA6jOjQXTZtxmm1VE/1v0fYEuHoAXVt4psy17lfObzISPqv8x
h9V0h//RbDX0Sb7//tyhQHponEiQof+ANdwYbGCzOI8+VHqvfxpdu3LYVn5pevKMKyFL
TzYGPwp9fq19ZO8ktFN3otypWS1tY0UcAZyAWqDew/KX/q1lvxr/JxgvyCBmIjimb2mm
Utmt8iaLBOLayG+dMdrlkFPH3yw9IMKbf+Wg1w6NoGqi5HZ0BO9smisn/H/sJShleeBN
ZtLg==
MIME-Version: 1.0
X-Received: by 10.50.3.71 with SMTP id a7mr10901488iga.80.1450583040041; Sat,
19 Dec 2015 19:44:00 -0800 (PST)
Sender: nbvfour@gmail.com
Received: by 10.36.20.142 with HTTP; Sat, 19 Dec 2015 19:43:59 -0800 (PST)
In-Reply-To: <4882BD35-D890-4860-9222-5C23AEB6AE89@mattcorallo.com>
References: <20151219184240.GB12893@muck>
<CAAcC9yvh2ma2dFhNDEKs7vfXyQF9L+T0YtRvOsJ15AbfVti=cw@mail.gmail.com>
<4882BD35-D890-4860-9222-5C23AEB6AE89@mattcorallo.com>
Date: Sat, 19 Dec 2015 19:43:59 -0800
X-Google-Sender-Auth: lccQMrUO_f4dkhJvjn0UbYgC92c
Message-ID: <CAAcC9yspsPs3gbumS4rTOg-P-=V=tycn2Z1nVPGGHwJ-nP+PBg@mail.gmail.com>
From: Chris Priest <cp368202@ohiou.edu>
To: Matt Corallo <lf-lists@mattcorallo.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, FREEMAIL_FROM, 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: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] We need to fix the block withholding attack
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: Sun, 20 Dec 2015 03:44:01 -0000
Then shouldn't this be something the pool deals with, not the bitcoin protocol?
On 12/19/15, Matt Corallo <lf-lists@mattcorallo.com> wrote:
> Peter was referring to pool-block-withholding, not selfish mining.
>
> On December 19, 2015 7:34:26 PM PST, Chris Priest via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>Block witholding attacks are only possible if you have a majority of
>>hashpower. If you only have 20% hashpower, you can't do this attack.
>>Currently, this attack is only a theoretical attack, as the ones with
>>all the hashpower today are not engaging in this behavior. Even if
>>someone who had a lot of hashpower decided to pull off this attack,
>>they wouldn't be able to disrupt much. Once that time comes, then I
>>think this problem should be solved, until then it should be a low
>>priority. There are more important things to work on in the meantime.
>>
>>On 12/19/15, Peter Todd via bitcoin-dev
>><bitcoin-dev@lists.linuxfoundation.org> wrote:
>>> At the recent Scaling Bitcoin conference in Hong Kong we had a
>>chatham
>>> house rules workshop session attending by representitives of a super
>>> majority of the Bitcoin hashing power.
>>>
>>> One of the issues raised by the pools present was block withholding
>>> attacks, which they said are a real issue for them. In particular,
>>pools
>>> are receiving legitimate threats by bad actors threatening to use
>>block
>>> withholding attacks against them. Pools offering their services to
>>the
>>> general public without anti-privacy Know-Your-Customer have little
>>> defense against such attacks, which in turn is a threat to the
>>> decentralization of hashing power: without pools only fairly large
>>> hashing power installations are profitable as variance is a very real
>>> business expense. P2Pool is often brought up as a replacement for
>>pools,
>>> but it itself is still relatively vulnerable to block withholding,
>>and
>>> in any case has many other vulnerabilities and technical issues that
>>has
>>> prevented widespread adoption of P2Pool.
>>>
>>> Fixing block withholding is relatively simple, but (so far) requires
>>a
>>> SPV-visible hardfork. (Luke-Jr's two-stage target mechanism) We
>>should
>>> do this hard-fork in conjunction with any blocksize increase, which
>>will
>>> have the desirable side effect of clearly show consent by the entire
>>> ecosystem, SPV clients included.
>>>
>>>
>>> Note that Ittay Eyal and Emin Gun Sirer have argued(1) that block
>>> witholding attacks are a good thing, as in their model they can be
>>used
>>> by small pools against larger pools, disincentivising large pools.
>>> However this argument is academic and not applicable to the real
>>world,
>>> as a much simpler defense against block withholding attacks is to use
>>> anti-privacy KYC and the legal system combined with the variety of
>>> withholding detection mechanisms only practical for large pools.
>>> Equally, large hashing power installations - a dangerous thing for
>>> decentralization - have no block withholding attack vulnerabilities.
>>>
>>> 1) http://hackingdistributed.com/2014/12/03/the-miners-dilemma/
>>>
>>> --
>>> 'peter'[:-1]@petertodd.org
>>> 00000000000000000188b6321da7feae60d74c7b0becbdab3b1a0bd57f10947d
>>>
>>_______________________________________________
>>bitcoin-dev mailing list
>>bitcoin-dev@lists.linuxfoundation.org
>>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
|
