From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WSQj5-0005OK-HX for bitcoin-development@lists.sourceforge.net; Tue, 25 Mar 2014 12:45:07 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.160.171 as permitted sender) client-ip=209.85.160.171; envelope-from=gavinandresen@gmail.com; helo=mail-yk0-f171.google.com; Received: from mail-yk0-f171.google.com ([209.85.160.171]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WSQj4-0002Dm-IL for bitcoin-development@lists.sourceforge.net; Tue, 25 Mar 2014 12:45:07 +0000 Received: by mail-yk0-f171.google.com with SMTP id q9so985617ykb.2 for ; Tue, 25 Mar 2014 05:45:01 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.50.194 with SMTP id z42mr624041yhb.145.1395751500976; Tue, 25 Mar 2014 05:45:00 -0700 (PDT) Sender: gavinandresen@gmail.com Received: by 10.170.133.195 with HTTP; Tue, 25 Mar 2014 05:45:00 -0700 (PDT) In-Reply-To: <20140325122851.GA9818@savin> References: <20140322084702.GA13436@savin> <20140322150836.GG3180@nl.grid.coop> <20140322190825.GB6047@savin> <532DE7E6.4050304@monetize.io> <20140325122851.GA9818@savin> Date: Tue, 25 Mar 2014 08:45:00 -0400 X-Google-Sender-Auth: yuB10CJcGTBhgLo6IeTMiHer2UM Message-ID: From: Gavin Andresen To: Peter Todd Content-Type: multipart/alternative; boundary=001a11c1d96869180104f56db8c2 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gavinandresen[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WSQj4-0002Dm-IL Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Tree-chains preliminary summary X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 12:45:07 -0000 --001a11c1d96869180104f56db8c2 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 25, 2014 at 8:28 AM, Peter Todd 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/ --001a11c1d96869180104f56db8c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
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 thous= ands 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. =A0Which can be solved by extending some tentative trus= t 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 numb= er 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, Bitc= oin Foundation

--001a11c1d96869180104f56db8c2--