Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.53 as permitted sender)
	client-ip=74.125.82.53; envelope-from=mh.in.england@gmail.com;
	helo=mail-wg0-f53.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <CANEZrP0kNZDByHpK2=UjP+ag0X1KmqHxnJdm=e_pWMitP4QvvA@mail.gmail.com>
References: <CA+8xBpecVQcTTbPxUm_3_GWC99dEd4=-VFWb+QT6jUy4rg8U4w@mail.gmail.com>
	<CANEZrP0kNZDByHpK2=UjP+ag0X1KmqHxnJdm=e_pWMitP4QvvA@mail.gmail.com>
Date: Fri, 15 Jun 2012 13:52:56 +0200
Message-ID: <CANEZrP0Tuzax2y9rjKmj12KP31ac96QaiuGYOxe2FnFBNu9jUA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Jeff Garzik <jgarzik@exmulti.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] New P2P commands for diagnostics,
	SPV clients
Precedence: list

> Need to specify the format of how these arrive. It means that when a
> new block is found instead of inv<->getdata<->block we'd see something
> like =C2=A0inv<->getdata<->merkleblock where a "merkleblock" structure is=
 a
> header + list of transactions + list of merkle branches linking them
> to the root.

Thinking about it some more and re-reading the Scalability wiki page,
I remembered that a nice bandwidth optimization to the protocol is to
distribute blocks as header+list of tx hashes. If a node has already
seen that tx before (eg, it's in the mempool) there is no need to send
it again.

With the new command to download the contents of the mempool on
startup, this means that blocks could potentially propagate across the
network faster as download time is taken out of the equation, and
indeed, with the signature cache the hard work of verifying is already
done. So this could also help reduce orphan blocks and spurious chain
splits.

Are you planning on implementing any of this Jeff? I think we have the
opportunity to kill a few birds with one or two stones.