MIME-Version: 1.0
In-Reply-To: <20170224010943.GA29218@savin.petertodd.org>
References: <20170223011506.GC905@savin.petertodd.org>
	<CAAcC9ys5sUxVfOjogFiF3gzk51D_L=QQkOYevTH=qbh_RkA3Hw@mail.gmail.com>
	<CA+KqGkrUneGe4yORi=JAAWzoO0UftMUuJm3S-__W5sBh-+T1vQ@mail.gmail.com>
	<20170223235105.GA28497@savin.petertodd.org>
	<CA+KqGkowxEZeAFYa2JJchBDtRkg1p3YZNocivzu3fAtgRLDRBQ@mail.gmail.com>
	<20170224010943.GA29218@savin.petertodd.org>
From: Bram Cohen <bram@bittorrent.com>
Date: Thu, 23 Feb 2017 18:50:10 -0800
Message-ID: <CA+KqGkrOK76S3ffPJmpqYcBwtSeKESqN16yZsrwzDR6JZZmwFA@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a1140ec68d358cb05493dc924
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A Better MMR Definition
Precedence: list

--001a1140ec68d358cb05493dc924
Content-Type: text/plain; charset=UTF-8

On Thu, Feb 23, 2017 at 5:09 PM, Peter Todd <pete@petertodd.org> wrote:

> I think you've misunderstood what TXO commitments are. From my article:
>
> "A merkle tree committing to the state of all transaction outputs, both
> spent
> and unspent, can provide a method of compactly proving the current state
> of an
> output."
> -https://petertodd.org/2016/delayed-txo-commitments#txo-commitments:
>

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're using a more complex bespoke data
structure instead of a basic fundamental one.

--001a1140ec68d358cb05493dc924
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Feb 23, 2017 at 5:09 PM, Peter Todd <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>&gt;</span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-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, bot=
h spent<br>
and unspent, can provide a method of compactly proving the current state of=
 an<br>
output.&quot;<br>
-<a href=3D"https://petertodd.org/2016/delayed-txo-commitments#txo-commitme=
nts" rel=3D"noreferrer" target=3D"_blank">https://petertodd.org/2016/<wbr>d=
elayed-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 indic=
ate 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 d=
ata structure instead of a basic fundamental one.=C2=A0</div></div></div></=
div>

--001a1140ec68d358cb05493dc924--