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 04C0194F for ; Sat, 8 Apr 2017 21:24:08 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from bc.grid.coop (bc.grid.coop [162.221.205.91]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 8928A7C for ; Sat, 8 Apr 2017 21:24:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) (uid 1000) by bc.grid.coop with local; Sat, 08 Apr 2017 21:22:11 +0000 id 00000000005E033E.0000000058E95483.000001E4 Date: Sat, 8 Apr 2017 21:22:11 +0000 From: Troy Benjegerdes To: Bram Cohen , Bitcoin Protocol Discussion Message-ID: <20170408212211.GG23538@hostname.unassigned> References: <1491516747.3791700.936828232.69F82904@webmail.messagingengine.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sat, 08 Apr 2017 21:37:04 +0000 Subject: Re: [bitcoin-dev] Using a storage engine without UTXO-index 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: Sat, 08 Apr 2017 21:24:08 -0000 I would advise anyone worried about 'hard drive access' to order a 512GB NVME (pci-express interface) flash drive (or a laptop), and I expect the performance will make you wonder why you ever bothered with cloud. My (very brief) analysis of the performance of a full chain download on a new laptop was that there was more overhead in lock contention and database writes and it barely loaded the machine. Now maybe this is because the flash **write** speed is slow (but still several orders of magnitude above spinning disk), but random reads are sure blazing fast. Flash storage sizes also appear to be growing at similiar rates as the total blockchain size. Which begs another question: In a distributed byzantine fault-tolerant system, why do we even need to bother with persistant storage, except for long-term archival and chain of custody issues, which we could serialize the in-memory structures out as a stream to things like tape drives or write-once optical media. On Fri, Apr 07, 2017 at 11:39:18AM -0700, Bram Cohen via bitcoin-dev wrote: > Expanding on this question a bit, it's optimized for parallel access, but > hard drive access isn't parallel and memory accesses are very fast, so > shouldn't the target of optimization be about cramming as much as possible > in memory and minimizing disk accesses? > > On Fri, Apr 7, 2017 at 11:18 AM, Gregory Maxwell via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > On Thu, Apr 6, 2017 at 10:12 PM, Tomas via bitcoin-dev > > wrote: > > >As this > > > solution, reversing the costs of outputs and inputs, seems to have > > > excellent performance characteristics (as shown in the test results), > > > updates to the protocol addressing the UTXO growth, might not be worth > > > considering *protocol improvements* > > > > I'm still lost on this-- AFAICT your proposals long term resource > > requirements are directly proportional to the amount of unspent output > > data, which grows over time at some fraction of the total transaction > > volume (plus the rate of spending which is more or less a constant). > > > > Can you help out my understanding here? > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev