MIME-Version: 1.0
In-Reply-To: <20170224031531.GA32118@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>
	<CA+KqGkrOK76S3ffPJmpqYcBwtSeKESqN16yZsrwzDR6JZZmwFA@mail.gmail.com>
	<20170224025811.GA31911@savin.petertodd.org>
	<CA+KqGkq7gavAnAk-tcA+gxL2sWpv3ENhEmHrQHaPdyAsKrLjGg@mail.gmail.com>
	<20170224031531.GA32118@savin.petertodd.org>
From: Bram Cohen <bram@bittorrent.com>
Date: Thu, 23 Feb 2017 19:32:43 -0800
Message-ID: <CA+KqGkrfhg3GnbWwvKXHQ2NWuCnfzYyTPUxRhzYMuDBiNQR4eA@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a11440182fdfdd905493e618e
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A Better MMR Definition
Precedence: list

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

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

>
> Glad we're on the same page with regard to what's possible in TXO
> commitments.
>
> Secondly, am I correct in saying your UTXO commitments scheme requires
> random
> access? While you describe it as a "merkle set", obviously to be merkelized
> it'll have to have an ordering of some kind. What do you propose that
> ordering
> to be?
>

The ordering is by the bits in the hash. Technically it's a Patricia Trie.
I'm using 'merkle tree' to refer to basically anything with a hash root.


> Maybe more specifically, what exact values do you propose to be in the set?
>
>
That is unspecified in the implementation, it just takes a 256 bit value
which is presumably a hash of something. The intention is to nail down a
simple format and demonstrate good performance and leave those semantics to
a higher layer. The simplest thing would be to hash together the txid and
output number.

--001a11440182fdfdd905493e618e
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 7:15 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"><div class=3D"HOEnZb"><div class=
=3D"h5"><br>
</div></div>Glad we&#39;re on the same page with regard to what&#39;s possi=
ble in TXO commitments.<br>
<br>
Secondly, am I correct in saying your UTXO commitments scheme requires rand=
om<br>
access? While you describe it as a &quot;merkle set&quot;, obviously to be =
merkelized<br>
it&#39;ll have to have an ordering of some kind. What do you propose that o=
rdering<br>
to be?<br></blockquote><div><br></div><div>The ordering is by the bits in t=
he hash. Technically it&#39;s a Patricia Trie. I&#39;m using &#39;merkle tr=
ee&#39; to refer to basically anything with a hash root.</div><div>=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">Maybe more specifically, what exact valu=
es do you propose to be in the set?<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div><=
br></div><div>That is unspecified in the implementation, it just takes a 25=
6 bit value which is presumably a hash of something. The intention is to na=
il down a simple format and demonstrate good performance and leave those se=
mantics to a higher layer. The simplest thing would be to hash together the=
 txid and output number.</div></div></div></div>

--001a11440182fdfdd905493e618e--