Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WoM5j-000251-6F for bitcoin-development@lists.sourceforge.net; Sun, 25 May 2014 00:15:07 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.181 as permitted sender) client-ip=209.85.217.181; envelope-from=gmaxwell@gmail.com; helo=mail-lb0-f181.google.com; Received: from mail-lb0-f181.google.com ([209.85.217.181]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WoM5h-0001Ks-Vl for bitcoin-development@lists.sourceforge.net; Sun, 25 May 2014 00:15:07 +0000 Received: by mail-lb0-f181.google.com with SMTP id q8so3570263lbi.12 for ; Sat, 24 May 2014 17:14:59 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.20.168 with SMTP id o8mr11284lae.78.1400976899255; Sat, 24 May 2014 17:14:59 -0700 (PDT) Received: by 10.112.89.68 with HTTP; Sat, 24 May 2014 17:14:59 -0700 (PDT) In-Reply-To: <53813391.7040503@gmail.com> References: <53813391.7040503@gmail.com> Date: Sat, 24 May 2014 17:14:59 -0700 Message-ID: From: Gregory Maxwell To: Alan Reiner Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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.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: 1WoM5h-0001Ks-Vl Cc: Bitcoin Development Subject: Re: [Bitcoin-development] Cut-through propagation of blocks 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: Sun, 25 May 2014 00:15:07 -0000 On Sat, May 24, 2014 at 5:04 PM, Alan Reiner wrote: > I think the most important change is modifying the way Bitcoin Core > prioritizes blocks. Right now it uses the first full block verified. > Instead, it should consider the first valid header received as highest > priority, but only mine on it once it has done full verification of the This directly opens an attack where as soon as you find a block you announce the header to the world and then you delay announcing the block content. You can continue to mine on the block but no one else can (or alternatively they break their rule and risk extending an invalid block=E2=80=94 bad news for SPV wallets)=E2=80=94 then when you fin= d a successor block or someone else finds a competing block you immediately announce the content. It basically means that you can always delay announcing a block and be sure that doing so doesn't deprive you of your winning position. > If miners are concerned about that 1-3 second gap, they > should perhaps focus on making sure the tx they are mining are > well-propagated already, so that most of the network has most of the > transactions already in their memory pool by the time their block is mine= d. With an alternative transport protocol, assuming the content has already been relayed a block could be sent in a couple back to back UDP packets. (e.g. a few bytes per transaction to disambiguate the transaction order out of the already sent transactions). So I think very similar latency could be achieved without doing any thing which might increase the motivations for miners to misbehave.