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 1VdMXm-0005p1-JY for bitcoin-development@lists.sourceforge.net; Mon, 04 Nov 2013 15:58:22 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.53 as permitted sender) client-ip=209.85.215.53; envelope-from=gmaxwell@gmail.com; helo=mail-la0-f53.google.com; Received: from mail-la0-f53.google.com ([209.85.215.53]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VdMXl-00006b-QQ for bitcoin-development@lists.sourceforge.net; Mon, 04 Nov 2013 15:58:22 +0000 Received: by mail-la0-f53.google.com with SMTP id eh20so3308464lab.12 for ; Mon, 04 Nov 2013 07:58:15 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.1.70 with SMTP id 6mr126759lak.60.1383580695061; Mon, 04 Nov 2013 07:58:15 -0800 (PST) Received: by 10.112.63.164 with HTTP; Mon, 4 Nov 2013 07:58:15 -0800 (PST) In-Reply-To: <52778BCE.8030904@ceptacle.com> References: <52778BCE.8030904@ceptacle.com> Date: Mon, 4 Nov 2013 07:58:15 -0800 Message-ID: From: Gregory Maxwell To: Michael Gronager Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.6 (-) 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 (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: ceptacle.com] -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1VdMXl-00006b-QQ Cc: Bitcoin Development 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 15:58:22 -0000 On Mon, Nov 4, 2013 at 3:58 AM, Michael Gronager wrote: > The suggested change is actually very simple (minutes of coding) and > elegant and addresses precisely the identified problem. It is actually a > mental shortcut in the assumption of how probability works when mining a > chain. The paper simply corrects this error - nice work! This isn't so. Their solution creates a weaker form of the vulnerability at all times, not just when the attacker has a informational/positional advantage. Normally delaying your blocks is negative expectation because you will get orphaned by blocks that are announced before you most of the time because miners extend the first seen. However, if you can position yourself all over the network you can condition your announcements on other blocks being announced and still win the race even if you delayed. Eliminating the first seen rule means that a miner with enough hashpower (including the largest pools existing today) could execute this attack without positioning themselves all over the network, the improvement is that a low hashrate attacker couldn't do as well, even with positioning themselves all over the network. I don't think this can be described as "simply corrects the error". The largest pool would gain an advantage in delaying their blocks and would receive a superliner share of mining income from doing so, something they can't simply do today without attacking the network. At the moment I believe we can improve the situation with propagation advantage without the other changes, so we should do that first while thinking carefully about this. Simply relaying late blocks might be fine, if anything it would at least make it easier to keep reliable orphan stats... though I'm concerned with the bandwidth overhead and risk of flooding if its not implemented carefully.