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 677B9BD3 for ; Fri, 7 Apr 2017 18:39:20 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f182.google.com (mail-io0-f182.google.com [209.85.223.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C26571D8 for ; Fri, 7 Apr 2017 18:39:19 +0000 (UTC) Received: by mail-io0-f182.google.com with SMTP id b140so55089127iof.1 for ; Fri, 07 Apr 2017 11:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bittorrent-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=14OfQiRQLSHQcFKmrWc4GInVkf4brfY89B3+4jt6GCE=; b=reDQxjlyS4tncBvifDCWuk7I+e8j1tnqdahNjoyIwflc+nZn2e7M5C38j1thBP10lA 6ol9SaKaDNcaZv8SYt/sABYYBTIALd7//IZ1z5VlYw0ffUqOrODKbRKW7zZcM13q1gbj 4cuwfKfp3Ay+tdtpjHl+0VfeTtPk5RV1ATX5OaGi6M9OHCZ+UfMTOGSvNtuyNJBr5x3y yzCCCR+uC1I5lpz1GxFBLO22ylj8WMsjojd+xZxI2eTWJyhE98iwt55DO4cySDrzkEWy zdZk7uREOn+0j6ts5arRIrKu78cwKgUzH/0C1j0KoxA7iT0sLbGTxn5S9y7H+HYbGAw6 ZLJA== 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=14OfQiRQLSHQcFKmrWc4GInVkf4brfY89B3+4jt6GCE=; b=lppJh7n9mfyQGE5cIHrhdsYbFMs5IRn/xrgBl5jBLRchQ6PaZdoBKZqYxDz4npu9Is DcqTcEE18V6gaK7J06KSZl93TnpjwXnMN67ExfKyBjCn/TfBqMzFNNq91Yj7WEvnXDdk ZUZMM/QqW+Vum9NW+qSSsT5TnHcCGC5uEJiJKYh1+qWqy67YTE1fM3QOnob6rtSSL/p5 zOEo99oDdcEvtoWQy/csfr6pRYsaPOGneSRhYeqKDxijdG6q7q29tlXt2gdWyxSqGz+k Y5nbOOfkdfBAmqBl3o7KgOKF0favAR+xS5dYvNp5G+G1Ceh1DbfUBGcEsQOT71JdSJdM 2Wpw== X-Gm-Message-State: AFeK/H2bWcQAAnZnt81ztVlOf5HCLrRnh46CH0Uip+AZQayGjT5w8dT03t2yBymAwerDyBgnKK2k28gR2etqmT2B X-Received: by 10.107.50.206 with SMTP id y197mr41722232ioy.214.1491590359201; Fri, 07 Apr 2017 11:39:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.184.70 with HTTP; Fri, 7 Apr 2017 11:39:18 -0700 (PDT) In-Reply-To: References: <1491516747.3791700.936828232.69F82904@webmail.messagingengine.com> From: Bram Cohen Date: Fri, 7 Apr 2017 11:39:18 -0700 Message-ID: To: Gregory Maxwell , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=001a1144795482f3dc054c97f149 X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, 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 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: Fri, 07 Apr 2017 18:39:20 -0000 --001a1144795482f3dc054c97f149 Content-Type: text/plain; charset=UTF-8 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 > --001a1144795482f3dc054c97f149 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Expanding on this question a bit, it's optimized for p= arallel access, but hard drive access isn't parallel and memory accesse= s are very fast, so shouldn't the target of optimization be about cramm= ing 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
<bitcoin-dev@li= sts.linuxfoundation.org> wrote:
>As this
> solution, reversing the costs of outputs and inputs, seems to have
> excellent performance characteristics (as shown in the test results),<= br> > 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 resourc= e
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

--001a1144795482f3dc054c97f149--