bwauths use FastFirstHopPK, which is deprecated.

It's a deprecated option scheduled for removal, but bwauths make use of it.

added component::core tor/torflow deprecated owner::tom points::1 priority::medium resolution::fixed severity::normal status::closed tor-dirauth try-and-find-out type::defect labels

Should they? It makes them stand out. What harm would it do if it stopped?

(We're not actually removing it in 0.3.0.x, so calling this an 0.3.1.x bug.)

Trac:
Milestone: Tor: 0.3.0.x-final to Tor: 0.3.1.x-final

Trac:
Milestone: Tor: 0.3.1.x-final to Tor: unspecified

It was used to measure relay CPU load by ensuring that the first connection fails if the relay's CPU is heavily loaded and it can't process create cells.

I bet that probably doesn't work the same way it used to, and even if it does, the client default and consensus default are both to use create cells anyway.

So we can safely remove this option, or ignore it, and bwauth behaviour won't change, at least in 0.3.1 once #21407 (moved) is merged.

Trac:
Summary: bwauths use FastFirstHopPK to bwauths use FastFirstHopPK, which is deprecated.
Points: N/A to 1
Keywords: N/A deleted, tor-dirauth try-and-find-out deprecated added

Trac:
Component: Core Tor/Tor to Core Tor/Torflow
Milestone: Tor: unspecified to N/A
Owner: N/A to tom

It sounds like (since bwauths aren't generally using 0.3.1) that this could cause some change so we should measure, correct?

I've removed 'FastFirstHopPK 0' from my torrcs and HUPed, so in a week we'll have some data on this.

Replying to tom:

It sounds like (since bwauths aren't generally using 0.3.1) that this could cause some change so we should measure, correct?

It shouldn't make any change. The bwauths were early adopters of the value 0 for this option, and in the many years since they started using 0, the rest of Tor caught up and everybody starting using 0. Then recently we took out the ability to choose anything other than 0.

(In earlier Tor versions, the networkstatus_get_param("usecreatefast") defaulted to 1, and in more recent Tor versions, it defaults to 0. But in either case, it uses the param set by the consensus, which has been 0 for years.)

tl;dr I think this is not a big deal, just delete the line and move on.

Oh okay, cool. I'll measure something else then!

Trac:
Status: new to closed
Resolution: N/A to invalid

This requires a change to the torflow repository, so we can't close it yet.

Trac:
Resolution: invalid to N/A
Status: closed to reopened

https://gitweb.torproject.org/torflow.git/commit/?id=1288389e699c03702aeae06b84d3c7905fe98387

Okay now we can close it.

Trac:
Status: reopened to closed
Resolution: N/A to fixed

closed

changed time estimate to 8h

mentioned in issue #24087 (moved)

moved to tpo/network-health/torflow#21393 (closed)