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
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
|
Return-Path: <bit.kevin@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0D9B8A64
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 Oct 2017 15:52:20 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DF107431
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 Oct 2017 15:52:18 +0000 (UTC)
Received: by mail-wm0-f52.google.com with SMTP id l68so4072713wmd.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 03 Oct 2017 08:52:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to;
bh=pKWSz/17hXuQohumGXJcmry59wLQixgrrJuug7GqY78=;
b=bexSHpmSVjSv0pL5uHv1ndTZhDIhV3LNLEC7iuPsDWqtXOH7M2qxPJChnsJZdA/6tk
kB1kxBWr8b5lPWTRjNAnl4GfA4MzS0b4+w21IoW3XxAbQrKXhBz2f6K+XXtUyCoTYalk
kDKGiD6WLBz+cjkf2sDZ+bZKrLIqO/PHvGl+t+vRcAE4exFUPueCXlDMrq3Qgn6Fz0Ie
lnZLnF/QnLOkoDStSdn7IbI/fco7xtP1tA1OE8SPmHd4oNwH4nRQ15rbs6J14OsgjFhf
rjwG54QOTmYsmmhenmxVSjD6Rt3StMVffiVmMvFxmLjAU45zV98Kz6eAzIS4GQwL9ZTj
d4hw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=pKWSz/17hXuQohumGXJcmry59wLQixgrrJuug7GqY78=;
b=S7hXr9MfOkZRHwn+3elxmocz3TmcH7FLBzmPQLJ9GvO6FJQAIU65GmwiKn9f1wXYT4
tKx4W7/2pihM7zH1kW2p3P8KWlNIB+TOd7BNd3h/TeLWs6AvMk7RWfdrvFlHVi3fClrj
yrZJ/bjLYldMIsINjuZu6uJlbSKCgUXBsmqGfUiSrVfO8Gwt/fyagAeR5Q4H/CnENrYU
iEKy0rE030g5XJeahb12ID7tfI2ficCuAsd4RyrEJB6EgU0s+EXvN5Qhr6f6mJlcjvYB
oamueRw58Eum8a8CgLQfAC0PjmgxdbY4mlEy644oaaKo3UBvoZu/2OTr4HqDQR0lqMiZ
+U8g==
X-Gm-Message-State: AHPjjUiFIY/fcaDGGe7z1ouzYf7DqOmUBm0Q8OuPBpN1fnUHe1hIFrk+
hcyS2FVzz/aO79cuPA9M5vPcXw6SBfvvJ+Y9ptD95UEN
X-Google-Smtp-Source: AOwi7QBTW4YzbzvvwKwyEzsYCYQXRbzb6vElILKDZbPWeL69u9LceweXkcJ6j4EYLSRc/Onc2M1NeSPyQfmnPOLJ37Q=
X-Received: by 10.80.136.81 with SMTP id c17mr24767416edc.13.1507045937279;
Tue, 03 Oct 2017 08:52:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.216.6 with HTTP; Tue, 3 Oct 2017 08:52:16 -0700 (PDT)
From: =?UTF-8?B?5r2Y5b+X5b2q?= <bit.kevin@gmail.com>
Date: Tue, 3 Oct 2017 23:52:16 +0800
Message-ID: <CA+fZXJKuE_C7231-OHM2gvFUYBKjfoDoOfh+04YqHZuQF41eag@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="94eb2c0df462c076ae055aa6794d"
X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=disabled 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, 06 Oct 2017 11:51:19 +0000
Subject: [bitcoin-dev] A solution may solve Block Withholding Attack
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Tue, 03 Oct 2017 15:52:20 -0000
--94eb2c0df462c076ae055aa6794d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Here is a solution may solve Block Withholding Attack. The general idea is
came from Aviv Zohar(avivz@cs.huji.ac.il), I made it work for Bitcoin.
Anyway, thanks Aviv.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
DIFF_1 =3D 0x00000000FFFF00000000000000000000000000000000000000000000000000=
00;
Diff =3D DIFF_1 / target
this is equal to
Diff =3D DIFF_1 / (target - 0) or Diff =3D DIFF_1 / abs(target - 0)
now, we change diff algo to below:
New_Diff =3D DIFF_1 / abs(target - offset)
Offset is 32 bytes, like uint256 in Bitcoin, range is [0, 2^256),
define: offset_hash =3D DSHA256(offset).
we need to do a little change to the merkle root hash algo, put the
offset_hash as a tx hash in the front of tx hashes.
[offset_hash, coinbase_tx_hash, tx01_hash, tx02_hash, =E2=80=A6 , tx_n_hash=
]
Actually could put offset_hash in any place in the array of hashes.
network_hash_range =3D network_hash_end - network_hash_begin
miner_hash_range =3D miner_hash_end - miner_hash_begin
The offset value MUST between network_hash_begin/end or
miner_hash_begin/end.
https://user-images.githubusercontent.com/514951/31133378-e00d9ca2-a891-11e=
7-8c61-73325f59f6ed.JPG
When mining pool send a job to miners, put the PoW hash range
(miner_hash_begin/end) in the job. So if the miners find a hash which value
is between [miner_hash_begin, miner_hash_end], means it's SHOULD be a
valid share, could submit the share to the pool. If the hash value is
between [network_hash_begin, network_hash_end] means find a valid block.
The network_diff is much much high than the miner's diff, means the
network_hash_range is much much smaller than miner_hash_range. By now,
a typical miner's pool diff is around 16K, network diff is 1123863285132,
so miner_hash_range is at least million times bigger than
network_hash_range.
The miners only know miner_hash_range, it's impossible for cheat miners
to find out which share could make a valid block or not.
Problems:
1. it's a hard fork.
2. will make existed asic dsha256 chips useless, but I think it's only a
small change to make new asic chips based on existed tech.
--94eb2c0df462c076ae055aa6794d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Here is a solution may solve Block Withholding Attack=
. The general idea is=C2=A0</div><div>came from Aviv Zohar(<a href=3D"mailt=
o:avivz@cs.huji.ac.il">avivz@cs.huji.ac.il</a>), I made it work for Bitcoin=
.=C2=A0</div><div>Anyway, thanks Aviv.</div><div><br></div><div>=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div><div><br></div>=
<div>DIFF_1 =3D 0x00000000FFFF000000000000000000000000000000000000000000000=
0000000;</div><div><br></div><div>Diff =3D DIFF_1 / target</div><div><br></=
div><div>this is equal to=C2=A0</div><div><br></div><div>Diff =3D DIFF_1 / =
(target - 0) or Diff =3D DIFF_1 / abs(target - 0)</div><div><br></div><div>=
now, we change diff algo to below:</div><div><br></div><div>New_Diff =3D DI=
FF_1 / abs(target - offset)</div><div><br></div><div>Offset is 32 bytes, li=
ke uint256 in Bitcoin, range is [0, 2^256),=C2=A0</div><div>define: offset_=
hash =3D DSHA256(offset).</div><div><br></div><div>we need to do a little c=
hange to the merkle root hash algo, put the=C2=A0</div><div>offset_hash as =
a tx hash in the front of tx hashes.</div><div><br></div><div>[offset_hash,=
coinbase_tx_hash, tx01_hash, tx02_hash, =E2=80=A6 , tx_n_hash]</div><div><=
br></div><div>Actually could put offset_hash in any place in the array of h=
ashes.</div><div><br></div><div>network_hash_range =3D network_hash_end - n=
etwork_hash_begin</div><div><br></div><div>miner_hash_range =3D miner_hash_=
end - miner_hash_begin</div><div><br></div><div>The offset value MUST betwe=
en network_hash_begin/end or miner_hash_begin/end.</div><div><br></div><div=
><a href=3D"https://user-images.githubusercontent.com/514951/31133378-e00d9=
ca2-a891-11e7-8c61-73325f59f6ed.JPG">https://user-images.githubusercontent.=
com/514951/31133378-e00d9ca2-a891-11e7-8c61-73325f59f6ed.JPG</a></div><div>=
<br></div><div>When mining pool send a job to miners, put the PoW hash rang=
e=C2=A0</div><div>(miner_hash_begin/end) in the job. So if the miners find =
a hash which value</div><div>is between [miner_hash_begin, miner_hash_end],=
means it's SHOULD be a=C2=A0</div><div>valid share, could submit the s=
hare to the pool. If the hash value is=C2=A0</div><div>between [network_has=
h_begin, network_hash_end] means find a valid block.</div><div><br></div><d=
iv>The network_diff is much much high than the miner's diff, means the=
=C2=A0</div><div>network_hash_range is much much smaller than miner_hash_ra=
nge. By now,=C2=A0</div><div>a typical miner's pool diff is around 16K,=
network diff is 1123863285132,=C2=A0</div><div>so miner_hash_range is at l=
east million times bigger than network_hash_range.=C2=A0</div><div>The mine=
rs only know miner_hash_range, it's impossible for cheat miners=C2=A0</=
div><div>to find out which share could make a valid block or not.</div><div=
><br></div><div>Problems:</div><div>1. it's a hard fork.</div><div>2. w=
ill make existed asic dsha256 chips useless, but I think it's only a sm=
all change to make new asic chips based on existed tech.</div></div>
--94eb2c0df462c076ae055aa6794d--
|
