Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of eigbox.net
	designates 66.96.186.17 as permitted sender)
	client-ip=66.96.186.17;
	envelope-from=SRS0=nh6BJu=HM=godofgod.co.uk=matthewmitchell@eigbox.net;
	helo=bosmailout17.eigbox.net; 
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\))
From: Matthew Mitchell <matthewmitchell@godofgod.co.uk>
In-Reply-To: <CANEZrP0HHhSXyN9pWODtTxHMfRB4B0w-eSdvNHH13WwLVgECrw@mail.gmail.com>
Date: Thu, 13 Sep 2012 15:05:29 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <FC0AF926-2CBD-49BA-A3B7-AF9D70A83CE4@godofgod.co.uk>
References: <2104FC7F-0AE0-4C55-9987-B20EFCE19FC3@godofgod.co.uk>
	<CAAS2fgSymOJ=cQnNwK9+nvRYszHHH4vtUpoQYWNNYoVaYB5Gpg@mail.gmail.com>
	<19ED4257-0BCA-41C5-A533-B0AB9B500181@godofgod.co.uk>
	<CAAS2fgRfXBrsFm_zdNFe7Z4FN7uQ5zSg++scng=hNrHZZV93VQ@mail.gmail.com>
	<CANEZrP0HHhSXyN9pWODtTxHMfRB4B0w-eSdvNHH13WwLVgECrw@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>, Gregory Maxwell <gmaxwell@gmail.com>,
	"bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Sender: Matthew Mitchell <matthewmitchell@godofgod.co.uk>
Subject: Re: [Bitcoin-development] Segmented Block Relaying BIP draft.
Precedence: list

On 13 Sep 2012, at 09:42, Mike Hearn <mike@plan99.net> wrote:

> For what it's worth I disagree with Gregory on nearly all these
> points, so don't take it as some kind of consensus from the Bitcoin
> community ;)
>=20
> Matts change is reasonable but I think we all agree it has minimal
> impact at the moment relative to other things, so something even more
> complex than that seems like a non-starter. Bloom filtering is a lot
> more important.

Sure other things may be done before this, I was seeing this as a change =
somewhere down the line but not urgent.

@Gregory

> But you only need to request the transactions you don't have. Most of
> time you should already have almost all of the transactions.

Yes, my proposal allows you to do this. You skip out transactions your =
already have. My proposal is simply better than others because it takes =
full advantage of the merkle tree structure with minor additions that =
are simple to implement. How hard is it to get the hashes at a =
particular level of a merkle tree? Not hard at all. How hard is it to =
place a selection of transactions from a block into a message Not hard =
at all. Implementation of the protocol requirements would be a piece of =
cake. The harder bit would be to create an algorithm to determine the =
best level of segmentation but this is not required to comply with the =
protocol.

> Because there is no motivation not to set them to zero, if you don't
> someone else will

The motivation to incentivise miners and maintain stronger security? The =
difficulty only has to be high enough to prevent a cartel of malicious =
miners taking control of the network, something that is potentially a =
problem today with the large mining pools. Remember that the more =
transactions there are the more fees there can be for miners to collect. =
The more people that are using bitcoin, the greater bitcoins will be =
worth. A bigger network should be good for miners when relying on fees.

> And yes, of course, you schedule the change
> for the future, but as you note that it doesn't solve the problem of
> people opposing it.

If it's so controversial that it creates a split making two separated =
currencies then I'd see it turning out like the format wars (VHS vs =
Betamax and Blu-ray vs HD-DVD). Eventually people will move towards one =
or the other since it's better for people to have universalised =
agreement on a system.=