Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of eigbox.net
	designates 66.96.188.4 as permitted sender)
	client-ip=66.96.188.4;
	envelope-from=SRS0=rXVvyT=HK=godofgod.co.uk=matthewmitchell@eigbox.net;
	helo=bosmailout04.eigbox.net; 
From: Matthew Mitchell <matthewmitchell@godofgod.co.uk>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Message-Id: <2104FC7F-0AE0-4C55-9987-B20EFCE19FC3@godofgod.co.uk>
Date: Tue, 11 Sep 2012 20:07:39 +0100
To: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\))
Sender: Matthew Mitchell <matthewmitchell@godofgod.co.uk>
Subject: Re: [Bitcoin-development] Segmented Block Relaying BIP draft.
Precedence: list

For some reason sourceforge is not sending me updates anymore but I can =
see the replies online=85

There could be a slightly more simple protocol which gives all the =
transactions hashes and nodes can then download the transactions =
separately. However there are two problems:

1. Downloading all the transactions individually might be inefficient. =
My proposal will allow nodes to request multiple transactions at once.
2. Why not add a few additional components to the protocol to allow =
requests for any level of the merkle tree? It's not very complicated at =
all and protects against the future.

Sure, analysis needs to be done to see at what point the proposal would =
give benefit and I will hopefully get around to doing some measurements =
of peer behaviour to aid with this.

I think it's a good idea to think ahead rather than only do what is =
beneficial for the network currently. The block sizes at the moment are =
about 0.1MB but what if the bitcoin demand starts pushing that into =
megabytes? And yes the ~0.95MB limit needs to be changed in order for =
bitcoin to grow that far. Why would the limit not be lifted? How will =
bitcoin demand be satisfied other than having large fees to deter =
transactions, hoping the fees are large enough to balance the demand =
with the block size limits to prevent many transactions being =
unconfirmed and annoying users? That limit has got to go eventually. And =
then it could be that block sizes do become large enough to worry about =
the performance in relaying.

Best not to leave this to the last minute, so at the very least I think =
it's good to talk about this.=