Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 493E510AA for ; Sat, 26 Dec 2015 00:45:53 +0000 (UTC) X-Greylist: delayed 00:08:08 by SQLgrey-1.7.6 Received: from outpost.bitwarp.com (outpost.bitwarp.com [144.76.39.233]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7D32FE0 for ; Sat, 26 Dec 2015 00:45:52 +0000 (UTC) To: bitcoin-dev@lists.linuxfoundation.org References: <20151219184240.GB12893@muck> <219f125cee6ca68fd27016642e38fdf1@xbt.hk> <20151220132842.GA25481@muck> From: Geir Harald Hansen X-Enigmail-Draft-Status: N1110 Message-ID: <567DE16E.8040001@bitminter.com> Date: Sat, 26 Dec 2015 01:38:06 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sat, 26 Dec 2015 02:27:42 +0000 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, 26 Dec 2015 00:45:53 -0000 On 20.12.2015 18:00, Emin Gün Sirer via bitcoin-dev wrote: > Instead, we will have the bigger > pools become more suspicious of signing up new hash power, which is a > good thing. Block withholding attacks do not differentiate between small and large pools. When Eligius and BTCGuild got hit with this, they were far from the biggest pools at the time. When my pool, Bitminter, got a new large miner who found 1 block where average luck would have had them find 3, one of the other miners claimed they must be withholding blocks. Even if there is no logic or evidence behind it, after one person cries wolf the others get nervous. This way even the possibility of block withholding can keep smaller pools from growing. It takes more hashpower to put a dent in a bigger pool, so you will see less such panic. > And we will have small groups of people who have some reason > for trusting each other (e.g. they know each other from IRC, conferences, > etc) band together into small pools. These are fantastic outcomes for > decentralization. Three guys with 1 TH/s, 2 TH/s and 100 GH/s meet at a conference and decide to start a private pool? Obviously that doesn't work. Maybe three people with huge warehouses of miners would work together if they knew and trusted each other. Those small miners need to mine with people they don't know to get an acceptable variance. If you kill off mining pools then small miners have no way to achieve acceptable variance and they will disappear. There will only be big warehouse miners left, the ones who are big enough to solo mine. That's not helping decentralization. > Right, it's not clear at all that yelling at people has much effect. As much > fun as I had going to that meeting with GHash in London to ask them to > back down off of the 51% boundary, I am pretty sure that yelling at large > open pools will not scale. We needed better mechanisms for keeping pools > in check. I agree. It's very disappointing how most miners and pools handle this (BTCGuild being the exception). But I do not think block withholding is a good tool. It can easily destroy small pools, but it won't put a dent in a pool that goes over 50%. Block withholding is a tool big pools can use to put smaller competitors out of business. And even if it was effective I would not use block withholding to attack other pools. > And Miner's Dilemma (MD) attacks are clearly quite effective. This is a > time when we should count our blessings, not work actively to render > them inoperable. Is it? Is there any example of block withholding leading to more decentralized mining? If I remember right, GHash being too big ended with BitFury moving some of their hashpower out of the pool. I don't know where that hashpower went and whether the problem was solved or merely hidden. GHash profitability being very low for some time wasn't due to block withholding, it was a bug that some miners abused to get paid for the same work multiple times. This made it look like a lot of work was done while finding few blocks. > Basically you have the pool pick a secret k for each share, and commit > to H(k) in the share. Additionally the share commits to a target divider > D. The PoW validity rule is then changed from H(block header) < T, to be > H(block header) < T * D && H(H(block header) + k) < max_int / D > > > Thanks, this requires a change to the Bitcoin PoW. Good luck with that! > > Once again, this suggestion would make the GHash-at-51% situation > possible again. Working extra hard to re-enable those painful days > sounds like a terrible idea. Block withholding didn't solve the problem back then. And guess what, those painful days are here right now. China is at 65% and block withholding isn't solving it. I was disappointed when GHash got too big and refused to do anything. It was sad when their miners didn't do anything. Then they used double-spends to scam a casino. I was shocked that noone cared. Now two thirds of the bitcoin hashpower is within the control of a single government. This time I expected noone would care - but I'm still disappointed. I'm also surprised at the irrational behavior; there are so many who go out of their way to put their own investments in danger. For a long time now many miners and pools have been irresponsible with the hashpower. But block withholding just makes it worse. Regards, Geir H. Hansen, Bitminter mining pool