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; 
Message-ID: <BLU170-W757A725FD907FDC49BF9F2A55E0@phx.gbl>
Content-Type: multipart/alternative;
	boundary="_3823cccf-ed2a-4e2b-adbf-e246c42a35aa_"
From: Paul Lyon <pmlyon@hotmail.ca>
To: Mark Friedenbach <mark@monetize.io>, Peter Todd <pete@petertodd.org>,
	Jonathan Levin <jonathan.levin@sant.ox.ac.uk>
Date: Mon, 21 Apr 2014 13:22:48 -0300
Importance: Normal
In-Reply-To: <53554089.1010503@monetize.io>
References: <mailman.122233.1398039406.2207.bitcoin-development@lists.sourceforge.net>,
	<52CDA01B-13BF-4BB8-AC9A-5FBBB324FD15@sant.ox.ac.uk>,
	<CACh7GpFGEvR+_qArYCkgi7AW4coSeH741ob4hmBpj6G3MayNAQ@mail.gmail.com>,
	<a9a262a9-c70f-470d-81e0-ca32c41d8dc5@email.android.com>,
	<53554089.1010503@monetize.io>
MIME-Version: 1.0
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Economics of information propagation
Precedence: list

--_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

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

--_3823cccf-ed2a-4e2b-adbf-e246c42a35aa_--