From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VeVpt-0004HP-TW for bitcoin-development@lists.sourceforge.net; Thu, 07 Nov 2013 20:05:49 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.172 as permitted sender) client-ip=209.85.215.172; envelope-from=adam.back@gmail.com; helo=mail-ea0-f172.google.com; Received: from mail-ea0-f172.google.com ([209.85.215.172]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VeVps-0002tj-Ku for bitcoin-development@lists.sourceforge.net; Thu, 07 Nov 2013 20:05:49 +0000 Received: by mail-ea0-f172.google.com with SMTP id r16so602517ead.3 for ; Thu, 07 Nov 2013 12:05:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=zCE8XpFGawSvFrmBDAaESesEWGBsKC4rtjw9k0/kqTw=; b=AWy+gBLpz6hc8PCnzTLUTOI2s1jyoOqSOScVwfh0tnbrg2tJUx7nHIIZeCiVH/0hWA Y6JrPkN1bEuii5v9YJ0FA0E1vFjNw7xPCm1Z1oKlpFLKD8lM4x3CiLXsjcdC18urDTPx uwpKs2nWIPcmhSnw2Y2UAPLMZmxXGSChovi85IZLUDSF+pc2KzDHcPRF+KSf6LAbRjTG Gi2BuflNVhE17T6lD4jJUMav2YoDrg9q8jO1iGQjcGntgnskH0t3egbkIdQfah3mxrbq pTqy/STCsNdsh0vgVlQTDWXH4kH09/KFt/Mm3VcI4QELY1trjFxP1icmeNF6Cpqbu/bQ u/fg== X-Received: by 10.15.41.3 with SMTP id r3mr4105632eev.74.1383854742267; Thu, 07 Nov 2013 12:05:42 -0800 (PST) Received: from netbook (c83-90.i07-21.onvol.net. [92.251.83.90]) by mx.google.com with ESMTPSA id a6sm13335705eei.10.2013.11.07.12.05.40 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 12:05:41 -0800 (PST) Received: by netbook (Postfix, from userid 1000) id 007472E288B; Thu, 7 Nov 2013 21:05:38 +0100 (CET) Received: by flare (hashcash-sendmail, from uid 1000); Thu, 7 Nov 2013 21:05:34 +0100 Date: Thu, 7 Nov 2013 21:05:34 +0100 From: Adam Back To: Ittay Message-ID: <20131107200534.GA27068@netbook.cypherspace.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Hashcash: 1:20:131107:ittay.eyal@cornell.edu::zO1b9WwN6O58wj9E:000000000000000 0000000000000000000000001U6U X-Hashcash: 1:20:131107:bitcoin-development@lists.sourceforge.net::8hozK4W0GuAMT s7s:000000000000000000002z8Q X-Hashcash: 1:20:131107:gavin@bitcoinfoundation.org::ZJEzIt0Ngu1V/bCX:0000000000 000000000000000000000000EGPm X-Hashcash: 1:20:131107:egs@systems.cs.cornell.edu::SKWz3XKUsP0HLStF:00000000000 0000000000000000000000005MKt X-Hashcash: 1:20:131107:adam@cypherspace.org::P8IWZF2Y0Y8cikMP:00000000000000000 00000000000000000000000053qn X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (adam.back[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1VeVps-0002tj-Ku Cc: Bitcoin Dev , Gavin Andresen , Emin =?iso-8859-1?B?R/xu?= Sirer Subject: [Bitcoin-development] comments on selfish-mining model (Re: BIP proposal - patch to raise selfish mining threshold.) 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: Thu, 07 Nov 2013 20:05:50 -0000 (Talking about the paper, not the BIP). With regard to racing the other winner which catches up when private pool length=1: i) the model does not appear to take into account that when another pool goes on to mine a block, and the attacker publishes their selfishly-withheld block, the selfish pool will not be able to change the existing winners mind. This is not insignificant as the pools have 30%, 20%, 15%, 7% etc. ii) The miners already have an incentive, as other big bitcoin processors, to maintain fast, secure and redundant links to other significant miners. The attacker is giving up a large proportion of their winnings from the times that they win at all. Say the attacker IS the 30% pool, when he wins and waits for someone else to win, > 80% of the network is pool mined, so there is a good chance that the other winner individually represents a non-negligible proportion of the network or a sufficiently well connected portion of the network that the attacker will be unable to race them to publication with a useful proportion of the network. iii) Also broadcast is not instantaneous, lets say network propagation takes 10 seconds; a big proportion of the time, the actual mining times will be more than 5 seconds apart so that by the time the selfish miner learns of the block, much of the network will already have accepted it block as first. iv) Even within the 10 seconds ambiguity period, the more powerful miner will tend statistically to come first, and so reach a bigger portion of the network, as well as having a stronger incentive to maintain links as in ii). These four factors erode the achievable \gamma parameter. I suspect it unlikely \gamma>0.5 would be achievable, putting the profitable threshold \alpha in 25% - 33%. (And assuming whatever techniques to reduce latency are used by the selfish pools can be used by other pools.) Your main result that even with \gamma=0 (if you dont win any races) that you still win once the selfish pool reaches 33% is an important new indication, which needs further consideration. (And you could expect to win some percentage \gamma>0 even with the factors I mention, and full implementation of the same latency reduction techniques in all moderate sized miners, selfish and normal). It is also not clear what will happen if multiple selfish miners compete with each other. A selfish miner cooperating as a peer to increase percentage runs risk of mutual sabotage - he has to announce his private block to his co-conspirator, and the co-conspirator may publish, or collude with another non-selfish miner. Your supposition is there is a profit motive to collude. However there are other profit motives in bitcoin that are not exercised - for example there were for sometime 2 pools that had excess of 50% power, and yet this was not abused for double spending. Of course increasing profit by a new mining strategy is not theft as double spending which has a clear loser. Miners even exercised restraint and volutarily avoided growing over 50%. As others have I think said by now analysis is welcome. It seems that Peter Todd may have observed the same or something similar wrt miner incentives some months ago, though it wasnt as widely read nor formally verified. It might be useful to release the source for your simulator if that is open to you. In my opinion a constructive direction for reducing centralization risks is to try to reduce the use of and motivation for pools. Even at <51% per pool there is (probabilistic) miner risk in double-spends. And there is risk that the large miners evolve to become a defacto policy enforcement point for policies not aligned with user interests, or with fungibility of bitcoin which itself presents another kind of risk (defacto reduced fungibility should this arise would also be bad for bitcoin). Also without even having mining power, there is scope to network hacking (eg of routers in front of miners) to influence the mining profit, and even double spend. As I mentioned large miners have an incentive to maintain secure redudant links (probably some links using Tor for blocks) as a counter-measure. Adam On Tue, Nov 05, 2013 at 11:56:53AM -0500, Ittay wrote: > Hello, > Please see below our BIP for raising the selfish mining threshold. > Looking forward to your comments.