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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <watsonbladd@gmail.com>) id 1Sb1gO-00085K-9r
for bitcoin-development@lists.sourceforge.net;
Sun, 03 Jun 2012 03:40:48 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.160.47 as permitted sender)
client-ip=209.85.160.47; envelope-from=watsonbladd@gmail.com;
helo=mail-pb0-f47.google.com;
Received: from mail-pb0-f47.google.com ([209.85.160.47])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
(Exim 4.76) id 1Sb1gN-0004fV-EH
for bitcoin-development@lists.sourceforge.net;
Sun, 03 Jun 2012 03:40:48 +0000
Received: by pbbrq2 with SMTP id rq2so4443265pbb.34
for <bitcoin-development@lists.sourceforge.net>;
Sat, 02 Jun 2012 20:40:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.129.167 with SMTP id nx7mr5280920pbb.80.1338694841635; Sat,
02 Jun 2012 20:40:41 -0700 (PDT)
Sender: watsonbladd@gmail.com
Received: by 10.142.174.10 with HTTP; Sat, 2 Jun 2012 20:40:41 -0700 (PDT)
In-Reply-To: <CACsn0c=+xrVvGMAkPZffpVhRcAc09RuOW7LeOwi0TOD88VbuqQ@mail.gmail.com>
References: <201206030052.17128.luke@dashjr.org>
<CACsn0c=+xrVvGMAkPZffpVhRcAc09RuOW7LeOwi0TOD88VbuqQ@mail.gmail.com>
Date: Sat, 2 Jun 2012 22:40:41 -0500
X-Google-Sender-Auth: cFj9yNQtq3Zeqb4RplkKwU7B8vU
Message-ID: <CACsn0cmvpY49R_nt=LhPaiOSFkL=Zywd-ZkUtOR9BK=hr2h1DQ@mail.gmail.com>
From: Watson Ladd <wbl@uchicago.edu>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(watsonbladd[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Sb1gN-0004fV-EH
Subject: [Bitcoin-development] Fwd: Defeating the block withholding attack
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sun, 03 Jun 2012 03:40:48 -0000
On Sat, Jun 2, 2012 at 7:52 PM, Luke-Jr <luke@dashjr.org> wrote:
> Analysis, comments, constructive criticism, etc welcome for the following=
:
>
> =3D=3DBackground=3D=3D
> At present, an attacker can harm a pool by intentionally NOT submitting s=
hares
> that are also valid blocks. All pools are vulnerable to this attack, whet=
her
> centralized or decentralized and regardless of reward system used. The
> attack's effectiveness is proportional to ratio of the attacker's hashrat=
e to
> the rest of the pool.
This attack has an obvious signature: getting outworked on the same
block as the pool was trying to verify, and always by the same person.
>
> There are obvious solutions that can be used to defeat this attack on
> centralized pools. For example, including a secret in the coinbase transa=
ction
> that is accepted by the network as a partial preimage proof-of-work. All =
these
> solutions require changes to Bitcoin's proof-of-work acceptance terms, an=
d
> since centralized pools can be harmful to the network's security, these r=
ule
> changes are not likely to gain enough acceptance among the greater Bitcoi=
n
> community.
>
> =3D=3DProposed Solution=3D=3D
> Please comment on the viability of this new proof-of-work algorithm, whic=
h I
> think should be viable for even decentralized pools:
>
> Blocks are accepted at a lower difficulty N (choosable by the pool; eg, t=
he
> share difficulty) iff they are submitted with a candidate for the next bl=
ock
> and SHA256(SHA256(NewBlockHash + NextBlockCandidateHash)) meets difficult=
y M.
> The relationship between M and N must be comparable to the normal network
> difficulty; details on the specifics of this can be figured out later, id=
eally
> by someone more qualified than me. M and N must be chosen prior to search=
ing
> for the block: it should be safe to steal some always-zero bytes from the
> prevblock header for this.
So the goal is to prevent the attacker double-dipping by submitting
cycles to the pool, which if he
found a correct answer he could submit himself. I don't see how this
does that: if he finds a valid
block he finds a valid block. Only if the operator has a secret is
this prevented.
>
> This algorithm should guarantee that every share has an equal chance of b=
eing
> a valid block at the time it is found, and that which ones are actually b=
locks
> cannot be known until the subsequent block is found. Thus, attackers have=
no
> way to identify which shares to withhold even while they have full knowle=
dge
> of the shares/blocks themselves.
This further delays the finalization of a transaction. That's not a good th=
ing.
>
> =3D=3DBackward Compatibility=3D=3D
> Obviously, this change creates a hard-fork in the blockchain. I propose t=
hat
> if it solves the block withholding risk, the gain is sufficient that the
> community may approve a hard-fork to take place 1-2 years from consensus.
>
> Since mining continues to use a double-SHA256 on a fixed 80 byte header,
> existing miners, FPGAs, etc should work unmodified. Poolservers will need=
to
> adapt significantly.
>
> -------------------------------------------------------------------------=
-----
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither=C2=A0 Liberty nor Safety."
-- Benjamin Franklin
--=20
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither=C2=A0 Liberty nor Safety."
-- Benjamin Franklin
|
