From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Xba42-0005dZ-5v for bitcoin-development@lists.sourceforge.net; Tue, 07 Oct 2014 19:04:50 +0000 X-ACL-Warn: Received: from p3plsmtpa11-08.prod.phx3.secureserver.net ([68.178.252.109]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Xba41-0002q7-3b for bitcoin-development@lists.sourceforge.net; Tue, 07 Oct 2014 19:04:50 +0000 Received: from [192.168.0.23] ([201.231.95.129]) by p3plsmtpa11-08.prod.phx3.secureserver.net with id 0K4h1p00B2nUpUh01K4iE1; Tue, 07 Oct 2014 12:04:43 -0700 Message-ID: <54343948.1030400@certimix.com> Date: Tue, 07 Oct 2014 16:04:40 -0300 From: Sergio Lerner User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: bitcoin-development References: <543438E4.8080501@certimix.com> In-Reply-To: <543438E4.8080501@certimix.com> X-Enigmail-Version: 1.4.6 X-Forwarded-Message-Id: <543438E4.8080501@certimix.com> Content-Type: text/plain; charset=ISO-8859-1 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. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [68.178.252.109 listed in list.dnswl.org] X-Headers-End: 1Xba41-0002q7-3b Subject: Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT) 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: Tue, 07 Oct 2014 19:04:50 -0000 On 06/10/2014 08:43 p.m., Tom Harding wrote: > On 10/5/2014 4:00 PM, Sergio Lerner wrote: >> If everyone acts rationally in his own interest, then the best choice >> for the remaining miners is to try to mine a competing block at the >> same height n including the high-fee transaction, to collect the fee >> for themselves. > > Sergio -- > > Just some thoughts on your interesting problem. > > > Since everybody but M10 is on equal footing, I would expect M10 to > have some fixed advantage depending on assumptions, and the bigger the > advantage, the shorter the "freeze time". > Yes, that's how simulation works. The problem is that the existence of high-fee delays the decision to switch to M10. Since the network is moving slower (because of fragmentation) the effect of the high-fee is twofold: it delays the convergence because it promotes selfishness and it delays convergence because it promotes fragmentation. During that time window where the network is frozen, any other high-fee transaction only makes things worse. This is a very rare example where a well distributed network (100 miners having 1% each) is much much worse than 3 miners having 33% each. Using the my previous terminology, automatic fee-sharing ("ORBS") is a solution to the freeze problem ("FRONT") but opens the windows to "CHAKIDO" double-spending. and CHAKIDO double-spending is a much worse problem than FRONT. But as Tamas pointed out, sooner or later someone will implement something like ORBS, get over the critical mass of miner adoption, and then the CHAKIDO problem will be inevitable. The only clean solution to this problem is the DECOR+ protocol, which shares block-rewards by including "uncles" (as GHOST does) and splitting the reward between all miners at the same height until coinbase maturity is over. This way the best choice is always cooperative. PS: Using so many acronyms makes arguments much more concise, but suggest we should have all the attack terminology described in a single "Bitcoin Security Wiki"...