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-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WcGL1-0002qP-Mo for bitcoin-development@lists.sourceforge.net; Mon, 21 Apr 2014 15:40:55 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.43 as permitted sender) client-ip=209.85.219.43; envelope-from=dscvlt@gmail.com; helo=mail-oa0-f43.google.com; Received: from mail-oa0-f43.google.com ([209.85.219.43]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WcGKz-0007dn-VS for bitcoin-development@lists.sourceforge.net; Mon, 21 Apr 2014 15:40:55 +0000 Received: by mail-oa0-f43.google.com with SMTP id eb12so4408532oac.30 for ; Mon, 21 Apr 2014 08:40:48 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.186.40 with SMTP id fh8mr10572obc.87.1398094848549; Mon, 21 Apr 2014 08:40:48 -0700 (PDT) Received: by 10.182.225.106 with HTTP; Mon, 21 Apr 2014 08:40:48 -0700 (PDT) In-Reply-To: References: <52CDA01B-13BF-4BB8-AC9A-5FBBB324FD15@sant.ox.ac.uk> Date: Tue, 22 Apr 2014 01:10:48 +0930 Message-ID: From: Ashley Holman To: Peter Todd Content-Type: multipart/alternative; boundary=089e0153764acf694d04f78f528a X-Spam-Score: -0.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 (dscvlt[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -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: 1WcGKz-0007dn-VS Cc: bitcoin-development@lists.sourceforge.net, Jonathan Levin Subject: Re: [Bitcoin-development] Economics of information propagation 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, 21 Apr 2014 15:40:55 -0000 --089e0153764acf694d04f78f528a Content-Type: text/plain; charset=UTF-8 On Mon, Apr 21, 2014 at 1:36 PM, Peter Todd wrote: > > That is mistaken: you can't mine on top of just a block header, leaving > small miners disadvantaged as they are earning no profit while they wait > for the information to validate the block and update their UTXO sets. This > results in the same problem as before, as the large pools who mine most > blocks can validate either instantly - the self-mine case - or more quickly > than the smaller miners. > > Under the headers first scenario, wouldn't the full block still reach everyone in the same time as it would under the current rules? So the small miner loses nothing in terms of updating their UTXO set, but gains an early "heads up" alert that a new block is coming. This allows them spend the propagation time working more productively on an empty block in the new chain rather than wasting time on an orphan. It's true that it doesn't solve the problem of larger pools vs smaller pools, but if it doesn't make it any worse then headers-first propagation would be a net benefit to the network since it removes the incentive to make small blocks. --089e0153764acf694d04f78f528a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Apr 21, 2014 at 1:36 PM, Peter Todd <pete@petertodd.org> wrote:
That is mistaken: you can't mine on top of just a block header, leaving= small miners disadvantaged as they are earning no profit while they wait f= or the information to validate the block and update their UTXO sets. This r= esults in the same problem as before, as the large pools who mine most bloc= ks can validate either instantly - the self-mine case - or more quickly tha= n the smaller miners.

=C2=A0
Under the headers first scenario, wo= uldn't the full block still reach everyone in the same time as it would= under the current rules? =C2=A0So the small miner loses nothing in terms o= f updating their UTXO set, but gains an early "heads up" alert th= at a new block is coming. =C2=A0This allows them spend the propagation time= working more productively on an empty block in the new chain rather than w= asting time on an orphan. =C2=A0It's true that it doesn't solve the= problem of larger pools vs smaller pools, but if it doesn't make it an= y worse then headers-first propagation would be a net benefit to the networ= k since it removes the incentive to make small blocks.
--089e0153764acf694d04f78f528a--