questions from when i was reading through it

   RSA1024, DH1024, AES128, and SHA1, as discussed in

   rend-spec.txt. Except as noted, all RSA keys MUST have exponent

   values of 65537.

   [XXX -- is this last sentence new? I think we don't require it now. -RD]

   As in [proposal 220], all signatures are generated not over strings

   themselves, but over those strings prefixed with a distinguishing

   the client must know the introduction point and know the service's

   per-introduction-point authentication key from the hidden service

   descriptor.

   [XXX what exactly does the intro point check then? Seems like the

    intro point should be able to send a cell down the circuit to the

    service, even if the service doesn't like the cell. -RD]

   The final level of access control happens at the server itself, which

   may decide to respond or not respond to the client's request

        hsdir_spread_accept = an integer in range [1,128]

                             with default value 12.

[XXX I think I obsoleted this spread_accept notion? -RD]

   To determine where a given hidden service descriptor will be stored

   in a given period, after the blinded public key for that period is

   where shared_random_value is the shared value generated by the authorities

   in section [PUB-SHAREDRANDOM], and node_identity_digest is a SHA1 digest of

   the node's RSA public key as described in tor-spec.txt.

[XXX Maybe include a sentence about why SHA1 isn't scary here? -RD]

   Finally, for replicanum in 1...hsdir_n_replicas, the hidden service

   host uploads descriptors to the first hsdir_spread_store nodes whose

   as the SRV for time period TIME_PERIOD_NUM.

[Ok, this says clients. What do servers do? The same, right? Or should

 we let services choose to drop off in the disaster case? -RD]

2.3.2. Hidden services and changing shared random values

   It's theoretically possible that the consensus shared random values will

       the hidden service host does not need to have its private blinded

       key online.

2.5. Hidden service descriptors: encryption format [ENCRYPTED-DATA]

   The encrypted part of the hidden service descriptor is encrypted and

      'ed25519'. See [INTRO-AUTH] below.

     At least once:

[XXX Why not permit descriptors that list 0 intro points? I think

 they're permitted in the legacy rend design. -RD]

        "introduction-point" SP link-specifiers NL

   [TODO: The above will work fine with what we do today, but it will do

   quite badly if we ever freak out and want to go back to RSA2048 or

   bigger.  Do we care?]

   [Do we lose much by making AUTH_KEY_LEN and SIGLEN 2 bytes each? Or,

    even crazier, do we lose much by making those two variable sizes,

    defined by whichever value of AUTH_KEY_TYPE you pick? I guess we

    don't know how big it is if we don't recognize the key type, but we

    are already planning to refuse the intro request then. -RD]

3.1.2. Registering an introduction point on a legacy Tor node [LEGACY_EST_INTRO]

   cell, first documented in rend-spec.txt. New hidden service hosts

   must use this format when establishing introduction points at older

   Tor nodes that do not support the format above in [EST_INTRO].

   [If we roll out intro-point-side support early enough, then service

    hosts can simply avoid making intro points to old relays? -RD]

   In this older protocol, an ESTABLISH_INTRO cell contains:

       EXT_FIELD_LEN  [1 byte]

       EXT_FIELD      [EXT_FIELD_LEN bytes]

   [Worth mentioning that old-school Tor relays send back an empty

    payload here? Or, even better, not mentioning it if we simplify

    3.1.2 to "don't do that". -RD]

3.2. Sending an INTRODUCE1 cell to the introduction point. [SEND_INTRO1]

   In order to participate in the introduction protocol, a client must

   [TODO: Should we have a field to determine the type of ENCRYPTED, or

   should we instead assume that there is exactly one encryption key per

   encryption method? The latter is probably safer.]

   encryption method? The latter is probably safer.] [Agree -RD]

   Upon receiving an INTRODUCE1 cell, the introduction point checks

   whether AUTH_KEY and ENC_KEY match a configured introduction