Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of googlemail.com
	designates 209.85.215.193 as permitted sender)
	client-ip=209.85.215.193;
	envelope-from=john.dillon892@googlemail.com;
	helo=mail-ea0-f193.google.com; 
MIME-Version: 1.0
In-Reply-To: <CAE-z3OWBoMz6jC36Bp+dGqj6jHiWj1d1zGtH+iBbLcCt_6kNJw@mail.gmail.com>
References: <CAE-z3OX+Uzw_diW97yKWGzVMBFZHq2t+w15jNSdGMGqwyJ65yQ@mail.gmail.com>
	<20130724094255.GB12568@savin>
	<CAE-z3OWBoMz6jC36Bp+dGqj6jHiWj1d1zGtH+iBbLcCt_6kNJw@mail.gmail.com>
Date: Sun, 28 Jul 2013 18:42:26 +0000
Message-ID: <CAPaL=UVc0CGvvam0tdxw+4Y8XwSw0Awz8ifv64HYgORJ7zLztg@mail.gmail.com>
From: John Dillon <john.dillon892@googlemail.com>
To: Tier Nolan <tier.nolan@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Distributing low POW headers
Precedence: list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Jul 24, 2013 at 11:55 AM, Tier Nolan <tier.nolan@gmail.com> wrote:
> Distributing headers with 1/64 of the standard POW means that a header would
> be broadcast approximately once every 9 seconds (assuming a 10 minute block
> time).  This was picked because sending 80 byte headers every 9 seconds
> shouldn't represent much load on the network.

As Peter said, "much" should be quantified.

Remember that there is a statistical distribution here, what is the probability
of how many seconds per headers?

> This creates an incentive for miners to take headers into account.  If all
> the headers were worth less than a full block, then a fork which was losing
> would suddenly be winning if a block is found.  A fork will only become the
> main chain due to a new block, if it is within 16 mini-confirms.

Sounds like you are changing economics and requiring miners to have even better
network connections. This is not a thing to do lightly and it probably a bad
idea.

> Second, if a header builds on a header that is in the header tree, then it
> is broadcast, even if it doesn't meet full POW (only 1/64 required).  This
> gives information on which fork is getting the most power.
>
> It gives information about potential "consensus loss" forks, where a
> significant number of miners are following an alternative chain.
>
> In fact, this is probably worth doing as an initial step.

I understand Pieter Wuille is working on letting Bitcoin propagate and make use
of pure block headers, a step towards SPV and partial UTXO mode.

Orphan measurement would be very useful for a lot of reasons, how about you
think about that first? It wouldn't have the potential data rate issues either
and should be a very simple change. Just set some threshold relative to the
height of the best block where you will not further propagate and orphan
block(header) and prior to that limit do so freely. I believe the change would
be 100% compatible with the P2P protocol as it is based on inventories.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBCAAGBQJR9WXdAAoJEEWCsU4mNhiPBUYIALgg3ylA5mkciT3W/kb+qXCp
spYlPwAU/HVUrd/p6Ra6xAOOa224BE018FHRx7cJ31AQdVPsKhC1XiQCeYMv14Cj
5LstO2VTzxLovfs1lTVnekt+xVo6EHP47Qhmhdfo1AQWHS2njIp2lT9gAlNgMYoI
Twu0FLfJFwg14HlueLhTNvGo3TeVpGhTV3HYTbjWGBuPeroaaPCKKQOy/jmA9mnZ
1x4MjQZ+AkGA3+vrinyRZ1FQsp1pOUZMZx5UFYDOOPS3TysxttiHF/Vkdmy9dNVf
5zbXrEDImlariRnyxCf6sn4Fpu9H9bt6yttCez6NHqAoZCwciXyo+UrZjFawSVg=
=8gci
-----END PGP SIGNATURE-----