Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
T
Tor
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1,082
    • Issues 1,082
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 27
    • Merge Requests 27
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value Stream
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • The Tor Project
  • Core
  • Tor
  • Issues
  • #23126

Closed
Open
Created Aug 07, 2017 by Roger Dingledine@armaReporter

HSDirs should publish some count about new-style onion addresses (v3 metrics)

Right now we have an ongoing estimate of the total number of onion addresses published to the HSDirs: https://metrics.torproject.org/hidserv-dir-onions-seen.html

How many of those are 224-style onion addresses, and how many of them are legacy-style onion addresses?

I see a rep_hist_stored_maybe_new_hs() for the v2-style descriptors, and I think I see a

  /* XXX: Update HS statistics. We should have specific stats for v3. */

for the v3-style descriptors.

So I think that means that the graph is only showing v2-style onions, and we have no infrastructure for noticing trends with v3 style onions.

I also suspect that noticing trends is harder with v3-style onions, since each descriptor the hsdir sees is standalone, and it's not possible (without knowing the onion address) to link two descriptors to the same address.

So our only chance at estimating total number of v3 onion addresses is to know the publishing habits of v3 style onion services (how many descriptors per how much time period), and then publish the total number of descriptors we see, and folks can do some math afterwards to estimate number of running services? In any case we can see if the number goes up or down over time.

Or maybe there is some even better design? :)

The reason I bring it up now is (a) if we want to get any code into relays, we need to do it sufficiently before we need it, so it can get rolled out, and (b) I see discussions about bugs with v3-style onion services publishing every 2 minutes, and while we're fixing those we should keep in mind how handy it would be to be able to predict how many descriptors a new onion service will publish per time period on average.

Edited Nov 04, 2020 by George Kadianakis
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Tor: 0.4.5.x-stable
Milestone
Tor: 0.4.5.x-stable (Past due)
Assign milestone
Time tracking
None
Due date
None