<div dir="ltr">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?</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 7, 2017 at 11:18 AM, Gregory Maxwell via bitcoin-dev <span dir="ltr"><<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Apr 6, 2017 at 10:12 PM, Tomas via bitcoin-dev<br>
<<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>> wrote:<br>
>As this<br>
> solution, reversing the costs of outputs and inputs, seems to have<br>
> excellent performance characteristics (as shown in the test results),<br>
> updates to the protocol addressing the UTXO growth, might not be worth<br>
> considering *protocol improvements*<br>
<br>
</span>I'm still lost on this-- AFAICT your proposals long term resource<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="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>