MIME-Version: 1.0
In-Reply-To: <CAAS2fgTJ8xOj8zCmBq1LN9OdMV-tDfSjVUPhLpO98cR1w-QAoA@mail.gmail.com>
References: <1491516747.3791700.936828232.69F82904@webmail.messagingengine.com>
	<CAAS2fgTJ8xOj8zCmBq1LN9OdMV-tDfSjVUPhLpO98cR1w-QAoA@mail.gmail.com>
From: Bram Cohen <bram@bittorrent.com>
Date: Fri, 7 Apr 2017 11:39:18 -0700
Message-ID: <CA+KqGko0cDY29bhznMxJJ7yAUTuB6GaDDNGBRwzssJUxM_53xQ@mail.gmail.com>
To: Gregory Maxwell <greg@xiph.org>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a1144795482f3dc054c97f149
Subject: Re: [bitcoin-dev] Using a storage engine without UTXO-index
Precedence: list

--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
> <bitcoin-dev@lists.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),
> > 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

<div dir=3D"ltr">Expanding on this question a bit, it&#39;s optimized for p=
arallel access, but hard drive access isn&#39;t parallel and memory accesse=
s are very fast, so shouldn&#39;t the target of optimization be about cramm=
ing as much as possible in memory and minimizing disk accesses?</div><div c=
lass=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Apr 7, 2017 at =
11:18 AM, Gregory Maxwell via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"=
mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev=
@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><span class=3D"">On Thu, Apr 6, 2017 at 10:12 PM, Tomas via bitcoin=
-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt;As this<br>
&gt; solution, reversing the costs of outputs and inputs, seems to have<br>
&gt; excellent performance characteristics (as shown in the test results),<=
br>
&gt; updates to the protocol addressing the UTXO growth, might not be worth=
<br>
&gt; considering *protocol improvements*<br>
<br>
</span>I&#39;m still lost on this-- AFAICT your proposals long term resourc=
e<br>
requirements are directly proportional to the amount of unspent output<br>
data, which grows over time at some fraction of the total transaction<br>
volume (plus the rate of spending which is more or less a constant).<br>
<br>
Can you help out my understanding here?<br>
<div class=3D"HOEnZb"><div class=3D"h5">______________________________<wbr>=
_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>

--001a1144795482f3dc054c97f149--