public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Gavin Andresen <gavin@bitcoinfoundation.org>
To: Peter Todd <pete@petertodd.org>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Tree-chains preliminary summary
Date: Tue, 25 Mar 2014 08:45:00 -0400	[thread overview]
Message-ID: <CABsx9T149f9of9+sYMFazAxtRi=ZJrpA1B41buERD3+j7NGKmg@mail.gmail.com> (raw)
In-Reply-To: <20140325122851.GA9818@savin>

[-- Attachment #1: Type: text/plain, Size: 1373 bytes --]

On Tue, Mar 25, 2014 at 8:28 AM, Peter Todd <pete@petertodd.org> wrote:

> Bitcoin doesn't scale. There's a lot of issues at hand here, but the
> most fundemental of them is that to create a block you need to update
> the state of the UTXO set, and the way Bitcoin is designed means that
> updating that state requires bandwidth equal to all the transaction
> volume to keep up with the changes to what set. Long story short, we get
> O(n^2) scaling, which is just plain infeasible.
>

We have a fundamental disagreement here.

If you go back and read Satoshi's original thoughts on scaling, it is clear
that he imagined tens of thousands of mining nodes and hundreds of millions
of lightweight SPV users.

Scaling is a problem if every person is a fully validating node; then,
indeed, you get an O(n^2) problem.  Which can be solved by extending some
tentative trust to your peers, but lets put all those possible solutions
aside.

Given tens of thousands of fully validating nodes, you get O(m*n), where m
is the number of fully validating peers and is a large constant (10s of
thousands).

We don't know how large m can or will be; we have only just started to
scale up.

"Bitcoin doesn't scale" is pure FUD. It might not scale in exactly the way
you want, but it WILL scale.

-- 
--
Gavin Andresen
Chief Scientist, Bitcoin Foundation
https://www.bitcoinfoundation.org/

[-- Attachment #2: Type: text/html, Size: 2211 bytes --]

  reply	other threads:[~2014-03-25 12:45 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-22  8:47 [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee Peter Todd
2014-03-22 13:53 ` Jorge Timón
2014-03-22 19:34   ` Peter Todd
2014-03-22 20:12     ` Jorge Timón
2014-03-23 23:17       ` Troy Benjegerdes
2014-03-23 23:53         ` Mark Friedenbach
2014-03-24 20:34           ` Troy Benjegerdes
2014-03-24 20:57             ` Mark Friedenbach
2014-03-25 22:10               ` Troy Benjegerdes
2014-03-26  1:09                 ` kjj
2014-03-22 15:08 ` Troy Benjegerdes
2014-03-22 17:04   ` Mark Friedenbach
2014-03-22 19:08   ` Peter Todd
2014-03-23 22:37     ` Troy Benjegerdes
     [not found]     ` <532DE7E6.4050304@monetize.io>
2014-03-25 12:28       ` [Bitcoin-development] Tree-chains preliminary summary Peter Todd
2014-03-25 12:45         ` Gavin Andresen [this message]
2014-03-25 13:49           ` Peter Todd
2014-03-25 15:20             ` Mike Hearn
2014-03-25 16:47               ` Peter Todd
2014-03-25 17:37             ` Jeff Garzik
2014-03-25 18:02               ` Alan Reiner
2014-03-25 18:13                 ` slush
2014-03-25 19:47                   ` Peter Todd
2014-03-25 21:41                     ` Troy Benjegerdes
2014-03-25 20:40             ` Ricardo Filipe
2014-03-25 22:00               ` Troy Benjegerdes
2014-03-26 10:58               ` Peter Todd
2014-03-25 12:50         ` Peter Todd
2014-03-25 21:03         ` Mark Friedenbach
2014-03-25 22:34           ` Gregory Maxwell
2014-03-27 16:14             ` Jorge Timón
2014-03-28 15:10               ` Troy Benjegerdes
2014-04-17 21:41                 ` Tier Nolan
2014-03-26 10:48           ` Peter Todd
2014-08-03 17:23         ` Gregory Sanders
2014-03-24 21:17 ` [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee Luke-Jr

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='CABsx9T149f9of9+sYMFazAxtRi=ZJrpA1B41buERD3+j7NGKmg@mail.gmail.com' \
    --to=gavin@bitcoinfoundation.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=pete@petertodd.org \
    /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