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
|
Return-Path: <natanael.l@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 69F4CE1C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Dec 2015 08:30:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D3C92A0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Dec 2015 08:30:38 +0000 (UTC)
Received: by mail-wm0-f51.google.com with SMTP id l126so34306785wml.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Dec 2015 00:30:38 -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:to
:cc:content-type;
bh=0JqSlH1Tb+fB526mdgLG8Zo4wnN6V5VngyP/lBoNfrc=;
b=ooKxdbgvC0uI0dAIJyG9+9JlRkxXGWFCW/OaLEXiuOb2VLvDYnTfcsKJevF/9gFZ5l
PeoeNLfFpAvsleB7FWEOyUEA/4rehD5XbTLdDQmR9qRJV0QqDDB5EwHFcElJdH9HDyxY
C0YaithWs+QFtAa/ZN6kXlHxNKCphazWRO7VAs2DqMVKSNRrareNrubshox4IFtEpEZI
SX3W6KZ18D09EvUggnLXQv6gGqciLlsyFZWn+K/VLub28nvkZ1Q61Xrr4G9QFWKqGgDX
UEjSqjyd0AG33IbFKzMhWpneyX+nDfepvYS4Y9VM1jrE3oMPIrd742vk0SkFZ5la5lOd
ng3Q==
MIME-Version: 1.0
X-Received: by 10.28.16.72 with SMTP id 69mr13692089wmq.100.1450600237554;
Sun, 20 Dec 2015 00:30:37 -0800 (PST)
Received: by 10.194.23.195 with HTTP; Sun, 20 Dec 2015 00:30:37 -0800 (PST)
Received: by 10.194.23.195 with HTTP; Sun, 20 Dec 2015 00:30:37 -0800 (PST)
In-Reply-To: <CAPkFh0u+pHWQfJJX5pJR5N5rhs=K0CgDaZwkf+dOS1UHMUU+bw@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>
<CAAcC9ysejDQ8tyn_hhTQ_1ToKsM2f2rdhG4d1X3O5uuBj1X8NQ@mail.gmail.com>
<CAPkFh0u+pHWQfJJX5pJR5N5rhs=K0CgDaZwkf+dOS1UHMUU+bw@mail.gmail.com>
Date: Sun, 20 Dec 2015 09:30:37 +0100
Message-ID: <CAAt2M1-MTR0+4UgpH-0W0f8PtCGAd1kjn4HmD-Jz4gaRZGuXrA@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
To: =?UTF-8?Q?Emin_G=C3=BCn_Sirer?= <el33th4x0r@gmail.com>
Content-Type: multipart/alternative; boundary=001a11471346dee1c40527502f15
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
X-Mailman-Approved-At: Sun, 20 Dec 2015 15:13:24 +0000
Cc: Bitcoin Dev <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 08:30:39 -0000
--001a11471346dee1c40527502f15
Content-Type: text/plain; charset=UTF-8
Wouldn't block withhold be fixed by not letting miners in pools know which
block candidates are valid before the pool knows? (Note: I haven't read any
other proposals for how to fix it, this may already be known)
As an example, by having the pool use the unique per-miner nonces sent to
each miner for effective division of labor as a kind of seed / commitment
value, where one in X block candidates will be valid, where X is the
current ratio between partial PoW blocks sent as mining proofs and the full
difficulty?
The computational work of the pool remains low (checking this isn't harder
than the partial PoW validation already performed), they pool simply looks
at which commitment value from the pool that the miner used, looks up the
correct committed value and hashes that together with the partial PoW. If
it hits the target, the block is valid.
--001a11471346dee1c40527502f15
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Wouldn't block withhold be fixed by not letting miners i=
n pools know which block candidates are valid before the pool knows? (Note:=
I haven't read any other proposals for how to fix it, this may already=
be known) </p>
<p dir=3D"ltr">As an example, by having the pool use the unique per-miner n=
onces sent to each miner for effective division of labor as a kind of seed =
/ commitment value, where one in X block candidates will be valid, where X =
is the current ratio between partial PoW blocks sent as mining proofs and t=
he full difficulty? </p>
<p dir=3D"ltr">The computational work of the pool remains low (checking thi=
s isn't harder than the partial PoW validation already performed), they=
pool simply looks at which commitment value from the pool that the miner u=
sed, looks up the correct committed value and hashes that together with the=
partial PoW. If it hits the target, the block is valid. </p>
--001a11471346dee1c40527502f15--
|
