From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3098971F for ; Fri, 31 Mar 2017 18:58:47 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pg0-f44.google.com (mail-pg0-f44.google.com [74.125.83.44]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9A6DA1F9 for ; Fri, 31 Mar 2017 18:58:46 +0000 (UTC) Received: by mail-pg0-f44.google.com with SMTP id 81so79177693pgh.2 for ; Fri, 31 Mar 2017 11:58:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=68pmfQVbJc2Oli6qL0+OWoXiF/a1HEMG9zylvi+6MZo=; b=klkcyd0s5BnDl5mdOmifM5lgr6bfG8a1dJ/IXu5oqa+k0sHHmHbh1UlO1HmT79KB8F KOFXPt+/v/yBg1LK65Y3JJ4dHtOZD7KK1zQfdFI3twBgMgx97gfIDeP0e2JWrXBWhSsY ljNmTx9FVpv/U8M88bbxCD1GSPVXBVRFyNUPyRajKGOU3xxFM2Z1TFKy0YsL+L8NiISf GMVxgmNrIjp0JM41aIV1K2IhZM0qHnDzx9VAerkGJK074K9uT/ex5sdP5nuIT8n4yeIO mFEXs0EoUh03DKmBNZH8JRV3TjC4ZbdRu/pJa6NKgR8mcnRFTq6pbFFH9hkq+KI0ULHb 1nuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=68pmfQVbJc2Oli6qL0+OWoXiF/a1HEMG9zylvi+6MZo=; b=CYTAUARcyrbSYiR+6XCXPV2KNZsEjXWEvAJR9cs9nSXuf6ENuHg+i/L/GOKlS5C6jt 27csRwWpsw9cGWmZ2nx4CZiqMmjfHz3cxwGliZyeENuZAVQ50TtJBc6gfT5rHlsLoN2g L4wVHo2j2PlPZAMb9r5jOU8v095Nb0MwrX3GqkZDD/BuRa2lXmoARf8WqgHFjhDrbXQM fIew4TibByhrB0kqwCx2GPAtMWrEEgFUGyjlihH+UuXwMFL40VugXAeAcAMlHS6iN1a4 iFiEWgYXth2o2pFCqehjtELdLI5Dyzd8CzQNwWGnXUJ4WMrykprliNDAcgvu5L6hAbxo XXnQ== X-Gm-Message-State: AFeK/H2gNwf+gLoarWVAf+KbntzjrLGBuAVe3GJqVl5xLT2KWv4iU22g4jMGAlgcVfPXTg== X-Received: by 10.99.109.195 with SMTP id i186mr1349451pgc.215.1490986726132; Fri, 31 Mar 2017 11:58:46 -0700 (PDT) Received: from [10.117.142.49] (mobile-166-176-184-254.mycingular.net. [166.176.184.254]) by smtp.gmail.com with ESMTPSA id r82sm5238797pfl.108.2017.03.31.11.58.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Mar 2017 11:58:45 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Eric Voskuil X-Mailer: iPhone Mail (14D27) In-Reply-To: Date: Fri, 31 Mar 2017 11:58:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: David Vorick , Bitcoin Protocol Discussion X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,LOTS_OF_MONEY,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 31 Mar 2017 18:59:20 +0000 Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 18:58:47 -0000 As an independently verifiable, decentralized store of public information, t= he Bitcoin block tree and transaction DAG do have an advantage over systems s= uch as Visa. The store is just a cache. There is no need to implement reliab= ility in storage or in communications. It is sufficient to be able to detect= invalidity. And even if a subset of nodes fail to do so, the system overall= compensates. As such the architecture of a Bitcoin node and its supporting hardware requi= rements are very different from an unverifiable, centralized store of privat= e information. So in that sense the comparison below is not entirely fair. M= any, if not most, of the high costs of a Visa datacenter do not apply becaus= e of Bitcoin's information architecture. However, if the system cannot remain decentralized these architectural advan= tages will not hold. At that point your considerations below are entirely va= lid. Once the information is centralized it necessarily becomes private and f= ragile. Conversely, once it becomes private it necessarily becomes centraliz= ed and fragile. This fragility requires significant investment by the centra= l authority to maintain. So as has been said, we can have decentralization and its benefit of trustle= ssness or we can have Visa. We already have Visa. Making another is entirely= uninteresting. e=20 > On Mar 31, 2017, at 11:23 AM, David Vorick via bitcoin-dev wrote: >=20 > Sure, your math is pretty much entirely irrelevant because scaling systems= to massive sizes doesn't work that way. >=20 > At 400B transactions per year we're looking at block sizes of 4.5 GB, and a= database size of petabytes. How much RAM do you need to process blocks like= that? Can you fit that much RAM into a single machine? Okay, you can't fit t= hat much RAM into a single machine. So you have to rework the code to operat= e on a computer cluster. >=20 > Already we've hit a significant problem. You aren't going to rewrite Bitco= in to do block validation on a computer cluster overnight. Further, are stor= age costs consistent when we're talking about setting up clusters? Are bandw= idth costs consistent when we're talking about setting up clusters? Are RAM a= nd CPU costs consistent when we're talking about setting up clusters? No, th= ey aren't. Clusters are a lot more expensive to set up per-resource because t= hey need to talk to eachother and synchronize with eachother and you have a L= OT more parts, so you have to build in redundancies that aren't necessary in= non-clusters. >=20 > Also worth pointing out that peak transaction volumes are typically 20-50x= the size of typical transaction volumes. So your cluster isn't going to nee= d to plan to handle 15k transactions per second, you're really looking at mo= re like 200k or even 500k transactions per second to handle peak-volumes. An= d if it can't, you're still going to see full blocks. >=20 > You'd need a handful of experts just to maintain such a thing. Disks are g= oing to be failing every day when you are storing multiple PB, so you can't j= ust count a flat cost of $20/TB and expect that to work. You're going to nee= d redundancy and tolerance so that you don't lose the system when a few of y= our hard drives all fail within minutes of eachother. And you need a way to r= ebuild everything without taking the system offline. >=20 > This isn't even my area of expertise. I'm sure there are a dozen other sig= nificant issues that one of the Visa architects could tell you about when de= aling with mission-critical data at this scale. >=20 > -------- >=20 > Massive systems operate very differently and are much more costly per-unit= than tiny systems. Once we grow the blocksize large enough that a single co= mputer can't do all the processing all by itself we get into a world of much= harder, much more expensive scaling problems. Especially because we're talk= ing about a distributed system where the nodes don't even trust each other. A= nd transaction processing is largely non-parallel. You have to check each tr= ansaction against each other transaction to make sure that they aren't doubl= e spending eachother. This takes synchronization and prevents 500 CPUs from a= ll crunching the data concurrently. You have to be a lot more clever than th= at to get things working and consistent. >=20 > When talking about scalability problems, you should ask yourself what othe= r systems in the world operate at the scales you are talking about. None of t= hem have cost structures in the 6 digit range, and I'd bet (without actually= knowing) that none of them have cost structures in the 7 digit range either= . In fact I know from working in a related industry that the cost structures= for the datacenters (plus the support engineers, plus the software manageme= nt, etc.) that do airline ticket processing are above $5 million per year fo= r the larger airlines. Visa is probably even more expensive than that (thoug= h I can only speculate). > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev