Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 63B63EC0 for ; Sat, 19 Dec 2015 19:30:47 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mcelrath.org (moya.mcelrath.org [50.31.3.130]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B42BB125 for ; Sat, 19 Dec 2015 19:30:46 +0000 (UTC) Received: from mcelrath.org (localhost [127.0.0.1]) by mcelrath.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id tBJJUjPX023656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 19 Dec 2015 19:30:45 GMT Received: (from mcelrath@localhost) by mcelrath.org (8.14.3/8.14.3/Submit) id tBJJUjBt023655; Sat, 19 Dec 2015 19:30:45 GMT X-Authentication-Warning: mcelrath.org: mcelrath set sender to bob_bitcoin@mcelrath.org using -f Date: Sat, 19 Dec 2015 19:30:45 +0000 From: Bob McElrath To: Peter Todd Message-ID: <20151219193045.GP20063@mcelrath.org> References: <20151219184240.GB12893@muck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151219184240.GB12893@muck> User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] We need to fix the block withholding attack X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2015 19:30:47 -0000 Peter Todd via bitcoin-dev [bitcoin-dev@lists.linuxfoundation.org] wrote: > One of the issues raised by the pools present was block withholding > attacks, which they said are a real issue for them. In particular, pools > are receiving legitimate threats by bad actors threatening to use block > withholding attacks against them. The only possible other bad actors are other miners. So who are the "bad actor" miners? It's a short list of candidates. > P2Pool is often brought up as a replacement for pools, but it itself is still > relatively vulnerable to block withholding, and in any case has many other > vulnerabilities and technical issues that has prevented widespread adoption of > P2Pool. I've been trying to understand this source of "vulnerabilities and technical issues" with p2pool and have received a lot of contradictory information. Can someone in the know summarize what the problems with p2pool are? The economic situation where miners can be deprived of profit due to the lack of synchronicity in block updates is a physics problem due to the size of the Earth and will never be removed. This is a design flaw in Bitcoin. Therefore a different, more comprehensive solution is called for. My solution to this is somewhat longer term and needs more simulation but fundamentally removes the source of contention and fixes the design flaw, while remaining as close "in spirit" to bitcoin as possible: https://scalingbitcoin.org/hongkong2015/presentations/DAY2/2_breaking_the_chain_1_mcelrath.pdf Not only does block withholding simply not work to deny other miners income due to the absence of orphans, but I explicitly added a dis-incentive against withholding blocks in terms of the "cohort difficulty". Other graph-theoretic quantities are in general possible in the reward function to better align the incentives of miners with the correct operation of the system. Also by lowering the target difficulty and increasing the block (bead) rate, one lowers the variance of miner income. Part of the reason I ask is that there has been some interest in testing my ideas in p2pool itself (or a new similar share pool), but I'm failing to understand the source of all the complaints about p2pool. -- Cheers, Bob McElrath "For every complex problem, there is a solution that is simple, neat, and wrong." -- H. L. Mencken