Hacker News Reader

Comment by kstrauser | Hacker News Reader

I’m not sure you appreciate how large that data structure would be if you had to ship it inside the app.

The idea is to only distribute the root of the tree to a client, query the server for the username you want to look up, which then returns the key and a short proof that this username maps to that key within the hash tree identified by the known root.

How is that substantially better than an API that returns a user’s key?

If the service provider (ie. the X.com servers) are evil, then the API can return false data and the client has no way to know.

However, with a merkle tree, the root hash is embedded into the app, and the servers return the data together with info chaining to the merkle root (typically a few kilobytes, even if the whole tree is hundreds of gigabytes).

With that info, the app can verify the chain to the root and be sure that the servers aren't returning false data.

To clarify the above. It protects against endpoint compromise but depends on the assumption that the service operator (the one computing the root hash) is trustworthy. In other words it significantly reduces attack surface.

It can be done with Merkel trees. You just ship the root hash.

Merkel trees are snapshot/read only though - so you then use a bitcoin style Blockchain to ship refreshed versions of the root tree hash (you can even ship it in the actual bitcoin Blockchain if you like, piggybacking on its proof of work to ensure different people don't see different root hashes)

I'm sure shipping a >150GB file to every user is perfectly fine and sound engineering.

It's not _that_ far off from shipping a 3GB chrome webapp disguised as a desktop app (cough electron)

What’s a couple orders of magnitude between friends?

Parent comment writes: "ship[ing] the tree root hash", for a merkle tree ("bitcoin style") this would just be a single (small) hash no matter the tree size, i.e. 32 bytes is enough.

Reply on news.ycombinator.com