<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Feb 23, 2017 at 5:09 PM, Peter Todd <span dir="ltr">&lt;<a href="mailto:pete@petertodd.org" target="_blank">pete@petertodd.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think you&#39;ve misunderstood what TXO commitments are. From my article:<br>
<br>
&quot;A merkle tree committing to the state of all transaction outputs, both spent<br>
and unspent, can provide a method of compactly proving the current state of an<br>
output.&quot;<br>
-<a href="https://petertodd.org/2016/delayed-txo-commitments#txo-commitments" rel="noreferrer" target="_blank">https://petertodd.org/2016/<wbr>delayed-txo-commitments#txo-<wbr>commitments</a>:<br></blockquote><div><br></div><div>The proposal on that page is of a tree which does require random access updates, it just positions entries in the order they happened to be added instead of sorting by their hash. Once you start updating it to indicate spent status all the exact same issues of TXO size and cache coherence on updates show up again, but now you&#39;re using a more complex bespoke data structure instead of a basic fundamental one. </div></div></div></div>