Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.210.175 as permitted sender)
	client-ip=209.85.210.175; envelope-from=gmaxwell@gmail.com;
	helo=mail-iy0-f175.google.com; 
MIME-Version: 1.0
In-Reply-To: <2104FC7F-0AE0-4C55-9987-B20EFCE19FC3@godofgod.co.uk>
References: <2104FC7F-0AE0-4C55-9987-B20EFCE19FC3@godofgod.co.uk>
Date: Tue, 11 Sep 2012 15:42:32 -0400
Message-ID: <CAAS2fgSymOJ=cQnNwK9+nvRYszHHH4vtUpoQYWNNYoVaYB5Gpg@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Matthew Mitchell <matthewmitchell@godofgod.co.uk>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Segmented Block Relaying BIP draft.
Precedence: list

On Tue, Sep 11, 2012 at 3:07 PM, Matthew Mitchell
<matthewmitchell@godofgod.co.uk> wrote:
> For some reason sourceforge is not sending me updates anymore but I can s=
ee the replies online=E2=80=A6
>
> There could be a slightly more simple protocol which gives all the transa=
ctions hashes and nodes can then download the transactions separately. Howe=
ver there are two problems:
>
> 1. Downloading all the transactions individually might be inefficient. My=
 proposal will allow nodes to request multiple transactions at once.

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

> 2. Why not add a few additional components to the protocol to allow reque=
sts for any level of the merkle tree? It's not very complicated at all and =
protects against the future.

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?

It's sometimes desirable to be more general rather than more special
case when it's costless... but having couple extra p2p protocol
messages to implement, test for interop, guard against vulnerability,
etc. isn't costless... and should be justified with concrete benefits.

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.

>The block sizes at the moment are about 0.1MB but what if the bitcoin dema=
nd starts pushing that into megabytes?

And what if? _Bitcoin_ blocksizes can't be any larger.  Some future
incompatible system? well perhaps. But we're working on the protocol
for bitcoin now.

> And yes the ~0.95MB limit needs to be changed in order for bitcoin to gro=
w that far. Why would the limit not be lifted? How will bitcoin demand be s=
atisfied other than having large fees to deter transactions, hoping the fee=
s are large enough to balance the demand with the block size limits to prev=
ent 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.

The finite size=E2=80=94 and ultimately the contention for space it causes=
=E2=80=94 is
the only thing will creates non-trivial fees. Without the fees there
is no honest economic motivation to mine with adequate computing power
to provide security (lots of dishonest motivations=E2=80=94 e.g. applying
control over the currency exist), you'd just have a race to the
bottom, given unbounded block sizes it is always rational for
decentralized to include any transaction with a fee even if it is very
small=E2=80=94 otherwise the next rational solver is just going to include =
it.

Bitcoin gets its value through scarcity. There are two kinds of
scarcity that are economically important, scarcity of the coins=E2=80=94 th=
ere
will never be more than 21 million=E2=80=94 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.

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=E2=80=
=94
who the heck wants to possibly wait an hour to get a 1 confirm
sodapop??).

From the beginning it was obvious that confirmations would eventually
be slower (or expensive to make merely slow; Bitcoin is incapable of
reliable fast confirmations)=E2=80=94 thats the nature the stochastic
consensus and the fee based security support.  You could instead
imagine a future where bitcoin's security came by collusion by major
financial cartels and governments, and where fees aren't important....
 But I reject that future, it's a perfectly viable one, but why bother
with Bitcoins in the first place? To make some early adopters a little
bit of money starting off the next big centrally controlled fiat?
Boring.

I can't say for sure if the 1MB limit will stay exactly as is forever,
as I expect the economics work with any limit out of a fairly broad
range that is low enough to both make the space seriously scarce and
low enough that 'inexpensive' (e.g. privately owned) hardware can
continue to audit it to preserve the decentralized security,  and the
economic importance of the size limit is more subtle than the
inflation resistance... but I know that changing it is precisely as
technically difficult as changing the 21 million limit: all Bitcoin
node software must be replaced with incompatible software, and I
believe it would be just as economically risky=E2=80=94 if not more so=E2=
=80=94 if
done wrong, as at least inflation would have a easily understood
direct dillution effect while inadequate security would potentially
make all Bitcoin worthless.  As such I don't think it's even worth
discussing until there is an urgent demand to clarify the tradeoffs...

Should the block size ever be increased the message format used for
relaying the larger blocks will be the smallest of the issues being
discussed.