From: Peter Todd <pete@petertodd•org>
To: Gregory Maxwell <gmaxwell@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain
Date: Thu, 14 Feb 2013 01:39:01 -0500 [thread overview]
Message-ID: <20130214063901.GB15157@savin> (raw)
In-Reply-To: <CAAS2fgQGb1Tb=cma8_20_gWUQ+60v9v=UTt52RMGnztOx5-E3w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2209 bytes --]
On Wed, Feb 13, 2013 at 05:02:39PM -0800, Gregory Maxwell wrote:
> It's the year 2043— the Y2038 problem is behind us and everyone is
> beginning to forget how terrible it turned out to be— By some amazing
> chance Bitcoin still exists and is widely used. Off-chain system like
> fidelity bonded banks are vibrant and widely used providing scalable
> instant and completely private transactions to millions of people.
Speaking of fidelity bonded banks I think it needs to be made clear that
really trustworthy bonded banks require the maximum block size to be
kept limited. The problem is that even if you don't create any
transactions on the chain yourself, you still need to be able to keep
watch the chain to keep track of what the bank is doing. For instance if
you are trying to decide if you can trust the bank with a 1BTC deposit,
and they've purchased a 1000BTC fidelity bond, you still need to be able
to determine if all the unspent transaction outputs in the blockchain
that the bank could spend, in addition to all the unspen transactions in
the mempool, are less than the value of their fidelity bond. With 1MiB
blocks that will be practical on smartphones with wireless internet
connectivity without having to trust anyone else. With 1GiB blocks that
just won't be true and you'll be forced to trust the relatively few
nodes out there with the hardware to deal with the blockchain. You'll
pay for it too.
Potentially the various UTXO proposals will help, but they will need to
be quite sophisticated; we'll need sums of all txout values by
scriptPubKey and a fraud notice system for instance. All of this stuff
is at best many months away from even beginning to be deployed on the
network, and probably years away from getting to the point where it is
truely trustworthy. Maybe it'll never become trustworthy, either because
miners just don't bother, the code doesn't get written, or a flaw in the
whole idea is found. We're just not going to know until these
technologies are implemented and tested, and without them, large blocks
force us into trusting miners blindly and make many valuable
applications impossible.
--
'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
prev parent reply other threads:[~2013-02-14 6:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-12 13:49 Raph Frank
2013-02-12 15:49 ` Gregory Maxwell
2013-02-13 14:58 ` Raph Frank
2013-02-13 15:42 ` Gregory Maxwell
2013-02-13 21:02 ` Gavin Andresen
2013-02-13 21:05 ` Gregory Maxwell
2013-02-13 23:10 ` Stephen Pair
2013-02-14 0:28 ` Gregory Maxwell
2013-02-14 2:44 ` Stephen Pair
2013-02-14 3:38 ` Gregory Maxwell
2013-02-14 5:36 ` Stephen Pair
2013-02-14 6:07 ` Peter Todd
2013-02-14 12:59 ` Stephen Pair
2013-02-18 16:22 ` Peter Todd
2013-02-14 1:02 ` Gregory Maxwell
2013-02-14 6:39 ` Peter Todd [this message]
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=20130214063901.GB15157@savin \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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