public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Matthew Mitchell <matthewmitchell@godofgod.co.uk>
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Segmented Block Relaying BIP draft.
Date: Tue, 11 Sep 2012 15:42:32 -0400	[thread overview]
Message-ID: <CAAS2fgSymOJ=cQnNwK9+nvRYszHHH4vtUpoQYWNNYoVaYB5Gpg@mail.gmail.com> (raw)
In-Reply-To: <2104FC7F-0AE0-4C55-9987-B20EFCE19FC3@godofgod.co.uk>

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 see the replies online…
>
> 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.

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 requests 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 demand 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 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.

The finite size— and ultimately the contention for space it causes— 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— 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— 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— there
will never be more than 21 million— 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—
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)— 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— if not more so— 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.



  reply	other threads:[~2012-09-11 19:42 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-11 19:07 [Bitcoin-development] Segmented Block Relaying BIP draft Matthew Mitchell
2012-09-11 19:42 ` Gregory Maxwell [this message]
2012-09-11 21:48   ` Matthew Mitchell
2012-09-11 23:22     ` Gregory Maxwell
2012-09-13  8:42       ` Mike Hearn
2012-09-13 14:05         ` Matthew Mitchell
2012-09-13 15:16           ` Gregory Maxwell
     [not found]             ` <2B95CF41-4304-4D2A-9ABF-198D97B7449B@godofgod.co.uk>
2012-09-13 15:46               ` Matthew Mitchell
     [not found]               ` <CAAS2fgQi8QFwU2M=wLiDodt3SmO48vUV5Sp3YCb1OmGJ5m=E7Q@mail.gmail.com>
2012-09-13 17:49                 ` Matthew Mitchell
2012-09-13 18:59                   ` Pieter Wuille
2012-09-13 20:24                     ` Matthew Mitchell
  -- strict thread matches above, loose matches on Subject: below --
2012-09-10 15:07 Matthew Mitchell
2012-09-10 15:14 ` Gregory Maxwell
2012-09-10 16:29   ` Matt Corallo
2012-09-10 18:59 ` Luke-Jr
2012-09-10 19:34   ` Matthew Mitchell
2012-09-10 19:53     ` Matt Corallo
2012-09-10 20:00       ` Gregory Maxwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAAS2fgSymOJ=cQnNwK9+nvRYszHHH4vtUpoQYWNNYoVaYB5Gpg@mail.gmail.com' \
    --to=gmaxwell@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=matthewmitchell@godofgod.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox