From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WcGzh-0002Mj-OB for bitcoin-development@lists.sourceforge.net; Mon, 21 Apr 2014 16:22:57 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of hotmail.ca designates 65.55.111.108 as permitted sender) client-ip=65.55.111.108; envelope-from=pmlyon@hotmail.ca; helo=blu0-omc2-s33.blu0.hotmail.com; Received: from blu0-omc2-s33.blu0.hotmail.com ([65.55.111.108]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WcGze-0005tw-GJ for bitcoin-development@lists.sourceforge.net; Mon, 21 Apr 2014 16:22:57 +0000 Received: from BLU170-W75 ([65.55.111.72]) by blu0-omc2-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Apr 2014 09:22:49 -0700 X-TMN: [mhRkwfiJVGvpp3N17HUrzouvFaQUBTNM] X-Originating-Email: [pmlyon@hotmail.ca] Message-ID: Content-Type: multipart/alternative; boundary="_3823cccf-ed2a-4e2b-adbf-e246c42a35aa_" From: Paul Lyon To: Mark Friedenbach , Peter Todd , Jonathan Levin Date: Mon, 21 Apr 2014 13:22:48 -0300 Importance: Normal In-Reply-To: <53554089.1010503@monetize.io> References: , <52CDA01B-13BF-4BB8-AC9A-5FBBB324FD15@sant.ox.ac.uk>, , , <53554089.1010503@monetize.io> MIME-Version: 1.0 X-OriginalArrivalTime: 21 Apr 2014 16:22:49.0160 (UTC) FILETIME=[EFBEFC80:01CF5D7D] X-Spam-Score: -0.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 (pmlyon[at]hotmail.ca) -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [65.55.111.108 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1WcGze-0005tw-GJ Cc: "bitcoin-development@lists.sourceforge.net" 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 16:22:57 -0000 --_3823cccf-ed2a-4e2b-adbf-e246c42a35aa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I haven't done the math on this=2C so it may be a terrible idea. :) I've been wondering if block propagation times could also be improved by al= lowing peers to request the list of transaction hashes that make up a block= =2C and then making a follow-up request to only download any transactions n= ot currently known. I'm not sure what percentage of transactions a node wil= l usually already have when it receives a new block=2C but if it's high I f= igure this could be beneficial. > Date: Mon=2C 21 Apr 2014 09:00:09 -0700 > From: mark@monetize.io > To: pete@petertodd.org=3B jonathan.levin@sant.ox.ac.uk > CC: bitcoin-development@lists.sourceforge.net > Subject: Re: [Bitcoin-development] Economics of information propagation >=20 > That wasn't what I was saying. Right now the primacy of a block is > determined by the time at which the `block` message is received=2C which > is delays due to both the time it takes to transmit the block data and > the time it takes to validate. Headers-first=2C on the other hand=2C has = the > option of basing primacy on the time the block header is received=2C whic= h > is O(1) time to transmit and to SPV-validate. Mining on that block > doesn't actually commence until the full block is received and validated. >=20 > To see how this works=2C take an example: two blocks with a common parent > are found relatively close to each other=2C block A and block B. A is > found first but is a large block with the maximum block size and many > slow scripts. B is found a few seconds later and is an empty block. In > the current regime it is entirely possible that block B=2C the later but > smaller block=2C would get received and processed first by more mining > peers than the larger block A=2C exactly as described in Jonathan Levin's > email. >=20 > With headers-first=2C however=2C the cost of propagation of the block hea= der > is the same and we should expect block A to win out over block B nearly > every time. Miners will continue working on the old=2C known valid parent > block until the contents of block A are received and processed. So the > smaller block B is still found=2C and since it's data moves across the > network faster=2C miners even briefly mine on block B. But as soon as the= y > receive and process the contents of block A=2C they switch to that. >=20 > The earlier=2C larger block A will only become stale if *two* blocks are > found in the extra time it takes for block A to propagate the network. > That is a substantially different risk=2C and probably a negligible > concern to most miners. >=20 > On 04/20/2014 09:06 PM=2C Peter Todd wrote: > > That is mistaken: you can't mine on top of just a block header=2C > > 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=2C as the > > large pools who mine most blocks can validate either instantly - the > > self-mine case - or more quickly than the smaller miners. > >=20 > > Of course=2C in reality smaller miners can just mine on top of block > > headers and include no transactions and do no validation=2C but that is > > extremely harmful to the security of Bitcoin. >=20 > -------------------------------------------------------------------------= ----- > Start Your Social Network Today - Download eXo Platform > Build your Enterprise Intranet with eXo Platform Software > Java Based Open Source Intranet - Social=2C Extensible=2C Cloud Ready > Get Started Now And Turn Your Intranet Into A Collaboration Platform > http://p.sf.net/sfu/ExoPlatform > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development = --_3823cccf-ed2a-4e2b-adbf-e246c42a35aa_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I haven't done the math on this= =2C so it may be a terrible idea. :)

I've been wondering= if block propagation times could also be improved by allowing peers to req= uest the list of transaction hashes that make up a block=2C and then making= a follow-up request to only download any transactions not currently known.= I'm not sure what percentage of transactions a node will usually already h= ave when it receives a new block=2C but if it's high I figure this could be= beneficial.

>=3B Date: Mon=2C 21 Apr 2014 09:00:09 -0700
= >=3B From: mark@monetize.io
>=3B To: pete@petertodd.org=3B jonathan.= levin@sant.ox.ac.uk
>=3B CC: bitcoin-development@lists.sourceforge.net=
>=3B Subject: Re: [Bitcoin-development] Economics of information prop= agation
>=3B
>=3B That wasn't what I was saying. Right now the p= rimacy of a block is
>=3B determined by the time at which the `block` = message is received=2C which
>=3B is delays due to both the time it ta= kes to transmit the block data and
>=3B the time it takes to validate.= Headers-first=2C on the other hand=2C has the
>=3B option of basing p= rimacy on the time the block header is received=2C which
>=3B is O(1) = time to transmit and to SPV-validate. Mining on that block
>=3B doesn'= t actually commence until the full block is received and validated.
>= =3B
>=3B To see how this works=2C take an example: two blocks with a = common parent
>=3B are found relatively close to each other=2C block A= and block B. A is
>=3B found first but is a large block with the maxi= mum block size and many
>=3B slow scripts. B is found a few seconds la= ter and is an empty block. In
>=3B the current regime it is entirely p= ossible that block B=2C the later but
>=3B smaller block=2C would get = received and processed first by more mining
>=3B peers than the larger= block A=2C exactly as described in Jonathan Levin's
>=3B email.
&g= t=3B
>=3B With headers-first=2C however=2C the cost of propagation of= the block header
>=3B is the same and we should expect block A to win= out over block B nearly
>=3B every time. Miners will continue working= on the old=2C known valid parent
>=3B block until the contents of blo= ck A are received and processed. So the
>=3B smaller block B is still = found=2C and since it's data moves across the
>=3B network faster=2C m= iners even briefly mine on block B. But as soon as they
>=3B receive a= nd process the contents of block A=2C they switch to that.
>=3B
&g= t=3B The earlier=2C larger block A will only become stale if *two* blocks a= re
>=3B found in the extra time it takes for block A to propagate the = network.
>=3B That is a substantially different risk=2C and probably a= negligible
>=3B concern to most miners.
>=3B
>=3B On 04/20= /2014 09:06 PM=2C Peter Todd wrote:
>=3B >=3B That is mistaken: you = can't mine on top of just a block header=2C
>=3B >=3B leaving small = miners disadvantaged as they are earning no profit
>=3B >=3B while t= hey wait for the information to validate the block and update
>=3B >= =3B their UTXO sets. This results in the same problem as before=2C as the>=3B >=3B large pools who mine most blocks can validate either instan= tly - the
>=3B >=3B self-mine case - or more quickly than the smalle= r miners.
>=3B >=3B
>=3B >=3B Of course=2C in reality smalle= r miners can just mine on top of block
>=3B >=3B headers and include= no transactions and do no validation=2C but that is
>=3B >=3B extre= mely harmful to the security of Bitcoin.
>=3B
>=3B -------------= -----------------------------------------------------------------
>=3B= Start Your Social Network Today - Download eXo Platform
>=3B Build yo= ur Enterprise Intranet with eXo Platform Software
>=3B Java Based Open= Source Intranet - Social=2C Extensible=2C Cloud Ready
>=3B Get Starte= d Now And Turn Your Intranet Into A Collaboration Platform
>=3B http:/= /p.sf.net/sfu/ExoPlatform
>=3B _______________________________________= ________
>=3B Bitcoin-development mailing list
>=3B Bitcoin-devel= opment@lists.sourceforge.net
>=3B https://lists.sourceforge.net/lists/= listinfo/bitcoin-development
= --_3823cccf-ed2a-4e2b-adbf-e246c42a35aa_--