MIME-Version: 1.0
In-Reply-To: <CA+KqGkrNDEUB8yzkX+ya1ikb46zmKA6Bt4-skqUgLzo=nnNtUw@mail.gmail.com>
References: <20170223235105.GA28497@savin.petertodd.org>
	<CA+KqGkowxEZeAFYa2JJchBDtRkg1p3YZNocivzu3fAtgRLDRBQ@mail.gmail.com>
	<20170224010943.GA29218@savin.petertodd.org>
	<CA+KqGkrOK76S3ffPJmpqYcBwtSeKESqN16yZsrwzDR6JZZmwFA@mail.gmail.com>
	<20170224025811.GA31911@savin.petertodd.org>
	<CA+KqGkq7gavAnAk-tcA+gxL2sWpv3ENhEmHrQHaPdyAsKrLjGg@mail.gmail.com>
	<20170224031531.GA32118@savin.petertodd.org>
	<CA+KqGkrfhg3GnbWwvKXHQ2NWuCnfzYyTPUxRhzYMuDBiNQR4eA@mail.gmail.com>
	<20170224043613.GA32502@savin.petertodd.org>
	<CA+KqGkpi4GvgU-K6vt-U5ZN4AkpjZ0rruzddoJS4-V0TcnyqUQ@mail.gmail.com>
	<20170225041202.GA11152@savin.petertodd.org>
	<CA+KqGkqs8F1hK6y-JnLFRpqhQ5i8i+MXVmtGUQBYmE5d1OCAAg@mail.gmail.com>
	<CAHUwRvtseXUx_ShfHd9r9LW1_8cJYcofQ4s1vEpkpKJEniDTzA@mail.gmail.com>
	<CA+KqGkrNDEUB8yzkX+ya1ikb46zmKA6Bt4-skqUgLzo=nnNtUw@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
Date: Tue, 28 Feb 2017 15:24:28 -0800
Message-ID: <CAPg+sBgyToj8NcYSFJ376WNLGXO7aSwpZRvd0zuFeB=rF14rfg@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
	Bram Cohen <bram@bittorrent.com>
Content-Type: multipart/alternative; boundary=001a1146060e59d0fe05499f7f61
Subject: Re: [bitcoin-dev] A Better MMR Definition
Precedence: list

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

On Feb 28, 2017 15:10, "Bram Cohen via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

On Tue, Feb 28, 2017 at 8:43 AM, G. Andrew Stone <g.andrew.stone@gmail.com>
wrote:

>
> But since transactions' prevouts are not specified by [block height, tx
> index, output index] or by TXO index, I don't understand how an insertion
> ordered TXO tree can result in efficient lookups.  Can you help me
> understand this?
>

You have to have a lookup table going from prevouts to txo index. Lookups
on that are relatively fast because looking up things in a hashtable is a
single cache miss, while looking up things in a tree is logarithmic cache
misses.


I'm wondering if there is some confusion here.

Yes, someone needs to have a lookup table from prevouts to TXO tree
positions. But because an insertion-ordered TXO tree does not rebalance,
that table can be maintained by wallets or service providers for just their
own coins, instead of by every full node and miner individually for
everyone's coins.

In the simplest committed TXO model, full nodes simply maintain the TXO
root hash, and every transaction/block comes with a proof that its inputs
are in the TXO tree, and the necessary information to update the root after
spending the inputs and adding the outputs.

-- 
Pieter

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

<div dir=3D"auto"><div class=3D"gmail_extra" dir=3D"auto"><div class=3D"gma=
il_quote">On Feb 28, 2017 15:10, &quot;Bram Cohen via bitcoin-dev&quot; &lt=
;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists=
.linuxfoundation.org</a>&gt; wrote:<br type=3D"attribution"><blockquote cla=
ss=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote"><div class=3D"quoted-text">On Tue, Feb 28, 2017 at 8:43 AM, G. Andrew=
 Stone <span dir=3D"ltr">&lt;<a href=3D"mailto:g.andrew.stone@gmail.com" ta=
rget=3D"_blank">g.andrew.stone@gmail.com</a>&gt;</span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr"><div><div><div><br></div>But since t=
ransactions&#39; prevouts are not specified by [block height, tx index, out=
put index] or by TXO index, I don&#39;t understand how an insertion ordered=
 TXO tree can result in efficient lookups.=C2=A0 Can you help me understand=
 this?<br></div></div></div></blockquote><div><br></div></div><div>You have=
 to have a lookup table going from prevouts to txo index. Lookups on that a=
re relatively fast because looking up things in a hashtable is a single cac=
he miss, while looking up things in a tree is logarithmic cache misses.</di=
v></div></div></div></blockquote></div></div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">I&#39;m wondering if there is some confusion here.</div><di=
v dir=3D"auto"><br></div><div dir=3D"auto">Yes, someone needs to have a loo=
kup table from prevouts to TXO tree positions. But because an insertion-ord=
ered TXO tree does not rebalance, that table can be maintained by wallets o=
r service providers for just their own coins, instead of by every full node=
 and miner individually for everyone&#39;s coins.</div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">In the simplest committed TXO model, full nodes s=
imply maintain the TXO root hash, and every transaction/block comes with a =
proof that its inputs are in the TXO tree, and the necessary information to=
 update the root after spending the inputs and adding the outputs.</div><di=
v dir=3D"auto"><br></div><div dir=3D"auto">--=C2=A0</div><div dir=3D"auto">=
Pieter</div><div dir=3D"auto"><br></div><div class=3D"gmail_extra" dir=3D"a=
uto"></div></div>

--001a1146060e59d0fe05499f7f61--