Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A8BF59FA for ; Fri, 31 Mar 2017 16:46:14 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f41.google.com (mail-vk0-f41.google.com [209.85.213.41]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7BC5D17C for ; Fri, 31 Mar 2017 16:46:13 +0000 (UTC) Received: by mail-vk0-f41.google.com with SMTP id s68so97551203vke.3 for ; Fri, 31 Mar 2017 09:46:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SSvVewkvDhhzI9oFu8UhDaT/7MQqqmVLKVkJkvQDspg=; b=bpno/sMo6LqJYiPrX3WJchXEWPhLau4UeuAnZLbc8abjlDAnINTmRWdoi40mudNSo+ Ul2LUYTGjadMDBObTzuCtIUHcxRVvVUvqxKBWNitBlqCC/9emvWg5OahvPpwnml7lB83 K3Jod+otsHEZvC+lPI6rWyE5se4GoqykfAKj76ICD/mFxWjaF7ot8z1a29SmZPL04k+6 wLUkdciywOfsu/y0AjoaA+u9FYNhfhDjj+hHroAb5DhG+XpaXdW6quX5h6qBjP9Y7yqQ CfgpXctkLxtUlUQHea28KEuH9G65nql6+QsnYbSiD85A72d8cfb0galtW16PBRu5mOV2 6fwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SSvVewkvDhhzI9oFu8UhDaT/7MQqqmVLKVkJkvQDspg=; b=ewhgrlpdo/xU6BY6MDdDZJ17RK91hua0thGhsNk/5lMxO1v89oqyZChYlxlfnndyZ2 3Uww+xSAflmmI1vVnSZu5NLF+wO80HlzfeP4SSN/fAHSz5Ou+Q15kCYU7XoY7hM5pliX x9nfn/HYAImD+0Sk53cFbbpQiqhY2ODCrKQ+toD1NqogsHPSRnRUqd7weSYeh5ejqiJB N9sbhjaW3/JoN4s0KjL2fsqF8sAwEIwLsg7GQdoJHEnpPKQcsFA/UJemfNY6MYF04Zor SzGXSbNZynATWX16NourMNYhKgthO5LUkrRNftJBbHTDM54uow4uR3lt5eNZBNLSVxYI rHDQ== X-Gm-Message-State: AFeK/H1Dgzr+I+PMBczJas9StSRj1AUkLuDnliOJ+gxYPONQX/2R87AU/lLTBx4dvrHOhXU2O1aboyBKgC7paw== X-Received: by 10.31.175.74 with SMTP id y71mr1789118vke.34.1490978772500; Fri, 31 Mar 2017 09:46:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.157.143 with HTTP; Fri, 31 Mar 2017 09:46:10 -0700 (PDT) In-Reply-To: References: From: Jared Lee Richardson Date: Fri, 31 Mar 2017 09:46:10 -0700 Message-ID: To: David Vorick Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, LOTS_OF_MONEY, 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 17:07:45 +0000 Cc: Bitcoin Dev 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 16:46:14 -0000 I guess I should caveat, a rounding error is a bit of exaggeration - mostly because I previously assumed that it would take 14 years for the network to reach such a level, something I didn't say and that you might not grant me. I don't know why paypal has multiple datacenters, but I'm guessing it probably has a lot more to do with everything else they do - interface, support, tax compliance, replication, redundancy - than it does with the raw numbers of transaction volumes. What I do know is the math, though. WW tx volume = 426,000,000,000 in 2015. Assuming tx size of ~500 bytes, that's 669 terabytes of data per year. At a hard drive cost of 0.021 per GB, that's $36k a year or so and declines ~14% a year. The bandwidth is the really big cost. You are right that if this hypothetical node also had to support historical syncing, the numbers would probably be unmanagable. But that can be solved with a simple checkpointing system for the vast majority of users, and nodes could solve it by not supporting syncing / reducing peer count. With a peer count of 25 I measured ~75 Gb/month with today's blocksize cap. That works out to roughly 10 relays(sends+receives) per transaction assuming all blocks were full, which was a pretty close approximation. The bandwidth data of our 426 billion transactions per year works out to 942 mbit/s. That's 310 Terabytes per month of bandwidth - At today's high-volume price of 0.05 per GB, that's $18,500 a month or $222,000 a year. Plus the $36k for storage per year brings it to ~$250k per year. Not a rounding error, but within the rough costs of running an exchange - a team of 5 developers works out to ~$400-600k a year, and the cost of compliance with EU and U.S. entities (including lawyers) runs upwards of a million dollars a year. Then there's the support department, probably ~$100-200k a year. The reason I said a rounding error was that I assumed that it would take until 2032 to reach that volume of transactions (Assuming +80%/year of growth, which is our 4-year and 2-year historical average tx/s growth). If hard drive prices decline by 14% per year, that cost becomes $3,900 a year, and if bandwidth prices decline by 14% a year that cost becomes $1800 a month($21,600 a year). Against a multi-million dollar budget, even 3x that isn't a large concern, though not, as I stated, a rounding error. My bad. I didn't approximate for CPU usage, as I don't have any good estimates for it, and I don't have significant reason to believe that it is a higher cost than bandwidth, which seems to be the controlling cost compared to adding CPU's. > I'm not going to take the time to refute everything you've been saying Care to respond to the math? > This whole thread has been absurdly low quality. Well, we agree on something at least. On Fri, Mar 31, 2017 at 9:14 AM, David Vorick wrote: > No one is suggesting anything like this. The cost of running a node > that could handle 300% of the 2015 worldwide nonbitcoin transaction > volume today would be a rounding error for most exchanges even if > prices didn't rise. > > > Then explain why PayPal has multiple datacenters. And why Visa has multiple > datacenters. And why the banking systems have multiple datacenters each. > > I'm guessing it's because you need that much juice to run a global payment > system at the transaction volumes that they run at. > > Unless you have professional experience working directly with transaction > processors handling tens of millions of financial transactions per day, I > think we can fully discount your assessment that it would be a rounding > error in the budget of a major exchange or Bitcoin processor to handle that > much load. And even if it was, it wouldn't matter because it's extremely > important to Bitcoin's security that it's everyday users are able to and are > actively running full nodes. > > I'm not going to take the time to refute everything you've been saying but I > will say that most of your comments have demonstrated a similar level of > ignorance as the one above. > > This whole thread has been absurdly low quality.