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
154
|
Return-Path: <admin@glados.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8723FFBE
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 12 Feb 2016 11:31:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com
[209.85.214.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BD728D2
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 12 Feb 2016 11:31:56 +0000 (UTC)
Received: by mail-ob0-f169.google.com with SMTP id gc3so15943781obb.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 12 Feb 2016 03:31:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=glados-cc.20150623.gappssmtp.com; s=20150623;
h=mime-version:sender:in-reply-to:references:date:message-id:subject
:from:to:content-type;
bh=jCfeFMnaJ7L5gm8Jku80GfKAehnXH4LsGAeB5a+bz7o=;
b=rQJk8QINqtI5zShsLukADU+8/4PlatSeS3tdPdJ5A3FsZDIcUVT1t0NGvEDH3kFm4h
Ih/B0PugZLTlatGBGkFiU8m/s4txXLhbu5BXS2ehMeUpxWRSCGFL30qmZbCwxgZe8juz
V8eFKyJ31N9BXKrw5k2NAL4j1PZsifIkttKRonqYa6ImBJZ1ggm1DKtlmbUVlKSIH8O0
78fk93WqAMHJyKjMuZjbiGqdZXDGpaWp+TBtyl/4glOm5z3i6C7D700E9vYpLyKInOyn
DIJ9O9HgpRmWTxumCGCtQfbWbQufcezxj0J9CPEtF8oR++4XHv97toQep0ovjh3KkZ0C
uyrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:date
:message-id:subject:from:to:content-type;
bh=jCfeFMnaJ7L5gm8Jku80GfKAehnXH4LsGAeB5a+bz7o=;
b=Ta/gGcnsj5KOC6/REnHjdiZB/6WtvrY4UuOsFUmtC67jfY5seZp1zJyHcLieWL4fbo
P6BUhkNFxCX+j9hyjewqi2pYkQAHvkwaS1oRxxFnk1tgMZ2b+jN4cFl6XRm6jWtxozgl
SufB7SKd4C+1EByhyf2NF5Y9/LxMZrqVEpcdbqh5c1XGyuL/K+/mJ7rIqaaSMukAXM/H
+m1Ikje+z/oGnfJ/CMUATzQO60hOen6DaHvx2VkP50+vFQL7CAKqBkebq4O7E0Ezjvn2
bkUiwwxx/YbPd5b6x/r0eo9ATn3jic2gfmOByTavBiB3dcmJmMEeBAbpalXm0CcZy5E/
WZvw==
X-Gm-Message-State: AG10YOQQDDlKPwboFMFj5FvEIvbAIZlZOp0du9KUyfPCL+IIMfLmsTef1MiFnlVti8yPj+3AEdJkbepJcQmkng==
MIME-Version: 1.0
X-Received: by 10.202.77.11 with SMTP id a11mr697378oib.23.1455276716124; Fri,
12 Feb 2016 03:31:56 -0800 (PST)
Sender: admin@glados.cc
Received: by 10.202.214.2 with HTTP; Fri, 12 Feb 2016 03:31:56 -0800 (PST)
X-Originating-IP: [49.182.145.219]
Received: by 10.202.214.2 with HTTP; Fri, 12 Feb 2016 03:31:56 -0800 (PST)
In-Reply-To: <CAL7-sS1JhXAJ_hjUpLvnPWiwsf2hOwsaZdrq9negDPZiGs4nmg@mail.gmail.com>
References: <CAL7-sS0NdZ4E7qwSs9TQdvsyqrzY0q847oM2cnwEYA3ciXCs4g@mail.gmail.com>
<CAL7-sS3QFGg_uj0UN+vPSE1Y3-XTj3HeCaPxERznpMfhvaj28A@mail.gmail.com>
<CAL7-sS2DqPF0Y7+UT7qGp==MJBmHmbQW5em+XFY8ZkVPuzCPcQ@mail.gmail.com>
<CAL7-sS2TMUg1KTPgitzMq61-4+ppzpZ7E_aEsbLXOuBYqU_q-g@mail.gmail.com>
<CAL7-sS1JhXAJ_hjUpLvnPWiwsf2hOwsaZdrq9negDPZiGs4nmg@mail.gmail.com>
Date: Fri, 12 Feb 2016 22:31:56 +1100
X-Google-Sender-Auth: HLKujp5AgTyeoo7pMn-mulSyPjE
Message-ID: <CAL7-sS2vb5Aid-pTHHgJ0N9O8QYP=OR3HE1bVGw32LPm6W9SUA@mail.gmail.com>
From: gladoscc <admin+g@glados.cc>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11494d0eb70853052b910339
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,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: Fri, 12 Feb 2016 15:16:43 +0000
Subject: [bitcoin-dev] Soft fork fix for block withholding attacks
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: Fri, 12 Feb 2016 11:31:57 -0000
--001a11494d0eb70853052b910339
Content-Type: text/plain; charset=UTF-8
Here's a method of fixing block withholding attacks with a soft fork:
We require blocks to choose an arbitrary target, e.g. two bytes. We
redefine the block PoW target to be "less than the difficulty, with the
last two bytes being the target".
We require blocks to include a blinded hash of the target plus some junk
(which blinds it) in the coinbase. The miner cannot arbitrarily switch
targets.
The miner can now send the block header to hashers. Hashers do not know the
target, and hence must submit all shares that matches the first PoW
criteria (below difficulty) and delegate secondary verification to the
miner. With two bytes as the target, there are 65335 false positives for
every valid block.
Finally, we require miners to communicate a proof of their target hash (ie,
the junk they generated) in a non-hashed area of the block. This can be a
protocol extension. The target is already included in the hash as the last
two bytes.
This can be deployed as a soft fork with miner opt in, triggering across
many difficulty cycles. Initially, we soft fork to require the last bit of
the block hash to be zero. The next difficulty cycle, we require the last
two bits to be zero. We do this 16 times to get 2 bytes, and then we
actually activate targets.
By then, nominal difficulty would have been cut by 2^16 (65536), but the
block target makes mining each block 65536 times as hard. We do the
progression over 16 difficulty cycles to minimise increases in block
timings. We can be more specific and progress over even more difficulty
cycles through more clever soft fork rules.
For example, Vitalik detailed "timewalking" attacks that allow effective
granular lowering of the nominal difficulty.
Critique welcome.
--001a11494d0eb70853052b910339
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Here's a method of fixing block withholding attacks with=
a soft fork:</p>
<p dir=3D"ltr">We require blocks to choose an arbitrary target, e.g. two by=
tes. We redefine the block PoW target to be "less than the difficulty,=
with the last two bytes being the target".</p>
<p dir=3D"ltr">We require blocks to include a blinded hash of the target pl=
us some junk (which blinds it) in the coinbase. The miner cannot arbitraril=
y switch targets. </p>
<p dir=3D"ltr">The miner can now send the block header to hashers. Hashers =
do not know the target, and hence must submit all shares that matches the f=
irst PoW criteria (below difficulty) and delegate secondary verification to=
the miner. With two bytes as the target, there are 65335 false positives f=
or every valid block. </p>
<p dir=3D"ltr">Finally, we require miners to communicate a proof of their t=
arget hash (ie, the junk they generated) in a non-hashed area of the block.=
This can be a protocol extension. The target is already included in the ha=
sh as the last two bytes. </p>
<p dir=3D"ltr">This can be deployed as a soft fork with miner opt in, trigg=
ering across many difficulty cycles. Initially, we soft fork to require the=
last bit of the block hash to be zero. The next difficulty cycle, we requi=
re the last two bits to be zero. We do this 16 times to get 2 bytes, and th=
en we actually activate targets. </p>
<p dir=3D"ltr">By then, nominal difficulty would have been cut by 2^16 (655=
36), but the block target makes mining each block 65536 times as hard. We d=
o the progression over 16 difficulty cycles to minimise increases in block =
timings. We can be more specific and progress over even more difficulty cyc=
les through more clever soft fork rules. </p>
<p dir=3D"ltr">For example, Vitalik detailed "timewalking" attack=
s that allow effective granular lowering of the nominal difficulty. </p>
<p dir=3D"ltr">Critique welcome. </p>
--001a11494d0eb70853052b910339--
|
