-----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----- ------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk _______________________________________________ Bitcoin-development mailing list Bitcoinfirstname.lastname@example.org https://lists.sourceforge.net/lists/listinfo/bitcoin-development