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
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 07A36CE7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Dec 2015 15:30:10 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f178.google.com (mail-io0-f178.google.com
[209.85.223.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A5648130
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Dec 2015 15:30:09 +0000 (UTC)
Received: by mail-io0-f178.google.com with SMTP id 186so135388998iow.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Dec 2015 07:30:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:cc
:content-type; bh=HPmtuP1YVgT0Nz/9xGtzmqFJJLwktl3oVQAMOmTeT8g=;
b=p5LrfApNyPUSBDto9I1L+yvK0X2bIeVW+mJP6KQUc3GxU9l1Vo9u4chpRevkCQ0BA8
1m9eQDVht+VndwqOyCP21C1JVXxPZiQ+354eOt4Kv50PCnaY3aSwl/oTpvTwsJzeAlwc
jtmbZMYBAfYg7yJaW7+M3j1utpFKUifBCwUKSqmz+4R88EKjAl17u0k3kwN5OYWRYC9x
qI6l2l3SMAsUhYUEVkuRS9AqjrlCJZNdKjFHybpPxcxgYcA6AglkTzGmvAJluCYr89zT
7l4fYdvN2QUCUbnPCkn4tkZSl/tU3yhMNi0DCNxxI/B45Nbp2xnBuw1gN64KQO8lYvVl
13/w==
MIME-Version: 1.0
X-Received: by 10.107.153.79 with SMTP id b76mr18171985ioe.71.1450625409190;
Sun, 20 Dec 2015 07:30:09 -0800 (PST)
Received: by 10.79.77.75 with HTTP; Sun, 20 Dec 2015 07:30:09 -0800 (PST)
In-Reply-To: <CAAt2M19QwL1AyH=pVARGa0zYKUtRM9hz8vXUzyZb05E5EhQMeA@mail.gmail.com>
References: <20151219184240.GB12893@muck>
<CAAcC9yvh2ma2dFhNDEKs7vfXyQF9L+T0YtRvOsJ15AbfVti=cw@mail.gmail.com>
<219f125cee6ca68fd27016642e38fdf1@xbt.hk>
<CAAcC9ys_t7X0WpQ8W3577M8GLiA5sPV2F1BJ9qZbnMkE-1j3+Q@mail.gmail.com>
<aff8da46a69bdd7ef92ca87725866a5c@xbt.hk>
<CAPkFh0vNECi1OmBwki+8NNAQbe6EG2FEE4RR5z=kYVLLDFHUXg@mail.gmail.com>
<CAE-z3OU=18VuV+9U9meg5fRxQt3MZnAnQ2jPN5QBNk+ZtSoJXw@mail.gmail.com>
<CAAt2M19QwL1AyH=pVARGa0zYKUtRM9hz8vXUzyZb05E5EhQMeA@mail.gmail.com>
Date: Sun, 20 Dec 2015 15:30:09 +0000
Message-ID: <CAE-z3OVfhUAouWmpvYGSdXBMcYo7n=0CP=yVcSy5T0kzAtWh2Q@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a1140f7e0378f410527560c64
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS,
RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.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 15:30:10 -0000
--001a1140f7e0378f410527560c64
Content-Type: text/plain; charset=UTF-8
On Sun, Dec 20, 2015 at 12:42 PM, Natanael <natanael.l@gmail.com> wrote:
> If total difficulty is X and the ratio for full blocks to candidate blocks
> shared with the pool is Y, then the candidate block PoW now has to meet X/Y
> while hashing the candidate block PoW + the pool's commitment hash must
> meet Y, which together makes for X/Y*Y and thus the same total difficulty.
This gives the same total difficulty but miners are throwing away otherwise
valid blocks.
This means that it is technically a soft fork. All new blocks are valid
according to the old rule.
In practice, it is kind of a hard fork. If Y is 10, then all upgraded
miners are throwing away 90% of the blocks that are valid under the old
rules.
From the perspective of non-upgraded clients, the upgraded miners operate
at a 10X disadvantage.
This means that someone with 15% of the network power has a majority of the
effective hashing power, since 15% is greater than 8.5% (85% * 0.1).
The slow roll-out helps mitigate this though. It gives non-upgraded
clients time to react. If there is only a 5% difference initially, then
the attacker doesn't get much benefit.
The main differences are that there's a public key identifier the miners
> are told about in advance and expect to see in block templates, and that
> that now the pool has to publish this commitment value together with the
> block that also contains the commitment hash, and that this is verified
> together with the PoW.
I don't think public keys are strictly required. Registering them with
DNSSEC is way over the top. They can just publish the key on their website
and then use that for their identity.
--001a1140f7e0378f410527560c64
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
>On Sun, Dec 20, 2015 at 12:42 PM, Natanael <span dir=3D"ltr"><<a href=
=3D"mailto:natanael.l@gmail.com" target=3D"_blank">natanael.l@gmail.com</a>=
></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px=
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><sp=
an class=3D""></span>If total difficulty is X and the ratio for full blocks=
to candidate blocks shared with the pool is Y, then the candidate block Po=
W now has to meet X/Y while hashing the candidate block PoW + the pool'=
s commitment hash must meet Y, which together makes for X/Y*Y and thus the =
same total difficulty.
</blockquote><div><br></div>This gives the same total difficulty but miners=
are throwing away otherwise valid blocks.<br><br></div><div class=3D"gmail=
_quote">This means that it is technically a soft fork.=C2=A0 All new blocks=
are valid according to the old rule.<br></div><div class=3D"gmail_quote"><=
br></div>In practice, it is kind of a hard fork.=C2=A0 If Y is 10, then all=
upgraded miners are throwing away 90% of the blocks that are valid under t=
he old rules.<br><br></div>From the perspective of non-upgraded clients, th=
e upgraded miners operate at a 10X disadvantage.<br><br></div><div>This mea=
ns that someone with 15% of the network power has a majority of the effecti=
ve hashing power, since 15% is greater than 8.5% (85% * 0.1).<br><br></div>=
<div>The slow roll-out helps mitigate this though.=C2=A0 It gives non-upgra=
ded clients time to react.=C2=A0 If there is only a 5% difference initially=
, then the attacker doesn't get much benefit.<br><br></div><div><div><d=
iv class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex">The main differences are that there's a publ=
ic key identifier the miners are told about in advance and expect to see in=
block templates, and that that now the pool has to publish this commitment=
value together with the block that also contains the commitment hash, and =
that this is verified together with the PoW.=20
</blockquote></div><br></div><div class=3D"gmail_extra">I don't think p=
ublic keys are strictly required.=C2=A0 Registering them with DNSSEC is way=
over the top.=C2=A0 They can just publish the key on their website and the=
n use that for their identity.=C2=A0 <br></div></div></div></div>
--001a1140f7e0378f410527560c64--
|
