On Mon, Nov 04, 2013 at 11:11:34AM -0800, Mark Friedenbach wrote:
> > 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.

You don't need level compression if you adopt my per-block randomization
idea. I think we'd be better off keeping the proofs as simple as
possible, just dumb merkle paths.

> 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 mentioned UUID more in spirit than in terms of the official UUID
standard; any large randomly picked integer is fine.

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

Wouldn't hurt to run the idea past forrestv, given p2pool will be
affected as it'd need to adopt the standard. He's run into some oddness
with mining hardware and nonces that would be good to understand. (note
how p2pool blocks don't commit to a fully random hash - there's some
extra bytes in there due to stratum or something IIRC)


Attachment: signature.asc
Description: Digital signature

DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
Bitcoin-development mailing list

Reply via email to