From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VdJS0-0002ur-D7 for bitcoin-development@lists.sourceforge.net; Mon, 04 Nov 2013 12:40:12 +0000 X-ACL-Warn: Received: from 2508ds5-oebr.1.fullrate.dk ([90.184.5.129] helo=mail.ceptacle.com) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1VdJRz-0007Av-DJ for bitcoin-development@lists.sourceforge.net; Mon, 04 Nov 2013 12:40:12 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.ceptacle.com (Postfix) with ESMTP id 92D8E3678E4A; Mon, 4 Nov 2013 13:40:05 +0100 (CET) X-Virus-Scanned: amavisd-new at ceptacle.com Received: from mail.ceptacle.com ([127.0.0.1]) by localhost (server.ceptacle.private [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvQwLpFT+FWZ; Mon, 4 Nov 2013 13:40:05 +0100 (CET) Received: from MacGronager.local (cpe.xe-3-1-0-415.bynqe10.dk.customer.tdc.net [188.180.67.254]) by mail.ceptacle.com (Postfix) with ESMTPSA id 338DF3678E3F; Mon, 4 Nov 2013 13:40:04 +0100 (CET) Message-ID: <527795A0.3080400@ceptacle.com> Date: Mon, 04 Nov 2013 13:40:00 +0100 From: Michael Gronager User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mike Hearn References: <52778BCE.8030904@ceptacle.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1VdJRz-0007Av-DJ Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Auto-generated miner backbone X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 12:40:12 -0000 "We propose a simple, backwards-compatible change to the Bitcoin protocol to address this problem and raise the threshold. Specifically, when a miner learns of competing branches of the same length, it should propagate all of them, and choose which one to mine on uniformly at random." So only in the case of two competing chains... The "Selfish Miner" today has an advantage knowing which chain the other will work on, and by simply choosing the other they get their advantage making it likely that it is the other that will waste their effort. By using the random scheme this advantage is gone. Note again that it is only in the case of two competing chains, which will happen on average every 60 blocks. So it is only roughly once every 60 block that you change from choosing one chain to doing a 50% random. A rough calculation on earnings will be that you loose roughly 1/(2*60) ~ 1% of your blocks using this scheme. But at the same time you make it harder for such an attack to happen. (This number might be slightly higher, as working in parallel on both chains will make the two chains last longer, so agree that we need a bit more analysis...) I also agree that it is a kind of a Sybil attack, but I think we should accept the risk of a Sybil attack but of course minimize it, rather than introducing various social network (ip addresses) solutions, which in one way or the other always have some central auth / oracle assumption. On 4/11/13, 13:03 , Mike Hearn wrote: > The suggested change is actually very simple (minutes of coding) and > elegant and addresses precisely the identified problem. > > > Disagree. Unless I'm misunderstanding what they propose, their suggested > change would mean anyone could broadcast a newly discovered block at any > point and have a 50% chance of being the winner. That is a fundamental > change to the dynamics of how Bitcoin works that would require careful > thought and study. > > Also, their solution doesn't really address the problem they bring up, > it just changes the size of the threshold required. > > Fundamentally, their attack is a sybil attack. It doesn't work if they > can't delay or block a pools competitors because mostly their block will > come in second place and they'll lose the race. Thus the solution should > be a solution to sybil attacks.