diff options
| author | Luke-Jr <luke@dashjr.org> | 2012-06-03 00:52:14 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2012-06-03 00:52:53 +0000 |
| commit | ada354572b89e2f0e33594690608bf59737cb173 (patch) | |
| tree | d5a11764e6a6e309e8c7d3f14980dab34cc0c2c7 | |
| parent | 618bbd68c5e11a71d477022fad40f835a1239f60 (diff) | |
| download | pi-bitcoindev-ada354572b89e2f0e33594690608bf59737cb173.tar.gz pi-bitcoindev-ada354572b89e2f0e33594690608bf59737cb173.zip | |
[Bitcoin-development] Defeating the block withholding attack
| -rw-r--r-- | 0e/7a6b836702a6d5853ae83724b5f700d389ba90 | 95 |
1 files changed, 95 insertions, 0 deletions
diff --git a/0e/7a6b836702a6d5853ae83724b5f700d389ba90 b/0e/7a6b836702a6d5853ae83724b5f700d389ba90 new file mode 100644 index 000000000..801ed6fe0 --- /dev/null +++ b/0e/7a6b836702a6d5853ae83724b5f700d389ba90 @@ -0,0 +1,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. + + |