Date: Sun, 22 May 2016 04:55:33 -0400
From: Peter Todd <pete@petertodd.org>
To: Johnson Lau <jl2012@xbt.hk>
Message-ID: <20160522085533.GA10746@fedora-21-dvm>
References: <20160517132311.GA21656@fedora-21-dvm>
	<68A4772D-D423-45F9-ADB7-95BEB3E66F43@xbt.hk>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO"
Content-Disposition: inline
In-Reply-To: <68A4772D-D423-45F9-ADB7-95BEB3E66F43@xbt.hk>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Making UTXO Set Growth Irrelevant With
 Low-Latency Delayed TXO Commitments
Precedence: list


--2oS5YaxWCcQjTEyO
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, May 20, 2016 at 11:46:32AM +0200, Johnson Lau wrote:
> How is this compared to my earlier proposal: https://lists.linuxfoundatio=
n.org/pipermail/bitcoin-dev/2015-December/011952.html <https://lists.linuxf=
oundation.org/pipermail/bitcoin-dev/2015-December/011952.html> ?
>=20
> In my proposal, only the (pruned) UTXO set, and 32 bytes per archived blo=
ck, are required for mining. But it is probably more difficult for people t=
o spend an archived output. They need to know the status of other archived =
outputs from the same block. A full re-scan of the blockchain may be needed=
 to generate the proof but this could be done by a third party archival nod=
e.

We're working along the same lines, but my proposal is much better fleshed =
out;
I think you'll find you missed a few details if you flesh out yours in more
detail. For instance, since your dormant UTXO list is indexed by UTXO
expiration order, it's not possible to do any kind of verification that the
contents of that commitment are correct without the global state of all UTXO
data - you have no ability to locally verify as nothing commits to the cont=
ents
of the UTXO set.

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

--2oS5YaxWCcQjTEyO
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

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

iQEcBAEBCAAGBQJXQXQDAAoJEGOZARBE6K+y4/AH/3PwJINWeyMk36AsKlxNLgXK
2AiTh5EjYxgOicgpGi30fyR/TbzWltcOKwaVAxlPMiexmzuYV6smJ7yHyxdkW/Q5
pF3T5itshF1X87XMMF8sLvrBCu64uu0mYDwY9L75QU/SwXMwF7tv+YhCxzPtqIww
tsl5rjY3pFmw6uQudw1KgihbK7jD2zO6/UhBs72sYKvzEhBk6NxU1Ab8Hk0ua1Xt
IOI+CcvlPhhzyfkaSM8B1LjW+L1e6i3ZY4RRkNqriWkQaE/HKNqkHLK8sKTJpILH
L/lwq+uG9F+NHAbR3ZdX03f0+M3X8jSur4ZlwwU2ADvN7sE2J8mvVn1PF0TELfY=
=EkEa
-----END PGP SIGNATURE-----

--2oS5YaxWCcQjTEyO--