Date: Thu, 23 Feb 2017 20:09:43 -0500
From: Peter Todd <pete@petertodd.org>
To: Bram Cohen <bram@bittorrent.com>
Message-ID: <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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="XsQoSWH+UP9D9v3l"
Content-Disposition: inline
In-Reply-To: <CA+KqGkowxEZeAFYa2JJchBDtRkg1p3YZNocivzu3fAtgRLDRBQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A Better MMR Definition
Precedence: list


--XsQoSWH+UP9D9v3l
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 23, 2017 at 04:49:01PM -0800, Bram Cohen wrote:
> On Thu, Feb 23, 2017 at 3:51 PM, Peter Todd <pete@petertodd.org> wrote:
>=20
> > On Thu, Feb 23, 2017 at 03:13:43PM -0800, Bram Cohen wrote:
> > >
> > > I can't speak to MMRs (they look a bit redundant with the actual
> > blockchain
> > > history to my eye) but circling back to utxo commitments, the benefits
> > are
> >
> > In what way do you see MMRs as redundant?
> >
>=20
> You can readily prove something is in the TXO or STXO set using the actual
> blockchain, and the proofs will be nice and compact because even light
> nodes are expected to already have all the historical headers.
>=20
> What you can't do with MMRs or the blockchain is make a compact proof that
> something is still in the utxo set, which is the whole point of utxo
> commitments.

I think you've misunderstood what TXO commitments are. From my article:

"A merkle tree committing to the state of all transaction outputs, both spe=
nt
and unspent, can provide a method of compactly proving the current state of=
 an
output."
-https://petertodd.org/2016/delayed-txo-commitments#txo-commitments:

I'm proposing that we commit to not just the set of transaction outputs, but
also the current *state* of those outputs, with the same commitment structu=
re.

Concretely, each leaf node in the TXO commitment tree needs to commit to - =
at
minimum - the outpoint (txid:n) and spent/unspent status (possibly structur=
ally
as mentioned elsewhere in this thread). It's probably also valuable to comm=
it
to the scriptPubKey, nValue, as well, though technically that's redundant as
the txid already commits to that (there's some implementation options here).

> It's totally reasonable for full nodes to independently update and
> recalculate the utxo set as part of their validation process. The same
> can't be done for a balanced version of the txo set because it's too big.

Why would you commit to a balanced version of the TXO set? I'm proposing
committing to an insertion-ordered list, indexed by txout #.

> Relying on proofs as a crutch for using the full txo set would badly
> exacerbate the already extant problem of miners doing spv mining, and
> increase the bandwidth a full validating node had to use by a multiple.
>=20
> This whole conversation is badly sidetracked. If people have comments on =
my
> merkle set I'd like to engage further with them, but mmrs need to be argu=
ed
> independently on their own merits before being used as a counterpoint to
> utxo commitments.

Hmm? That's exactly what I'm doing. Also, as per the above, I think you've
misunderstood what my TXO commitment proposal is.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--XsQoSWH+UP9D9v3l
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJYr4fUAAoJECSBQD2l8JH7UfUH/AvnHiGtP5/Y2XezQqp67cgW
nnQIH8ep28NF7yaUH5qSeK2ONrm53qYJog6wEsFYmxlED4Jx4muH/RQb+NjA/zDt
QvmOTmsq43Io6YWBlOGBSioXoG/Nzb1C5iNfkLThNUIqbcOMBk+KZWj5hy/iNKE9
pruOWvEteWwnK//YZVo7KJktYVoq6uyxQrkf74828FLf6GR4EgP2F9o2lnCwIL5f
kwaY71uKguk89l8AdlHJ70ti600SG/D24h8Pa+u2LdEYDE404PF+cjS3d/XtPN/b
TJ+4DPTo52gheHNhDp8UlSE/NwTYtjszfONR7uSiQaDFBMmQKByvDlW/kEkdlIg=
=Zw33
-----END PGP SIGNATURE-----

--XsQoSWH+UP9D9v3l--