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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <luke@dashjr.org>) id 1Saz3t-0003RR-Bn
for bitcoin-development@lists.sourceforge.net;
Sun, 03 Jun 2012 00:52:53 +0000
X-ACL-Warn:
Received: from zinan.dashjr.org ([173.242.112.54])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Saz3r-0000XN-E5 for bitcoin-development@lists.sourceforge.net;
Sun, 03 Jun 2012 00:52:53 +0000
Received: from ishibashi.localnet (unknown [97.96.85.141])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 4E26E56062D
for <bitcoin-development@lists.sourceforge.net>;
Sun, 3 Jun 2012 00:52:45 +0000 (UTC)
From: "Luke-Jr" <luke@dashjr.org>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Date: Sun, 3 Jun 2012 00:52:14 +0000
User-Agent: KMail/1.13.7 (Linux/3.2.12-gentoonestfix-intelwr; KDE/4.8.1; x86_64;
; )
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <201206030052.17128.luke@dashjr.org>
X-Spam-Score: -0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1Saz3r-0000XN-E5
Subject: [Bitcoin-development] 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 00:52:53 -0000
Analysis, comments, constructive criticism, etc welcome for the following:
==Background==
At present, an attacker can harm a pool by intentionally NOT submitting shares
that are also valid blocks. All pools are vulnerable to this attack, whether
centralized or decentralized and regardless of reward system used. The
attack's effectiveness is proportional to ratio of the attacker's hashrate to
the rest of the pool.
There are obvious solutions that can be used to defeat this attack on
centralized pools. For example, including a secret in the coinbase transaction
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, and
since centralized pools can be harmful to the network's security, these rule
changes are not likely to gain enough acceptance among the greater Bitcoin
community.
==Proposed Solution==
Please comment on the viability of this new proof-of-work algorithm, which I
think should be viable for even decentralized pools:
Blocks are accepted at a lower difficulty N (choosable by the pool; eg, the
share difficulty) iff they are submitted with a candidate for the next block
and SHA256(SHA256(NewBlockHash + NextBlockCandidateHash)) meets difficulty 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, ideally
by someone more qualified than me. M and N must be chosen prior to searching
for the block: it should be safe to steal some always-zero bytes from the
prevblock header for this.
This algorithm should guarantee that every share has an equal chance of being
a valid block at the time it is found, and that which ones are actually blocks
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 knowledge
of the shares/blocks themselves.
==Backward Compatibility==
Obviously, this change creates a hard-fork in the blockchain. I propose that
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.
|
