<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>Answering both,<br></div>
<div><br></div>
<div>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">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br></div>
<blockquote type="cite"><div><div defang_data-gmailquote="yes"><blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;" defang_data-gmailquote="yes"><div><br></div>
<div>I'm still lost on this-- AFAICT your proposals long term resource<br></div>
<div>requirements are directly proportional to the amount of unspent output<br></div>
<div>data, which grows over time at some fraction of the total transaction<br></div>
<div>volume (plus the rate of spending which is more or less a constant).<br></div>
<div><div><br></div>
</div>
<div>Can you help out my understanding here?<br></div>
<div><div><br></div>
</div>
</blockquote></div>
</div>
</blockquote><div><br></div>
<div>On Fri, Apr 7, 2017, at 20:39, Bram Cohen wrote:<br></div>
<blockquote type="cite"><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?<br></div>
</blockquote><div><br></div>
<div>The long term *minimal disk storage* requirement, can obviously not be less then all the unspent outputs. Minimal disk requirements is not something bitcrust attempts to address.<br></div>
<div><br></div>
<div> The storage that is accessed during peak load (block validation with pre-synced transactions), is minimized as this only needs the transaction index (to lookup ptrs from hashes), the tip of the spend-tree and the tip of the spend-index (together to check double spents/spending non-existing outputs). These not only easily fit in RAM, but are accessed in a cache efficient way. *These* only grow with inputs as the spend tree contains one record per input referencing the output being spent.<br></div>
<div><br></div>
<div>Script validation is also not something bitcrust *directly* addresses; it uses libbitcoinconsensus for the actual validation and lookups to outputs are mostly similar. They are kept fast by trusting the OS on MRU caching of transaction-outputs; I don't think that for this part the UTXO index has much drawbacks,. Bitcrust seems to have a small advantage due to the awesomeness of Rayon's parallelization and the lock-free data structures, but a disadvantage in that keeping all spent outputs decreases spatial locality of reference. Script validation is not the innovative part.<br></div>
<div><br></div>
<div>Tomas<br></div>
</body>
</html>