[Monotone-devel] Re: RFC: Fake IDs

[Graydon Hoare]

Zack Weinberg wrote:

> To be clear, my primary motivation for the original patch was a worry
> that two places in the source code might decide to hard-code the
> *same* fake hash, and that they would then somehow collide.  (I think
> that in all of the places that currently use fake hashes, this can't
> happen, and anyway all the existing fake hashes are unique; however, I
> don't think we should have to rely on this staying so.  It would
> already be an unpleasant auditing exercise to verify that the existing
> fake hashes do not ever interact.)

Yeah, I understood that much, and it's definitely an improvement. I'm 
also sympathetic to the argument that passing the database around is a 
bit of a burden. I'd still like you to consider asking the database; or 
less: to construct some sufficiently large pool of fakes in advance and 
pass it in (eg: select from the database the set of IDs that have 24 '0' 
characters as a prefix, and record them as exceptions to the rule that 
any "%40.40llX" u64 is fair game, then pass that fact alone into your 
functions). You could also construct a bloom filter of all the values in 
the DB, or figure out a way to encode sentinel values that doesn't 
involve fake IDs (maybe make a disjoint vocab.cc type that can be either 
40 hex digits *or* the string "FAKE-NNNNNN", or ... lots of things.

My concern with your patch is that all it guarantees is that two 
different lines of code don't produce the same hash. You are then 
obliged to confirm that no two *dynamic control paths* use the same line 
of code to produce fakes that are used in ways that conflict. IOW it 
only seems to make the matter "a bit less likely" to be wrong; I'd 
prefer it went a bit further towards being certain that it's right.

-graydon