public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Eric Voskuil <eric@voskuil.org>
To: David Vorick <david.vorick@gmail.com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
Date: Fri, 31 Mar 2017 11:58:44 -0700	[thread overview]
Message-ID: <F7248427-367E-4666-9171-5FD6898F4144@voskuil.org> (raw)
In-Reply-To: <CAFVRnyr-Z9YWtT3r+7-fGejzgxKhH3-kQuo8JQFqKDpyZNBBdg@mail.gmail.com>

As an independently verifiable, decentralized store of public information, the Bitcoin block tree and transaction DAG do have an advantage over systems such as Visa. The store is just a cache. There is no need to implement reliability 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 requirements are very different from an unverifiable, centralized store of private information. So in that sense the comparison below is not entirely fair. Many, if not most, of the high costs of a Visa datacenter do not apply because of Bitcoin's information architecture.

However, if the system cannot remain decentralized these architectural advantages will not hold. At that point your considerations below are entirely valid. Once the information is centralized it necessarily becomes private and fragile. Conversely, once it becomes private it necessarily becomes centralized and fragile. This fragility requires significant investment by the central authority to maintain.

So as has been said, we can have decentralization and its benefit of trustlessness or we can have Visa. We already have Visa. Making another is entirely uninteresting.

e 

> On Mar 31, 2017, at 11:23 AM, David Vorick via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> Sure, your math is pretty much entirely irrelevant because scaling systems to massive sizes doesn't work that way.
> 
> 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 that much RAM into a single machine. So you have to rework the code to operate on a computer cluster.
> 
> Already we've hit a significant problem. You aren't going to rewrite Bitcoin to do block validation on a computer cluster overnight. Further, are storage costs consistent when we're talking about setting up clusters? Are bandwidth costs consistent when we're talking about setting up clusters? Are RAM and CPU costs consistent when we're talking about setting up clusters? No, they aren't. Clusters are a lot more expensive to set up per-resource because they need to talk to eachother and synchronize with eachother and you have a LOT more parts, so you have to build in redundancies that aren't necessary in non-clusters.
> 
> 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 need to plan to handle 15k transactions per second, you're really looking at more like 200k or even 500k transactions per second to handle peak-volumes. And if it can't, you're still going to see full blocks.
> 
> You'd need a handful of experts just to maintain such a thing. Disks are going to be failing every day when you are storing multiple PB, so you can't just count a flat cost of $20/TB and expect that to work. You're going to need redundancy and tolerance so that you don't lose the system when a few of your hard drives all fail within minutes of eachother. And you need a way to rebuild everything without taking the system offline.
> 
> This isn't even my area of expertise. I'm sure there are a dozen other significant issues that one of the Visa architects could tell you about when dealing with mission-critical data at this scale.
> 
> --------
> 
> 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 computer 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 talking about a distributed system where the nodes don't even trust each other. And transaction processing is largely non-parallel. You have to check each transaction against each other transaction to make sure that they aren't double spending eachother. This takes synchronization and prevents 500 CPUs from all crunching the data concurrently. You have to be a lot more clever than that to get things working and consistent.
> 
> When talking about scalability problems, you should ask yourself what other systems in the world operate at the scales you are talking about. None of them 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 management, etc.) that do airline ticket processing are above $5 million per year for the larger airlines. Visa is probably even more expensive than that (though I can only speculate).
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


  reply	other threads:[~2017-03-31 18:58 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-29 19:33 [bitcoin-dev] Hard fork proposal from last week's meeting Daniele Pinna
2017-03-29 20:28 ` Peter R
2017-03-29 22:17   ` Jared Lee Richardson
2017-03-29 20:28 ` David Vorick
2017-03-29 22:08   ` Jared Lee Richardson
2017-03-30  7:11     ` Luv Khemani
2017-03-30 17:16       ` Jared Lee Richardson
2017-03-31  4:21         ` Luv Khemani
2017-03-31  5:28           ` Jared Lee Richardson
2017-03-31  8:19             ` Luv Khemani
2017-03-31 15:59               ` Jared Lee Richardson
2017-03-31 16:14                 ` David Vorick
2017-03-31 16:46                   ` Jared Lee Richardson
2017-03-31 18:23                     ` David Vorick
2017-03-31 18:58                       ` Eric Voskuil [this message]
2017-04-01  6:15                       ` Jared Lee Richardson
  -- strict thread matches above, loose matches on Subject: below --
2017-03-31 21:23 Rodney Morris
2017-03-31 23:13 ` Eric Voskuil
     [not found]   ` <CABerxhGeofH4iEonjB1xKOkHcEVJrR+D4QhHSw5cWYsjmW4JpQ@mail.gmail.com>
2017-04-01  1:41     ` Rodney Morris
2017-04-01  6:18   ` Jared Lee Richardson
2017-04-01  7:41     ` Eric Voskuil
     [not found]       ` <CAAt2M1_sHsCD_AX-vm-oy-4tY+dKoDAJhfVUc4tnoNBFn-a+Dg@mail.gmail.com>
     [not found]         ` <CAAt2M19Gt8PmcPUGUHKm2kpMskpN4soF6M-Rb46HazKMV2D9mg@mail.gmail.com>
2017-04-01 14:45           ` Natanael
     [not found]       ` <CAD1TkXusCe-O3CGQkXyRw_m3sXS9grGxMqkMk8dOvFNXeV5zGQ@mail.gmail.com>
2017-04-01 18:42         ` Jared Lee Richardson
     [not found]   ` <CAAt2M1_kuCBQWd9dis5UwJX8+XGVPjjiOA54aD74iS2L0cYcTQ@mail.gmail.com>
     [not found]     ` <CAAt2M19Nr2KdyRkM_arJ=LBnqDQQyLQ2QQ-UBC8=gFnemCdPMg@mail.gmail.com>
2017-04-01 13:26       ` Natanael
2017-03-29 19:50 Raystonn .
2017-03-30 10:34 ` Tom Zander
2017-03-30 11:19   ` David Vorick
2017-03-30 21:42     ` Jared Lee Richardson
2017-03-30 11:24   ` Aymeric Vitte
2017-03-28 19:56 Paul Iverson
2017-03-28 20:16 ` Pieter Wuille
2017-03-28 20:43 ` Tom Zander
2017-03-28 20:53   ` Alphonse Pace
2017-03-28 21:06     ` Luke Dashjr
2017-03-28 16:59 Wang Chun
2017-03-28 17:13 ` Matt Corallo
2017-03-29  8:45   ` Jared Lee Richardson
2017-03-28 17:23 ` Alphonse Pace
2017-03-28 17:31   ` Wang Chun
2017-03-28 17:33     ` Jeremy
2017-03-28 17:50     ` Douglas Roark
2017-03-28 17:33   ` Juan Garavaglia
2017-03-28 17:53     ` Alphonse Pace
2017-03-28 22:36       ` Juan Garavaglia
2017-03-29  2:59         ` Luv Khemani
2017-03-29  6:24         ` Emin Gün Sirer
2017-03-29 15:34           ` Johnson Lau
2017-04-01 16:15             ` Leandro Coutinho
2017-03-29  9:16       ` Jared Lee Richardson
2017-03-29 16:00         ` Aymeric Vitte
2017-03-28 17:34 ` Johnson Lau
2017-03-28 17:46   ` Luke Dashjr
2017-03-28 20:50   ` Tom Zander
2017-03-29  4:21     ` Johnson Lau
2017-03-28 20:48 ` Tom Zander
2017-03-29  6:32 ` Bram Cohen
2017-03-29  9:37   ` Jorge Timón
2017-03-29 19:07     ` Jared Lee Richardson
2017-04-02 19:02       ` Staf Verhaegen
2017-03-29  7:49 ` Martin Lízner
2017-03-29 15:57   ` David Vorick
2017-03-29 16:08     ` Aymeric Vitte
     [not found]       ` <CAFVRnyo1XGNbq_F8UfqqJWHCVH14iMCUMU-R5bOh+h3mtwSUJg@mail.gmail.com>
2017-03-29 16:18         ` David Vorick
2017-03-29 16:20           ` Andrew Johnson
2017-03-29 16:25             ` David Vorick
2017-03-29 16:41               ` Andrew Johnson
2017-03-29 17:14                 ` Aymeric Vitte
2017-03-29 20:53               ` Jared Lee Richardson
2017-03-29 20:32           ` Jared Lee Richardson
2017-03-29 21:36             ` praxeology_guy
2017-03-29 22:33             ` Aymeric Vitte
2017-03-30  5:23               ` Ryan J Martin
2017-03-30 10:30                 ` Tom Zander
2017-03-30 16:44                   ` Jared Lee Richardson
2017-03-30 20:51                   ` Jared Lee Richardson
2017-03-30 21:57                     ` Tom Zander
     [not found]               ` <CAD1TkXvx=RKvjC8BUstwtQxUUQwG4eiU9XmF1wr=bU=xcVg5WQ@mail.gmail.com>
2017-03-30 10:13                 ` Aymeric Vitte
2017-03-29 19:46     ` Jared Lee Richardson
2017-03-29 19:10   ` Jared Lee Richardson
2017-03-29 19:36     ` praxeology_guy
2017-04-02 19:12     ` Staf Verhaegen

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=F7248427-367E-4666-9171-5FD6898F4144@voskuil.org \
    --to=eric@voskuil.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=david.vorick@gmail.com \
    /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