Message-ID: <5277F166.9090606@monetize.io>
Date: Mon, 04 Nov 2013 11:11:34 -0800
From: Mark Friedenbach <mark@monetize.io>
Organization: Monetize.io Inc.
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
	rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <CANEZrP3iYBdg3p7Ru4O-UENY_yyQDA8=9PGn=KDKGGTrZ-xkRw@mail.gmail.com>	<20131104115314.GA1013@savin>	<CANEZrP1uqee1UO=zb+50t9BNtv2voTHoCKQCTQExNyoL=Y0=PA@mail.gmail.com>
	<20131104181649.GA3847@petertodd.org>
In-Reply-To: <20131104181649.GA3847@petertodd.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Bitcoin-development] Committing to extra block data/a better
 merge-mine standard
Precedence: list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/4/13 10:16 AM, Peter Todd wrote:
> Again, the right way to do this is define the standard to use the
> last txout so that midstate compression can be applied in the
> future. We can re-use this for merge-mining and other commitments
> easily by defining a simple standard based on defined path
> directions. Essentially for each thing you might want to commit,
> perhaps a merge-mined coin, a p2pool share, a UTXO commitment,
> whatever, generate a random 128-bit UUID.
> 
> Now interpret the bits of that UUID as an allowed path: 0 = left, 1
> = right, from the top of the tree. When you build the tree, make
> sure everything that is going to be committed to uses it's allowed
> path; the tree will look a bit jagged. If everyone picks their
> per-purpose UUIDs randomly the paths won't collide for very many
> levels on average, and path lengths will remain short. Validating
> that some given data was committed properly is simple and easy:
> just check the path, and check that the directions from the top of
> the tree followed the spec.

You mean... an authenticated prefix tree? Composable/commutative
properties are not needed as far as I can see, so you could make the
path validation, traversal, and proof size smaller by using level
compression.

I had previously proposed to this list a hash256-to-UUID mechanism
explicitly for this purpose. Recap: use 122 of the low 128 bits of the
aux-chain's genesis block to form a version=4 (random) or version=6
(previously unused) UUID. However since making that proposal I am now
leaning towards simply using the hash of the genesis block directly to
identify aux chains since level compression will allow longer keys
with the same path length.

I'm in the middle of writing BIPs to this end, among my many other
tasks. But basically it's the same as you describe ("OP_RETURN
<32-byte auth tree root>" for the last output), except keys don't
necessarily have to be UUIDs.

If there is general interest, I can make finishing this a higher priority.

Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSd/FmAAoJEAdzVfsmodw4pA0QALtgKLKsMNFocUanKGNp5T1F
918IjFt/HASRMs4GXiPpIeTB+o5Id6aCsg1ikKRuL9xD+WKoSyo83JP5UmcxGjFA
WTPi/0/ArYRh8L7ECvWoBSanNrun3z72p3KMI1Aa8qcJCgWbPx88AYeJv0Ki4JOo
1Pxc883772bOJnazrh4f/C4gcrqrlgs29PwI1rc3yCD9dmJhVmkz+O0/yfq+U8Gg
FXrpqR14mUM36wGX2HjqEual7Ry/7TEz5Ne4o8uncaVHtGgaYVw45a5Hk6rdo1rH
F3EV9nIpsLhGyqbKPqSxSju2h3eYQxQXKUP14mJS+ja/mKFXVc3PXDV+IHtXAplk
4gW8vtTWtVIDJAGTTh5RkJu5yAr57vq9lUMTNGGk6v1C3xOPP2C097sHRLaD4kD+
olsw5M9NW/Qpn1X3SCN3K85f7dvV3+fucmWL8mPM9KMLfc38fgs7I5SQgurMngsS
2D5jSwcZVjI/4n6ocgK3Y66yKC5xuzOOi2ZV+pPM38TjUeCF8fbjRnoIWyaBPDWy
mKA0bJiw5NMzi+IsNK5YDS5Gqb3qxS6tYLCp1+hesW3pBj35Zv/LdSh5DyecRETW
J0ye56lw/DfRAfNf+YERvrznqC2WVDZcQaElACq8R/nPJ2HD53p+SfxMSbljVO+I
SDsDOSvAzfQjQBLGdkx7
=5fPS
-----END PGP SIGNATURE-----