Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of eigbox.net
	designates 66.96.188.16 as permitted sender)
	client-ip=66.96.188.16;
	envelope-from=SRS0=rXVvyT=HK=godofgod.co.uk=matthewmitchell@eigbox.net;
	helo=bosmailout16.eigbox.net; 
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\))
From: Matthew Mitchell <matthewmitchell@godofgod.co.uk>
In-Reply-To: <CAAS2fgSymOJ=cQnNwK9+nvRYszHHH4vtUpoQYWNNYoVaYB5Gpg@mail.gmail.com>
Date: Tue, 11 Sep 2012 22:48:43 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <19ED4257-0BCA-41C5-A533-B0AB9B500181@godofgod.co.uk>
References: <2104FC7F-0AE0-4C55-9987-B20EFCE19FC3@godofgod.co.uk>
	<CAAS2fgSymOJ=cQnNwK9+nvRYszHHH4vtUpoQYWNNYoVaYB5Gpg@mail.gmail.com>
To: 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 11 Sep 2012, at 20:42, Gregory Maxwell <gmaxwell@gmail.com> wrote:

> Someone can do that just by pipelining the one at a time requests.
> How much bandwidth do you think you could save over that?

You wouldn't need to pipeline the requests, just place more than one =
inventory vector in get data, right? Well my messages would save the =
space of those inventory vectors. Instead of needing 36 byte inventory =
vectors for each transaction and a var int, you would need two var ints =
only. And then the transaction responses only need one header, so you =
save 24 bytes for each transaction after the first. You could say that =
is a small benefit.
=20
> I don't see what value this provides.  For protecting against the
> future you might as well suggest uploading x86 code which gets
> executed to select transactions. "Protects against the future".  Can
> you clarify some more about exactly how you think it would help?

Well it depends on wether you seriously think bitcoin blocks should be =
limited at a million bytes or not.

> it's not clear to me how your proposal is really all that useful for
> very large blocks: I looks like it would lot of bytes sending
> redundant tree data.

Look at bittorrent. With bittorrent you don't download files from a =
single peer all at once.

> Bitcoin gets its value through scarcity. There are two kinds of
> scarcity that are economically important, scarcity of the coins=97 =
there
> will never be more than 21 million=97 and scarcity of the block space
> which, as the protocol is defined and enforced by every node can not
> be more than 1MB. The latter scarcity is what makes the security model
> economically sane.

Why wouldn't requesting minimum fees in the software work as is done =
currently?

> Fortunately, its perfectly possible to make transactions denominated
> in bitcoin outside of the blockchain, and in a secure and distributed
> manner that respects the principles that make bitcoin attractive, but
> with information hiding that improves privacy, transaction speed, and
> scalability. See, e.g. the good work being done by Open transactions
> to create distributed cryptographic banks.  So blockchain scarcity
> itself doesn't prevent Bitcoin from being a one world currency
> (something which isn't at all sane no matter how big you make the
> blocks if you don't allow for other modes of transaction processing=97
> who the heck wants to possibly wait an hour to get a 1 confirm
> sodapop??).

So what you essentially suggest is having bitcoin banks that maintain =
trust through Open Transaction contracts which contains proof of =
agreement, providing some legal protection? One wonders why have bitcoin =
at all then? Why not have an elaborate e-money system between several =
banks using Open Transactions? Bitcoin doesn't just contain proof of if =
something was done right or not, it contains actual certainty that it =
will be done right. And how does Open Transactions prevent fractional =
reserve fraud?

I suppose when people consider bitcoin banks, they will consider bitcoin =
being useless.

>  but I know that changing it is precisely as
> technically difficult as changing the 21 million limit

Set the change to occur at some block in the future leaving time for =
people to upgrade. Send out alert messages to notify users to upgrade. =
Issue is, some people might not like the change for whatever reasons.

As far as I see it, if bitcoin won't scale, then it's worth looking at =
something different to bitcoin that will scale.=