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 1RdeoQ-00047T-Ik for bitcoin-development@lists.sourceforge.net; Thu, 22 Dec 2011 09:19:42 +0000 X-ACL-Warn: Received: from backup-server.nordu.net ([193.10.252.66]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1RdeoM-0000aN-6o for bitcoin-development@lists.sourceforge.net; Thu, 22 Dec 2011 09:19:42 +0000 Received: from [109.105.106.215] ([109.105.106.215]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pBM9IrIZ020551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 22 Dec 2011 10:19:31 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_Gr=F8nager?= In-Reply-To: <4EF2148D.40801@parhelic.com> Date: Thu, 22 Dec 2011 10:19:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <08D50310-D91D-480B-A324-F68E25609D63@ceptacle.com> References: <82659F61-0449-47BB-88DC-497E0D02F8A1@ceptacle.com> <4EEE58CA.5090902@justmoon.de> <67FAA76C-1734-471D-A3D8-31E5216DD512@ceptacle.com> <4EF2148D.40801@parhelic.com> To: Jordan Mack X-Mailer: Apple Mail (2.1251.1) X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1RdeoM-0000aN-6o Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Protocol extensions 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: Thu, 22 Dec 2011 09:19:42 -0000 Agree, but even before that, we will meet problems of the current = 1MB/10min limit. The calculations from the scalability link surely indicates that there = are 2 options for scalability either go for trusted supernodes backed by = huge hardware resources or something else would be needed. The supernode = approach is simple and easy to implement, but it also breaks a lot of = the nice features about bitcoin. So if we want bitcoin to stay p2p we = need to deploy other strategies. The hash space partitioning is one of = them. And the nice thing is that it can be made to scale even for a = javascript based validating and fully connected client running on a = smartphone in a bitcoin future with billions of clients and = transactions, and still it does not exclude you from running a trusted = supernode either.=20 Cheers, M On 21/12/2011, at 18:17, Jordan Mack wrote: > I think it would be a lot more than that. According to the Scalability=20= > page (https://en.bitcoin.it/wiki/Scalability) if Bitcoin took over all=20= > credit card transactions, that would be about 1.14GB per block. I=20 > believe that is 58.5PB per year. (6*24*365*1.14/1024) This would also=20= > mean the distribution of 2MB of block data per second, which doesn't=20= > include broadcast overhead. >=20 > On 12/21/2011 12:50 AM, Michael Gr=F8nager wrote: >> when bitcoin takes over all credit card transactions (!), and even = before that, >> we will meet a scalability problem. The blockchain will grow rapidly, >> (1MB/10min or 50GB/yr) >=20 > = --------------------------------------------------------------------------= ---- > Write once. Port to many. > Get the SDK and tools to simplify cross-platform app development. = Create=20 > new or port existing apps to sell to consumers worldwide. Explore the=20= > Intel AppUpSM program developer opportunity. = appdeveloper.intel.com/join > http://p.sf.net/sfu/intel-appdev > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development