Re: [tor-bugs] #18967 [Metrics/Onionoo]: Add UUID to families in Onionoo

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#18967: Add UUID to families in Onionoo
-----------------------------+---------------------
 Reporter:  seansaito        |          Owner:
     Type:  enhancement      |         Status:  new
 Priority:  Medium           |      Milestone:
Component:  Metrics/Onionoo  |        Version:
 Severity:  Normal           |     Resolution:
 Keywords:  persistence,     |  Actual Points:
Parent ID:                   |         Points:
 Reviewer:                   |        Sponsor:
-----------------------------+---------------------

Comment (by karsten):

 Replying to [comment:4 virgil]:
 > If an Onionoo is allowed to skip some consensuses, doesn't that mean the
 family UUIDs must be a function of *solely* the most recent consensus?
 >
 > Not to say that's impossible, but that's a huge constraint.

 Not skip but reorder, but you're right, it's a constraint, maybe a too big
 one.

 > Even if you require a complete record going back `k` steps, you're going
 to lose any persistence going back `>k` steps.  Instead of accepting that
 the Onionoo server will have gaps in its consensus history, wouldn't it be
 better simply to put them on a blockchain of some sort?

 Let's not over-engineer this, but I could imagine us designing something
 based on your suggestion before editing your comment:

 > Another solution would be that the UUID is a function of the last $k$
 consensuses.  And for an Onionoo server to update the family, it must have
 the a k-length sequence of consecutive consensuses.

 Consensuses are the wrong descriptor type, because we're only interested
 in mutual agreements that two relays A and B are in the same family,
 regardless of what the directory authorities think.  And consensuses don't
 contain family information, so we'd have to follow references to server
 descriptors, which makes this harder to implement.  We could simply look
 at server descriptors published in the past `k` hours or days.  And it's
 probably okay if an Onionoo server misses a single server descriptor,
 because that kind of inconsistency will heal by itself once that server
 descriptor is older than `k` hours.

 Would you two want to suggest a UUID algorithm based only on server
 descriptors published in the past `k` hours?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18967#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs