Walking onions proposal is completed.

Or at least, the first version of it.

1 files changed, 4113 insertions, 0 deletions

diff --git a/proposals/323-walking-onions-full.md b/proposals/323-walking-onions-full.md
new file mode 100644
index 0000000..d1c054d
--- /dev/null
+++ b/proposals/323-walking-onions-full.md
@@ -0,0 +1,4113 @@
+```
+Filename: 323-walking-onions-full.md
+Title: Specification for Walking Onions
+Author: Nick Mathewson
+Created: 3 June 2020
+Status: Draft
+```
+
+
+<!-- Section 1 --> <a id='S1'></a>
+
+# Introduction: A Specification for Walking Onions
+
+In Proposal 300, I introduced Walking Onions, a design for scaling
+Tor and simplifying clients, by removing the requirement that every
+client know about every relay on the network.
+
+This proposal will elaborate on the original Walking Onions idea,
+and should provide enough detail to allow multiple compatible
+implementations. In this introduction, I'll start by summarizing the
+key ideas of Walking Onions, and then outline how the rest of this
+proposal will be structured.
+
+<!-- Section 1.1 --> <a id='S1.1'></a>
+
+## Remind me about Walking Onions again?
+
+With Tor's current design, every client downloads and refreshes a
+set of directory documents that describe the directory authorities'
+views about every single relay on the Tor network.  This requirement
+makes directory bandwidth usage grow quadratically, since the
+directory size grows linearly with the number of relays, and it is
+downloaded a number of times that grows linearly with the number of
+clients.  Additionally, low-bandwidth clients and bootstrapping
+clients spend a disproportionate amount of their bandwidth loading
+directory information.
+
+With these drawbacks, why does Tor still require clients to
+download a directory?  It does so in order to prevent attacks that
+would be possible if clients let somebody else choose their
+paths through the network, or if each client chose its paths from a
+different subset of relays.
+
+Walking Onions is a design that resists these attacks without
+requiring clients ever to have a complete view of the network.
+
+You can think of the Walking Onions design like this: Imagine that with
+the current Tor design, the client covers a wall with little pieces
+of paper, each representing a relay, and then throws a dart at the wall
+to pick a relay.  Low-bandwidth relays get small pieces of paper;
+high-bandwidth relays get large pieces of paper.  With the Walking
+Onions design, however, the client throws its dart at a _blank
+wall_, notes the position of the dart, and asks for the relay whose
+paper _would be_ at that position on a "standard wall".  These
+"standard walls" are mapped out by directory authorities in advance,
+and are authenticated in such a way that the client can receive a
+proof of a relay's position on the wall without actually having to
+know the whole wall.
+
+Because the client itself picks the position on the wall, and
+because the authorities must vote together to build a set of
+"standard walls", nobody else controls the client's path through the
+network, and all clients can choose their paths in the same way.
+But since clients only probe one position on the wall at a time,
+they don't need to download a complete directory.
+
+(Note that there has to be more than one wall at a time: the client
+throws darts at one wall to pick guards, another wall to pick
+middle relays, and so on.)
+
+In Walking Onions, we call a collection of standard walls an
+"ENDIVE" (Efficient Network Directory with Individually Verifiable
+Entries).  We call each of the individual walls a "routing index",
+and we call each of the little pieces of paper describing a relay and
+its position within the routing index a "SNIP" (Separable Network
+Index Proof).
+
+For more details about the key ideas behind Walking Onions, see
+proposal 300.  For more detailed analysis and discussion, see
+"Walking Onions: Scaling Anonymity Networks while Protecting Users"
+by Komlo, Mathewson, and Goldberg.
+
+<!-- Section 1.2 --> <a id='S1.2'></a>
+
+## The rest of this document
+
+This proposal is unusually long, since Walking Onions touches on many
+aspects of Tor's functionality.  It requires changes to voting,
+directory formats, directory operations, circuit building, path
+selection, client operations, and more.  These changes are described in the
+sections listed below.
+
+Here in section 1, we briefly reintroduce Walking Onions, and talk
+about the rest of this proposal.
+
+Section 2 will describe the formats for ENDIVEs, SNIPs, and related
+documents.
+
+Section 3 will describe new behavior for directory authorities as
+they vote on and produce ENDIVEs.
+
+Section 4 describes how relays fetch and reconstruct ENDIVEs from
+the directory authorities.
+
+Section 5 has the necessary changes to Tor's circuit extension
+protocol so that clients can extend to relays by index position.
+
+Section 6 describes new behaviors for clients as they use Walking
+Onions, to retain existing Tor functionality for circuit construction.
+
+Section 7 explains how to implement onion services using Walking
+Onions.
+
+Section 8 describes small alterations in client and relay behavior
+to strengthen clients against some kinds of attacks based on relays
+picking among multiple ENDIVEs, while still making the voting
+system robust against transient authority failures.
+
+Section 9 closes with a discussion of how to migrate from the
+existing Tor design to the new system proposed here.
+
+<!-- Section 1.2.1 --> <a id='S1.2.1'></a>
+
+### Appendices
+
+Additionally, this proposal has several appendices:
+
+Appendix A defines commonly used terms.
+
+Appendix B provides definitions for CDDL grammar productions that
+are used elsewhere in the documents.
+
+Appendix C lists the new elements in the protocol that will require
+assigned values.
+
+Appendix D lists new network parameters that authorities must vote
+on.
+
+Appendix E gives a sorting algorithm for a subset of the CBOR object
+representation.
+
+Appendix F gives an example set of possible "voting rules" that
+authorities could use to produce an ENDIVE.
+
+Appendix G lists the different routing indices that will be required
+in a Walking Onions deployment.
+
+Appendix H discusses partitioning TCP ports into a small number of
+subsets, so that relays' exit policies can be represented only as
+the group of ports that they support.
+
+Appendix Z closes with acknowledgments.
+
+<!-- Section 1.2.2 --> <a id='S1.2.2'></a>
+
+### Related proposals
+
+The following proposals are not part of the Walking Onions proposal,
+but they were written at the same time, and are either helpful or
+necessary for its implementation.
+
+318-limit-protovers.md restricts the allowed version numbers for
+each subprotocol to the range 0..63.
+
+319-wide-everything.md gives a general mechanism for splitting relay
+commands across more than one cell.
+
+320-tap-out-again.md attempts to remove the need for TAP keys in
+the HSv2 protocol.
+
+321-happy-families.md lets families be represented with a single
+identifier, rather than a long list of keys
+
+322-dirport-linkspec.md allows a directory port to be represented
+with a link specifier.
+
+<!-- Section 2 --> <a id='S2'></a>
+
+# Document Formats: ENDIVEs and SNIPs
+
+Here we specify a pair of related document formats that we will
+use for specifying SNIPs and ENDIVEs.
+
+Recall from proposal 300 that a SNIP is a set of information about
+a single relay, plus proof from the directory authorities that the
+given relay occupies a given range in a certain routing index.
+For example, we can imagine that a SNIP might say:
+
+* Relay X has the following IP, port, and onion key.
+* In the routing index Y, it occupies index positions 0x20002
+  through 0x23000.
+* This SNIP is valid on 2020-12-09 00:00:00, for one hour.
+* Here is a signature of all the above text, using a threshold
+  signature algorithm.
+
+You can think of a SNIP as a signed combination of a routerstatus and
+a microdescriptor... together with a little bit of the randomized
+routing table from Tor's current path selection code, all wrapped
+in a signature.
+
+Every relay keeps a set of SNIPs, and serves them to clients when
+the client is extending by a routing index position.
+
+An ENDIVE is a complete set of SNIPs.  Relays download ENDIVEs, or
+diffs between ENDIVEs, once every voting period.  We'll accept some
+complexity in order to make these diffs small, even though some of the
+information in them (particularly SNIP signatures and index
+ranges) will tend to change with every period.
+
+<!-- Section 2.1 --> <a id='S2.1'></a>
+
+## Preliminaries and scope
+
+<!-- Section 2.1.1 --> <a id='S2.1.1'></a>
+
+### Goals for our formats
+
+We want SNIPs to be small, since they need to be sent on the wire
+one at a time, and won't get much benefit from compression.  (To
+avoid a side-channel, we want CREATED cells to all be the same
+size, which means we need to pad up to the largest size possible
+for a SNIP.)
+
+We want to place as few requirements on clients as possible, and we
+want to preserve forward compatibility.
+
+We want ENDIVEs to be compressible, and small. We want successive
+ENDIVEs to be textually similar, so that we can use diffs to
+transmit only the parts that change.
+
+We should preserve our policy of requiring only loose time
+synchronization between clients and relays, and allow even looser
+synchronization when possible.  Where possible, we'll make the
+permitted skew explicit in the protocol: for example, rather than
+saying "you can accept a document 10 minutes before it is valid", we
+will just make the validity interval start 10 minutes earlier.
+
+<!-- Section 2.1.2 --> <a id='S2.1.2'></a>
+
+### Notes on Metaformat
+
+In the format descriptions below, we will describe a set of
+documents in the CBOR metaformat, as specified in RFC 7049.  If
+you're not familiar with CBOR, you can think of it as a simple
+binary version of JSON, optimized first for simplicity of
+implementation and second for space.
+
+I've chosen CBOR because it's schema-free (you can parse it
+without knowing what it is), terse, dumpable as text, extensible,
+standardized, and very easy to parse and encode.
+
+We will choose to represent many size-critical types as maps whose
+keys are short integers: this is slightly shorter in its encoding
+than string-based dictionaries.  In some cases, we make types even
+shorter by using arrays rather than maps, but only when we are
+confident we will not have to make changes to the number of elements
+in the future.
+
+We'll use CDDL (defined in RFC 8610) to describe the data in a way
+that can be validated -- and hopefully, in a way that will make it
+comprehensible. (The state of CDDL tooling is a bit lacking at the
+moment, so my CDDL validation will likely be imperfect.)
+
+We make the following restrictions to CBOR documents that Tor
+implementations will _generate_:
+
+   * No floating-point values are permitted.
+
+   * No tags are allowed unless otherwise specified.
+
+   * All items must follow the rules of RFC 7049 section 3.9 for
+     canonical encoding, unless otherwise specified.
+
+Implementations SHOULD accept and parse documents that are not
+generated according to these rules, for future extensibility.
+However, implementations SHOULD reject documents that are not
+"well-formed" and "valid" by the definitions of RFC 7049.
+
+<!-- Section 2.1.3 --> <a id='S2.1.3'></a>
+
+### Design overview: signing documents
+
+We try to use a single document-signing approach here, using a hash
+function parameterized to accommodate lifespan information and an
+optional nonce.
+
+All the signed CBOR data used in this format is represented as a
+binary string, so that CBOR-processing tools are less likely to
+re-encode or transform it.   We denote this below with the CDDL syntax
+`bstr .cbor Object`, which means "a binary string that must hold a valid
+encoding of a CBOR object whose type is `Object`".
+
+<!-- Section 2.1.4 --> <a id='S2.1.4'></a>
+
+### Design overview: SNIP Authentication
+
+I'm going to specify a flexible authentication format for SNIPs that
+can handle threshold signatures, multisignatures, and Merkle trees.
+This will give us flexibility in our choice of authentication
+mechanism over time.
+
+  * If we use Merkle trees, we can make ENDIVE diffs much much smaller,
+    and save a bunch of authority CPU -- at the expense of requiring
+    slightly larger SNIPs.
+
+  * If Merkle tree root signatures are in SNIPs, SNIPs get a
+    bit larger, but they can be used by clients that do not have the
+    latest signed Merkle tree root.
+
+  * If we use threshold signatures, we need to depend on
+    not-yet-quite-standardized algorithms.  If we use multisignatures,
+    then either SNIPs get bigger, or we need to put the signed Merkle
+    tree roots into a consensus document.
+
+Of course, flexibility in signature formats is risky, since the more
+code paths there are, the more opportunities there are for nasty bugs.
+With this in mind, I'm structuring our authentication so that there
+should (to the extent possible) be only a single validation path for
+different uses.
+
+With this in mind, our format is structured so that "not using a
+Merkle tree" is considered, from the client's point of view, the same as
+"using a Merkle of depth 1".
+
+The authentication on a single snip is structured, in the abstract, as:
+   - ITEM: The item to be authenticated.
+   - PATH: A string of N bits, representing a path through a Merkle tree from
+     its root, where 0 indicates a left branch and 1 indicates a right
+     branch.  (Note that in a left-leaning tree, the 0th leaf will have
+     path 000..0, the 1st leaf will have path 000..1, and so on.)
+   - BRANCH: A list of N digests, representing the digests for the
+     branches in the Merkle tree that we are _not_ taking.
+   - SIG: A generalized signature (either a threshold signature or a
+     multisignature) of a top-level digest.
+   - NONCE: an optional nonce for use with the hash functions.
+
+Note that PATH here is a bitstring, not an integer! "0001" and "01" are
+different paths, and "" is a valid path, indicating the root of the tree.
+
+We assume two hash functions here: `H_leaf()` to be used with leaf
+items, and `H_node()` to be used with intermediate nodes.  These functions
+are parameterized with a path through the tree, with
+the lifespan of the object to be signed, and with a nonce.
+
+To validate the authentication on a SNIP, the client proceeds as follows:
+
+    Algorithm: Validating SNIP authentication
+
+    Let N = the length of PATH, in bits.
+
+    Let H = H_leaf(PATH, LIFESPAN, NONCE, ITEM).
+
+    While N > 0:
+       Remove the last bit of PATH; call it P.
+       Remove the last digest of BRANCH; call it B.
+
+       If P is zero:
+           Let H = H_node(PATH, LIFESPAN, NONCE, H, B)
+       else:
+           Let H = H_node(PATH, LIFESPAN, NONCE, B, H)
+
+       Let N = N - 1
+
+    Check wither SIG is a correct (multi)signature over H with the
+    correct key(s).
+
+Parameterization on this structure is up to the authorities.  If N is
+zero, then we are not using a Merkle tree.  The generalize signature
+SIG can either be given as part of the SNIP, or as part of a consensus
+document.  I expect that in practice, we will converge on a single set of
+parameters here quickly (I'm favoring BLS signatures and a Merkle
+tree), but using this format will give clients the flexibility to handle
+other variations in the future.
+
+For our definition of `H_leaf()` and `H_node()`, see "Digests and
+parameters" below.
+
+<!-- Section 2.1.5 --> <a id='S2.1.5'></a>
+
+### Design overview: timestamps and validity.
+
+For future-proofing, SNIPs and ENDIVEs have separate time ranges
+indicating when they are valid.  Unlike with current designs, these
+validity ranges should take clock skew into account, and should not
+require clients or relays to deliberately add extra tolerance to their
+processing.  (For example, instead of saying that a document is "fresh"
+for three hours and then telling clients to accept documents for 24
+hours before they are valid and 24 hours after they are expired, we will
+simply make the documents valid for 51 hours.)
+
+We give each lifespan as a (PUBLISHED, PRE, POST) triple, such that
+objects are valid from (PUBLISHED - PRE) through (PUBLISHED + POST).
+(The "PUBLISHED" time is provided so that we can more reliably tell
+which of two objects is more recent.)
+
+Later (see section 08), we'll explain measures to ensure that
+hostile relays do not take advantage of multiple overlapping SNIP
+lifetimes to attack clients.
+
+<!-- Section 2.1.6 --> <a id='S2.1.6'></a>
+
+### Design overview: how the formats work together
+
+Authorities, as part of their current voting process, will produce an
+ENDIVE.
+
+Relays will download this ENDIVE (either directly or as a diff),
+validate it, and extract SNIPs from it.  Extracting these SNIPs may be
+trivial (if they are signed individually), or more complex (if they are
+signed via a Merkle tree, and the Merkle tree needs to be
+reconstructed).  This complexity is acceptable only to the extent that
+it reduces compressed diff size.
+
+Once the SNIPs are reconstructed, relays will hold them and serve them
+to clients.
+
+<!-- Section 2.1.7 --> <a id='S2.1.7'></a>
+
+### What isn't in this section
+
+This section doesn't tell you what the different routing indices
+are or mean.  For now, we can imagine there being one routing index for
+guards, one for middles, and one for exits, and one for each hidden
+service directory ring. (See section 06 for more on regular indices,
+and section 07 for more on onion services.)
+
+This section doesn't give an algorithm for computing ENDIVEs from
+votes, and doesn't give an algorithm for extracting SNIPs from an ENDIVE.
+Those come later. (See sections 03 and 04 respectively.)
+
+<!-- Section 2.2 --> <a id='S2.2'></a>
+
+## SNIPs
+
+Each SNIP has three pieces: the part of the SNIP that describes the
+router, the part of that describes the SNIP's place within an ENDIVE, and
+the part that authenticates the whole SNIP.
+
+Why two _separate_ authenticated pieces?  Because one (the router
+description) is taken verbatim from the ENDIVE, and the other
+(the location within the ENDIVE) is computed from the ENDIVE by the
+relays. Separating them like this helps ensure that the part
+generated by the relay and the part generated by the authorities
+can't interfere with each other.
+
+    ; A SNIP, as it is sent from the relay to the client.  Note that
+    ; this is represented as a three-element array.
+    SNIP = [
+        ; First comes the signature.  This is computed over
+        ; the concatenation of the two bstr objects below.
+        auth: SNIPSignature,
+
+        ; Next comes the location of the SNIP within the ENDIVE.
+        index: bstr .cbor SNIPLocation,
+
+        ; Finally comes the information about the router.
+        router: bstr .cbor SNIPRouterData,
+    ]
+
+(Computing the signature over a concatenation of objects is safe, since
+the objects' content is self-describing CBOR, and isn't vulnerable to
+framing issues.)
+
+<!-- Section 2.2.1 --> <a id='S2.2.1'></a>
+
+### SNIPRouterData: information about a single router.
+
+Here we talk about the type that tells a client about a single
+router.  For cases where we are just storing information about a
+router (for example, when using it as a guard), we can remember
+this part, and discard the other pieces.
+
+The only required parts here are those that identify the router
+and tell the client how to build a circuit through it.  The others
+are all optional.  In practice, I expect they will be encoded in most
+cases, but clients MUST behave properly if they are absent.
+
+More than one SNIPRouterData may exist in the same ENDIVE for a
+single router.  For example, there might be a longer version to
+represent a router to be used as a guard, and another to represent
+the same router when used as a hidden service directory.  (This is
+not possible in the voting mechanism that I'm working on, but relays
+and clients MUST NOT treat this as an error.)
+
+This representation is based on the routerstats and
+microdescriptor entries of today, but tries to omit a number of
+obsolete fields, including RSA identity fingerprint, TAP key,
+published time, etc.
+
+    ; A SNIPRouterData is a map from integer keys to values for
+    ; those keys.
+    SNIPRouterData = {
+        ; identity key.
+        ? 0 => Ed25519PublicKey,
+
+        ; ntor onion key.
+        ? 1 => Curve25519PublicKey,
+
+        ; list of link specifiers other than the identity key.
+        ; If a client wants to extend to the same router later on,
+        ; they SHOULD include all of these link specifiers verbatim,
+        ; whether they recognize them or not.
+        ? 2 => [ LinkSpecifier ],
+
+        ; The software that this relay says it is running.
+        ? 3 => SoftwareDescription,
+
+        ; protovers.
+        ? 4 => ProtoVersions,
+
+        ; Family.  See below for notes on dual encoding.
+        ? 5 => [ * FamilyId ],
+
+        ; Country Code
+        ? 6 => Country,
+
+        ; Exit policies describing supported port _classes_.  Absent exit
+        ; policies are treated as "deny all".
+        ? 7 => ExitPolicy,
+
+        ; NOTE: Properly speaking, there should be a CDDL 'cut'
+        ; here, to indicate that the rules below should only match
+        ; if one if the previous rules hasn't matched.
+        ; Unfortunately, my CDDL tool doesn't seem to support cuts.
+
+        ; For future tor extensions.
+        * int => any,
+
+        ; For unofficial and experimental extensions.
+        * tstr => any,
+    }
+
+    ; For future-proofing, we are allowing multiple ways to encode
+    ; families.  One is as a list of other relays that are in your
+    ; family.  One is as a list of authority-generated family
+    ; identifiers. And one is as a master key for a family (as in
+    ; Tor proposal 242).
+    ;
+    ; A client should consider two routers to be in the same
+    ; family if they have at least one FamilyId in common.
+    ; Authorities will canonicalize these lists.
+    FamilyId = bstr
+
+    ; A country.  These should ordinarily be 2-character strings,
+    ; but I don't want to enforce that.
+    Country = tstr;
+
+    ; SoftwareDescription replaces our old "version".
+    SoftwareDescription = [
+      software: tstr,
+      version: tstr,
+      extra: tstr
+    ]
+
+    ; Protocol versions: after a bit of experimentation, I think
+    ; the most reasonable representation to use is a map from protocol
+    ; ID to a bitmask of the supported versions.
+    ProtoVersions = { ProtoId => ProtoBitmask }
+
+    ; Integer protocols are reserved for future version of Tor. tstr ids
+    ; are reserved for experimental and non-tor extensions.
+    ProtoId = ProtoIdEnum / int / tstr
+
+    ProtoIdEnum = &(
+      Link     : 0,
+      LinkAuth : 1,
+      Relay    : 2,
+      DirCache : 3,
+      HSDir    : 4,
+      HSIntro  : 5,
+      HSRend   : 6,
+      Desc     : 7,
+      MicroDesc: 8,
+      Cons     : 9,
+      Padding  : 10,
+      FlowCtrl : 11,
+    )
+    ; This type is limited to 64 bits, and that's fine.  If we ever
+    ; need a protocol version higher than 63, we should allocate a
+    ; new protoid.
+    ProtoBitmask = uint
+
+    ; An exit policy may exist in up to two variants.  When port classes
+    ; have not changed in a while, only one policy is needed.  If port
+    ; classes have changed recently, however, then SNIPs need to include
+    ; each relay's position according to both the older and the newer policy
+    ; until older network parameter documents become invalid.
+    ExitPolicy = SinglePolicy / [ SinglePolicy, SinglePolicy ]
+
+    ; Each single exit policy is a tagged bit array, whose bits
+    ; correspond to the members of the list of port classes in the
+    ; network parameter document with a corresponding tag.
+    SinglePolicy = [
+         ; Identifies which group of port classes we're talking about
+         tag: unsigned,
+         ; Bit-array of which port classes this relay supports.
+         policy: bstr
+    ]
+
+<!-- Section 2.2.2 --> <a id='S2.2.2'></a>
+
+### SNIPLocation: Locating a SNIP within a routing index.
+
+The SNIPLocation type can encode where a SNIP is located with
+respect to one or more routing indices.  Note that a SNIPLocation
+does not need to be exhaustive: If a given IndexId is not listed for
+a given relay in one SNIP, it might exist in another SNIP. Clients
+should not infer that the absence of an IndexId in one SNIPLocation
+for a relay means that no SNIPLocation with that IndexId exists for
+the relay.
+
+    ; SNIPLocation: we're using a map here because it's natural
+    ; to look up indices in maps.
+    SNIPLocation = {
+        ; The keys of this mapping represent the routing indices in
+        ; which a SNIP appears.  The values represent the index ranges
+        ; that it occupies in those indices.
+        * IndexId => IndexRange / ExtensionIndex,
+    }
+
+    ; We'll define the different index ranges as we go on with
+    ; these specifications.
+    ;
+    ; IndexId values over 65535 are reserved for extensions and
+    ; experimentation.
+    IndexId = uint32
+
+    ; An index range extends from a minimum to a maximum value.
+    ; These ranges are _inclusive_ on both sides.  If 'hi' is less
+    ; than 'lo', then this index "wraps around" the end of the ring.
+    ; A "nil" value indicates an empty range, which would not
+    ; ordinarily be included.
+    IndexRange = [ lo: IndexPos,
+                   hi: IndexPos ] / nil
+
+    ; An ExtensionIndex is reserved for future use; current clients
+    ; will not understand it and current ENDIVEs will not contain it.
+    ExtensionIndex = any
+
+    ; For most routing indices, the ranges are encoded as 4-byte integers.
+    ; But for hsdir rings, they are binary strings.  (Clients and
+    ; relays SHOULD NOT require this.)
+    IndexPos = uint / bstr
+
+A bit more on IndexRanges: Every IndexRange actually describes a set of
+_prefixes_ for possible index positions.  For example, the IndexRange
+`[ h'AB12', h'AB24' ]` includes all the binary strings that start with (hex)
+`AB12`, `AB13`, and so on, up through all strings that start with `AB24`.
+Alternatively, you can think of a `bstr`-based IndexRange *(lo, hi)* as
+covering *lo*`00000...` through *hi*`ff...`.
+
+IndexRanges based on the uint type work the same, except that they always
+specify the first 32 bits of a prefix.
+
+<!-- Section 2.2.3 --> <a id='S2.2.3'></a>
+
+### SNIPSignature: How to prove a SNIP is in the ENDIVE.
+
+Here we describe the types for implementing SNIP signatures, to be
+validated as described in "Design overview: Authentication" above.
+
+    ; Most elements in a SNIPSignature are positional and fixed
+    SNIPSignature = [
+        ; The actual signature or signatures.  If this is a single signature,
+        ; it's probably a threshold signature.  Otherwise, it's probably
+        ; a list containing one signature from each directory authority.
+        SingleSig / MultiSig,
+
+        ; algorithm to use for the path through the merkle tree.
+        d_alg: DigestAlgorithm,
+        ; Path through merkle tree, possibly empty.
+        merkle_path: MerklePath,
+
+        ; Lifespan information.  This is included as part of the input
+        ; to the hash algorithm for the signature.
+        LifespanInfo,
+
+        ; optional nonce for hash algorithm.
+        ? nonce: bstr,
+
+        ; extensions for later use. These are not signed.
+        ? extensions: { * any => any },
+    ]
+
+    ; We use this group to indicate when an object originated, and when
+    ; it should be accepted.
+    ;
+    ; When we are using it as an input to a hash algorithm for computing
+    ; signatures, we encode it as an 8-byte number for "published",
+    ; followed by two 4-byte numbers for pre-valid and post-valid.
+    LifespanInfo = (
+        ; Official publication time in seconds since the epoch.  These
+        ; MUST be monotonically increasing over time for a given set of
+        ; authorities on all SNIPs or ENDIVEs that they generate: a
+        ; document with a greater `published` time is always more recent
+        ; than one with an earlier `published` time.
+        ;
+        ; Seeing a publication time "in the future" on a correctly
+        ; authenticated document is a reliable sign that your
+        ; clock is set too far in the past.
+        published: uint,
+
+        ; Value to subtract from "published" in order to find the first second
+        ; at which this object should be accepted.
+        pre-valid: uint32,
+
+        ; Value to add to "published" in order to find the last
+        ; second at which this object should be accepted.  The
+        ; lifetime of an object is therefore equal to "(post-valid +
+        ; pre-valid)".
+        post-valid: uint32,
+    )
+
+    ; A Lifespan is just the fields of LifespanInfo, encoded as a list.
+    Lifespan = [ LifespanInfo ]
+
+    ; One signature on a SNIP or ENDIVE.  If the signature is a threshold
+    ; signature, or a reference to a signature in another
+    ; document, there will probably be just one of these per SNIP.  But if
+    ; we're sticking a full multisignature in the document, this
+    ; is just one of the signatures on it.
+    SingleSig = [
+       s_alg: SigningAlgorithm,
+       ; One of signature and sig_reference must be present.
+       ?signature: bstr,
+       ; sig_reference is an identifier for a signature that appears
+       ; elsewhere, and can be fetched on request.  It should only be
+       ; used with signature types too large to attach to SNIPs on their
+       ; own.
+       ?sig_reference: bstr,
+       ; A prefix of the key or the key's digest, depending on the
+       ; algorithm.
+       ?keyid: bstr,
+    ]
+
+    MultiSig = [ + SingleSig ]
+
+    ; A Merkle path is represented as a sequence of bits to
+    ; indicate whether we're going left or right, and a list of
+    ; hashes for the parts of the tree that we aren't including.
+    ;
+    ; (It's safe to use a uint for the number of bits, since it will
+    ; never overflow 64 bits -- that would mean a Merkle tree with
+    ; too many leaves to actually calculate on.)
+    MerklePath = [ uint, *bstr ]
+
+<!-- Section 2.3 --> <a id='S2.3'></a>
+
+## ENDIVEs: sending a bunch of SNIPs efficiently.
+
+ENDIVEs are delivered by the authorities in a compressed format, optimized
+for diffs.
+
+Note that if we are using Merkle trees for SNIP authentication, ENDIVEs do
+not include the trees at all, since those can be inferred from the leaves of
+the tree.  Similarly, the ENDIVEs do not include raw routing indices, but
+instead include a set of bandwidths that can be combined into the routing
+indices -- these bandwidths change less frequently, and therefore are more
+diff-friendly.
+
+Note also that this format has more "wasted bytes" than SNIPs
+do. Unlike SNIPs, ENDIVEs are large enough to benefit from
+compression with with gzip, lzma2, or so on.
+
+This section does not fully specify how to construct SNIPs from an ENDIVE;
+for the full algorithm, see section 04.
+
+    ; ENDIVEs are also sent as CBOR.
+    ENDIVE = [
+        ; Signature for the ENDIVE, using a simpler format than for 
+        ; a SNIP.  Since ENDIVEs are more like a consensus, we don't need
+        ; to use threshold signatures or Merkle paths here.
+        sig: ENDIVESignature,
+
+        ; Contents, as a binary string.
+        body: encoded-cbor .cbor ENDIVEContent,
+    ]
+
+    ; The set of signatures across an ENDIVE.
+    ;
+    ; This type doubles as the "detached signature" document used when
+    ; collecting signatures for a consensus.
+    ENDIVESignature = {
+        ; The actual signatures on the endive. A multisignature is the
+        ; likeliest format here.
+        endive_sig: [ + SingleSig ],
+
+        ; Lifespan information.  As with SNIPs, this is included as part
+        ; of the input to the hash algorithm for the signature.
+        ; Note that the lifespan of an ENDIVE is likely to be a subset
+        ; of the lifespan of its SNIPs.
+        endive_lifespan: Lifespan,
+
+        ; Signatures across SNIPs, at some level of the Merkle tree.  Note
+        ; that these signatures are not themselves signed -- having them
+        ; signed would take another step in the voting algorithm.
+        snip_sigs: DetachedSNIPSignatures,
+
+        ; Signatures across the ParamDoc pieces.  Note that as with the
+        ; DetachedSNIPSignatures, these signatures are not themselves signed.
+        param_doc: ParamDocSignature,
+
+        ; extensions for later use. These are not signed.
+        * tstr => any,
+    }
+
+    ; A list of single signatures or a list of multisignatures. This
+    ; list must have 2^signature-depth elements.
+    DetachedSNIPSignatures =
+          [ *SingleSig ] / [ *MultiSig ]
+
+    ENDIVEContent = {
+
+        ; Describes how to interpret the signatures over the SNIPs in this
+        ; ENDIVE. See section 04 for the full algorithm.
+        sig_params: {
+            ; When should we say that the signatures are valid?
+            lifespan: Lifespan,
+            ; Nonce to be used with the signing algorithm for the signatures.
+            ? signature-nonce: bstr,
+
+            ; At what depth of a Merkle tree do the signatures apply?
+            ; (If this value is 0, then only the root of the tree is signed.
+            ; If this value is >= ceil(log2(n_leaves)), then every leaf is
+            ; signed.).
+            signature-depth: uint,
+
+            ; What digest algorithm is used for calculating the signatures?
+            signature-digest-alg: DigestAlgorithm,
+
+            ; reserved for future extensions.
+            * tstr => any,
+        },
+
+        ; Documents for clients/relays to learn about current network
+        ; parameters.
+        client-param-doc: encoded-cbor .cbor ClientParamDoc,
+        relay-param-doc: encoded-cbor .cbor RelayParamDoc,
+
+        ; Definitions for index group.  Each "index group" is all
+        ; applied to the same SNIPs.  (If there is one index group,
+        ; then every relay is in at most one SNIP, and likely has several
+        ; indices.  If there are multiple index groups, then relays
+        ; can appear in more than one SNIP.)
+        indexgroups: [ *IndexGroup ],
+
+        ; Information on particular relays.
+        ;
+        ; (The total number of SNIPs identified by an ENDIVE is at most
+        ; len(indexgroups) * len(relays).)
+        relays: [ * ENDIVERouterData ],
+
+        ; for future exensions
+        * tstr => any,
+    }
+
+    ; An "index group" lists a bunch of routing indices that apply to the same
+    ; SNIPs.  There may be multiple index groups when a relay needs to appear
+    ; in different SNIPs with routing indices for some reason.
+    IndexGroup = {
+        ; A list of all the indices that are built for this index group.
+        ; An IndexId may appear in at most one group per ENDIVE.
+        indices: [ + IndexId ],
+        ; A list of keys to delete from SNIPs to build this index group.
+        omit_from_snips: [ *(int/tstr) ],
+        ; A list of keys to forward from SNIPs to the next relay in an EXTEND
+        ; cell.  This can help the next relay know which keys to use in its
+        ; handshake.
+        forward_with_extend: [ *(int/tstr) ],
+
+        ; A number of "gaps" to place in the Merkle tree after the SNIPs
+        ; in this group.  This can be used together with signature-depth
+        ; to give different index-groups independent signatures.
+        ? n_padding_entries: uint,
+
+        ; A detailed description of how to build the index.
+        + IndexId => IndexSpec,
+
+        ; For experimental and extension use.
+        * tstr => any,
+    }
+
+    ; Enumeration to identify how to generate an index.
+    Indextype_Raw = 0
+    Indextype_Weighted = 1
+    Indextype_RSAId = 2
+    Indextype_Ed25519Id = 3
+    Indextype_RawNumeric = 4
+
+    ; An indexspec may be given as a raw set of index ranges.  This is a
+    ; fallback for cases where we simply can't construct an index any other
+    ; way.
+    IndexSpec_Raw = {
+        type: Indextype_Raw,
+        ; This index is constructed by taking relays by their position in the
+        ; list from the list of ENDIVERouterData, and placing them at a given
+        ; location in the routing index.  Each index range extends up to
+        ; right before the next index position.
+        index_ranges: [ * [ uint, IndexPos ] ],
+    }
+
+    ; An indexspec given as a list of numeric spans on the index.
+    IndexSpec_RawNumeric = {
+        type: Indextype_RawNumeric,
+        first_index_pos: uint,
+        ; This index is constructed by taking relays by index from the list
+        ; of ENDIVERouterData, and giving them a certain amount of "weight"
+        ; in the index.
+        index_ranges: [ * [ idx: uint, span: uint ] ],
+    }
+
+    ; This index is computed from the weighted bandwidths of all the SNIPs.
+    ;
+    ; Note that when a single bandwidth changes, it can change _all_ of
+    ; the indices in a bandwidth-weighted index, even if no other
+    ; bandwidth changes.  That's why we only pack the bandwidths
+    ; here, and scale them as part of the reconstruction algorithm.
+    IndexSpec_Weighted = {
+        type: Indextype_Weighted,
+        ; This index is constructed by assigning a weight to each relay,
+        ; and then normalizing those weights. See algorithm below in section
+        ; 04.
+        ; Limiting bandwidth weights to uint32 makes reconstruction algorithms
+        ; much easier.
+        index_weights: [ * uint32 ],
+    }
+
+    ; This index is computed from the RSA identity key digests of all of the
+    ; SNIPs. It is used in the HSv2 directory ring.
+    IndexSpec_RSAId = {
+        type: Indextype_RSAId,
+        ; How many bytes of RSA identity data go into each indexpos entry?
+        n_bytes: uint,
+        ; Bitmap of which routers should be included.
+        members: bstr,
+    }
+
+    ; This index is computed from the Ed25519 identity keys of all of the
+    ; SNIPs.  It is used in the HSv3 directory ring.
+    IndexSpec_Ed25519Id = {
+        type: Indextype_Ed25519Id,
+        ; How many bytes of digest go into each indexpos entry?
+        n_bytes: uint,
+        ; What digest do we use for building this ring?
+        d_alg: DigestAlgorithm,
+        ; What bytes do we give to the hash before the ed25519?
+        prefix: bstr,
+        ; What bytes do we give to the hash after the ed25519?
+        suffix: bstr,
+        ; Bitmap of which routers should be included.
+        members: bstr,
+    }
+
+    IndexSpec = IndexSpec_Raw /
+                IndexSpec_RawNumeric /
+                IndexSpec_Weighted /
+                IndexSpec_RSAId /
+                IndexSpec_Ed25519Id
+
+    ; Information about a single router in an ENDIVE.
+    ENDIVERouterData = {
+        ; The authority-generated SNIPRouterData for this router.
+        1 => encoded-cbor .cbor SNIPRouterData,
+        ; The RSA identity, or a prefix of it, to use for HSv2 indices.
+        ? 2 => RSAIdentityFingerprint,
+
+        * int => any,
+        * tstr => any,
+    }
+
+    ; encoded-cbor is defined in the CDDL postlude as a bstr that is
+    ; tagged as holding verbatim CBOR:
+    ;
+    ;    encoded-cbor = #6.24(bstr)
+    ;
+    ; Using a tag like this helps tools that validate the string as
+    ; valid CBOR; using a bstr helps indicate that the signed data
+    ; should not be interpreted until after the signature is checked.
+    ; It also helps diff tools know that they should look inside these
+    ; objects.
+
+<!-- Section 2.4 --> <a id='S2.4'></a>
+
+## Network parameter documents
+
+Network parameter documents ("ParamDocs" for short) take the place of the
+current consensus and certificates as a small document that clients and
+relays need to download periodically and keep up-to-date.  They are generated
+as part of the voting process, and contain fields like network parameters,
+recommended versions, authority certificates, and so on.
+
+    ; A "parameter document" is like a tiny consensus that relays and clients
+    ; can use to get network parameters.
+    ParamDoc = [
+       sig: ParamDocSignature,
+       ; Client-relevant portion of the parameter document. Everybody fetches
+       ; this.
+       cbody: encoded-cbor .cbor ClientParamDoc,
+       ; Relay-relevant portion of the parameter document. Only relays need to
+       ; fetch this; the document can be validated without it.
+       ? sbody: encoded-cbor .cbor RelayParamDoc,
+    ]
+    ParamDocSignature = [
+       ; Multisignature or threshold signature of the concatenation
+       ; of the two digests below.
+       SingleSig / MultiSig,
+
+       ; Lifespan information.  As with SNIPs, this is included as part
+       ; of the input to the hash algorithm for the signature.
+       ; Note that the lifespan of a parameter document is likely to be
+       ; very long.
+       LifespanInfo,
+
+       ; how are c_digest and s_digest computed?
+       d_alg: DigestAlgorithm,
+       ; Digest over the cbody field
+       c_digest: bstr,
+       ; Digest over the sbody field
+       s_digest: bstr,
+    ]
+
+    ClientParamDoc = {
+       params: NetParams,
+       ; List of certificates for all the voters.  These
+       ; authenticate the keys used to sign SNIPs and ENDIVEs and votes,
+       ; using the authorities' longest-term identity keys.
+       voters: [ + bstr .cbor VoterCert ],
+
+       ; A division of exit ports into "classes" of ports.
+       port-classes: PortClasses,
+
+       ; As in client-versions from dir-spec.txt
+       ? recommend-versions: [ * tstr ],
+       ; As in recommended-client-protocols in dir-spec.txt
+       ? recommend-protos: ProtoVersions,
+       ; As in required-client-protocols in dir-spec.txt
+       ? require-protos: ProtoVersions,
+
+       ; For future extensions.
+       * tstr => any,
+    }
+
+    RelayParamDoc = {
+       params: NetParams,
+
+       ; As in server-versions from dir-spec.txt
+       ? recommend-versions: [ * tstr ],
+       ; As in recommended-relay-protocols in dir-spec.txt
+       ? recommend-protos: ProtoVersions,
+       ; As in required-relay-protocols in dir-spec.txt
+       ? require-versions: ProtoVersions,
+
+       * tstr => any,
+    }
+
+    ; A NetParams encodes information about the Tor network that
+    ; clients and relays need in order to participate in it.  The
+    ; current list of parameters is described in the "params" field
+    ; as specified in dir-spec.txt.
+    ;
+    ; Note that there are separate client and relay NetParams now.
+    ; Relays are expected to first check for a defintion in the
+    ; RelayParamDoc, and then in the ClientParamDoc.
+    NetParams = { *tstr => int }
+
+    PortClasses = {
+        ; identifies which port class grouping this is. Used to migrate
+        ; from one group of port classes to another.
+        tag: uint,
+        ; list of the port classes.
+        classes: { * IndexId => PortList },
+    }
+    PortList = [ *PortOrRange ]
+     ; Either a single port or a low-high pair
+    PortOrRange = Port / [ Port, Port ]
+    Port = 1...65535
+
+<!-- Section 2.5 --> <a id='S2.5'></a>
+
+## Certificates
+
+Voting certificates are used to bind authorities' long-term
+identities to shorter-term signing keys.  These have a similar
+purpose to the authority certs made for the existing voting
+algorithm, but support more key types.
+
+    ; A 'voter certificate' is a statement by an authority binding keys to
+    ; each other.
+    VoterCert = [
+
+       ; One or more signatures over `content` using the provided lifetime.
+       ; Each signature should be treated independently.
+       [ + SingleSig ],
+       ; A lifetime value, used (as usual ) as an input to the
+       ; signature algorithm.
+       LifespanInfo,
+       ; The keys and other data to be certified.
+       content: encoded-cbor .cbor CertContent,
+    ]
+
+    ; The contents of the certificate that get signed.
+    CertContent = {
+       ; What kind of a certificate is this?
+       type: CertType,
+       ; A list of keys that are being certified in this document
+       keys: [ + CertifiedKey ],
+       ; A list of other keys that you might need to know about, which
+       ; are NOT certififed in this document.
+       ? extra: [ + CertifiedKey ],
+       * tstr => any,
+    }
+
+    CertifiedKey = {
+       ; What is the intended usage of this key?
+       usage: KeyUsage,
+       ; What cryptographic algorithm is this key used for?
+       alg: PKAlgorithm,
+       ; The actual key being certified.
+       data: bstr,
+       ; A human readable string.
+       ? remarks: tstr,
+       * tstr => any,
+    }
+
+<!-- Section 2.6 --> <a id='S2.6'></a>
+
+## ENDIVE diffs
+
+Here is a binary format to be used with ENDIVEs, ParamDocs, and any
+other similar binary formats.  Authorities and directory caches need to
+be able to generate it; clients and non-cache relays only need to be
+able to parse and apply it.
+
+    ; Binary diff specification.
+    BinaryDiff = {
+        ; This is version 1.
+        v: 1,
+        ; Optionally, a diff can say what different digests
+        ; of the document should be before and after it is applied.
+        ; If there is more than one entry, parties MAY check one or
+        ; all of them.
+        ? digest: { * DigestAlgorithm =>
+                         [ pre: Digest,
+                           post: Digest ]},
+
+        ; Optionally, a diff can give some information to identify
+        ; which document it applies to, and what document you get
+        ; from applying it.  These might be a tuple of a document type
+        ; and a publication type.
+        ? ident: [ pre: any, post: any ],
+
+        ; list of commands to apply in order to the original document in
+        ; order to get the transformed document
+        cmds: [ *DiffCommand ],
+
+        ; for future extension.
+        * tstr => any,
+    }
+
+    ; There are currently only two diff commands.
+    ; One is to copy some bytes from the original.
+    CopyDiffCommand = [
+        OrigBytesCmdId,
+        ; Range of bytes to copy from the original document.
+        ; Ranges include their starting byte.  The "offset" is relative to
+        ; the end of the _last_ range that was copied.
+        offset: int,
+        length: uint,
+    ]
+
+    ; The other diff comment is to insert some bytes from the diff.
+    InsertDiffCommand = [
+        InsertBytesCmdId,
+        data: bstr,
+    ]
+
+    DiffCommand = CopyDiffCommand / InsertDiffCommand
+
+    OrigBytesCmdId = 0
+    InsertBytesCmdId = 1
+
+Applying a binary diff is simple:
+
+    Algorithm: applying a binary diff.
+
+    (Given an input bytestring INP and a diff D, produces an output OUT.)
+
+    Initialize OUT to an empty bytestring.
+
+    Set OFFSET to 0.
+
+    For each command C in D.commands, in order:
+
+        If C begins with OrigBytesCmdId:
+            Increase "OFFSET" by C.offset
+            If OFFSET..OFFSET+C.length is not a valid range in
+               INP, abort.
+            Append INP[OFFSET .. OFFSET+C.length] to OUT.
+            Increase "OFFSET" by C.length
+
+        else: # C begins with InsertBytesCmdId:
+            Append C.data to OUT.
+
+Generating a binary diff can be trickier, and is not specified here.
+There are several generic algorithms out there for making binary diffs
+between arbitrary byte sequences. Since these are complex, I recommend a
+chunk-based CBOR-aware algorithm, using each CBOR item in a similar way
+to the way in which our current line-oriented code uses lines.  When
+encountering a bstr tagged with "encoded-cbor", the diff algorithm
+should look inside it to find more cbor chunks. (See
+example-code/cbor_diff.py for an example of doing this with Python's
+difflib.)
+
+The diff format above should work equally well no matter what
+diff algorithm is used, so we have room to move to other algorithms
+in the future if needed.
+
+To indicate support for the above diff format in directory requests,
+implementations should use an `X-Support-Diff-Formats` header.  The
+above format is designated "cbor-bindiff"; our existing format is
+called "ed".
+
+<!-- Section 2.7 --> <a id='S2.7'></a>
+
+## Digests and parameters
+
+Here we give definitions for `H_leaf()` and `H_node()`, based on an
+underlying digest function H() with a preferred input block size of B.
+(B should be chosen as the natural input size of the hash function, to
+aid in precomputation.)
+
+We also define `H_sign()`, to be used outside of SNIP authentication
+where we aren't using a Merkle tree at all.
+
+PATH must be no more than 64 bits long.  NONCE must be no more than B-33
+bytes long.
+
+     H_sign(LIFESPAN, NONCE, ITEM) =
+        H( PREFIX(OTHER_C, LIFESPAN, NONCE) || ITEM)
+
+     H_leaf(PATH, LIFESPAN, NONCE, ITEM) =
+        H( PREFIX(LEAF_C, LIFESPAN, NONCE) ||
+           U64(PATH) ||
+           U64(bits(path)) ||
+           ITEM )
+
+     H_node(PATH, LIFESPAN, NONCE, ITEM) =
+        H( PREFIX(NODE_C, LIFESPAN, NONCE) ||
+           U64(PATH) ||
+           U64(bits(PATH)) ||
+           ITEM )
+
+     PREFIX(leafcode, lifespan, nonce) =
+          U64(leafcode) ||
+          U64(lifespan.published) ||
+          U32(lifespan.pre-valid) ||
+          U32(lifespan.post-valid) ||
+          U8(len(nonce)) ||
+          nonce ||
+          Z(B - 33 - len(nonce))
+
+     LEAF_C = 0x8BFF0F687F4DC6A1 ^ NETCONST
+     NODE_C = 0xA6F7933D3E6B60DB ^ NETCONST
+     OTHER_C = 0x7365706172617465 ^ NETCONST
+
+     # For the live Tor network only.
+     NETCONST = 0x0746f72202020202
+     # For testing networks, by default.
+     NETCONST = 0x74657374696e6720
+
+     U64(n) -- N encoded as a big-endian 64-bit number.
+     Z(n) -- N bytes with value zero.
+     len(b) -- the number of bytes in a byte-string b.
+     bits(b) -- the number of bits in a bit-string b.
+
+
+<!-- Section 3 --> <a id='S3'></a>
+
+# Directory authority operations
+
+For Walking Onions to work, authorities must begin to generate
+ENDIVEs as a new kind of "consensus document".  Since this format is
+incompatible with the previous consensus document formats, and is
+CBOR-based, a text-based voting protocol is no longer appropriate
+for generating it.
+
+We cannot immediately abandon the text-based consensus and
+microdescriptor formats, but instead will need to keep
+generating them for legacy relays and clients.  Ideally, process
+that produces the ENDIVE should also produce a legacy consensus,
+to limit the amount of divergence in their contents.
+
+Further, it would be good for the purposes of this proposal if we
+can "inherit" as much as possible of our existing voting mechanism
+for legacy purposes.
+
+This section of the proposal will try to solve these goals by defining a
+new binary-based voting format, a new set of voting rules for it, and a
+series of migration steps.
+
+<!-- Section 3.1 --> <a id='S3.1'></a>
+
+## Overview
+
+Except as described below, we retain from Tor's existing voting
+mechanism all notions of how votes are transferred and processed.
+Other changes are likely desirable, but they are out of scope for
+this proposal.
+
+Notably, we are not changing how the voting schedule works.  Nor are
+we changing the property that all authorities must agree on the list
+of authorities; the property that a consensus is computed as a
+deterministic function of a set of votes; or the property that if
+authorities believe in different sets of votes, they will not reach
+the same consensus.
+
+The principal changes in the voting that are relevant for legacy
+consensus computation are:
+
+  * The uploading process for votes now supports negotiation, so
+    that the receiving authority can tell the uploading authority
+    what kind of formats, diffs, and compression it supports.
+
+  * We specify a CBOR-based binary format for votes, with a simple
+    embedding method for the legacy text format.  This embedding is
+    meant for transitional use only; once all authorities support
+    the binary format, the transitional format and its support
+    structures can be abandoned.
+
+  * To reduce complexity, the new vote format also includes
+    _verbatim_ microdescriptors, whereas previously microdescriptors
+    would have been referenced by hash.  (The use of diffs and
+    compression should make the bandwidth impact of this addition
+    negligible.)
+
+For computing ENDIVEs, the principal changes in voting are:
+
+  * The consensus outputs for most voteable objects are specified in a
+    way that does not require the authorities to understand their
+    semantics when computing a consensus.  This should make it
+    easier to change fields without requiring new consensus methods.
+
+<!-- Section 3.2 --> <a id='S3.2'></a>
+
+## Negotiating vote uploads
+
+Authorities supporting Walking Onions are required to support a new
+resource "/tor/auth-vote-opts".  This resource is a text document
+containing a list of HTTP-style headers. Recognized headers are
+described below; unrecognized headers MUST be ignored.
+
+The *Accept-Encoding* header follows the same format as the HTTP
+header of the same name; it indicates a list of Content-Encodings
+that the authority will accept for uploads.  All authorities SHOULD
+support the gzip and identity encodings.  The identity encoding is
+mandatory.  (Default: "identity")
+
+The *Accept-Vote-Diffs-From* header is a list of digests of previous
+votes held by this authority; any new uploaded votes that are given
+as diffs from one of these old votes SHOULD be accepted.  The format
+is a space-separated list of "digestname:Hexdigest".  (Default: "".)
+
+The *Accept-Vote-Formats* header is a space-separated list of the
+vote formats that this router accepts. The recognized vote formats
+are "legacy-3" (Tor's current vote format) and "endive-1" (the vote
+format described here). Unrecognized vote formats MUST be ignored.
+(Default: "legacy-3".)
+
+If requesting "/tor/auth-vote-opts" gives an error, or if one or
+more headers are missing, the default values SHOULD be used.  These
+documents (or their absence) MAY be cached for up to 2 voting
+periods.)
+
+Authorities supporting Walking Onions SHOULD also support the
+"Connection: keep-alive" and "Keep-Alive" HTTP headers, to avoid
+needless reconnections in response to these requests.
+Implementors SHOULD be aware of potential denial-of-service
+attacks based on open HTTP connections, and mitigate them as
+appropriate.
+
+> Note: I thought about using OPTIONS here, but OPTIONS isn't quite
+> right for this, since Accept-Vote-Diffs-From does not fit with its
+> semantics.
+
+> Note: It might be desirable to support this negotiation for legacy
+> votes as well, even before walking onions is implemented.  Doing so
+> would allow us to reduce authority bandwidth a little, and possibly
+> include microdescriptors in votes for more convenient processing.
+
+<!-- Section 3.3 --> <a id='S3.3'></a>
+
+## A generalized algorithm for voting
+
+Unlike with previous versions of our voting specification, here I'm
+going to try to describe pieces the voting algorithm in terms of
+simpler voting operations.  Each voting operation will be named and
+possibly parameterized, and data will frequently self-describe what
+voting operation is to be used on it.
+
+Voting operations may operate over different CBOR types, and are
+themselves specified as CBOR objects.
+
+A voting operation takes place over a given "voteable field".  Each
+authority that specifies a value for a voteable field MUST specify
+which voting operation to use for that field.  Specifying a voteable
+field without a voting operation MUST be taken as specifying the
+voting operation "None" -- that is, voting against a consensus.
+
+On the other hand, an authority MAY specify a voting operation for
+a field without casting any vote for it.  This means that the
+authority has an opinion on how to reach a consensus about the
+field, without having any preferred value for the field itself.
+
+<!-- Section 3.3.1 --> <a id='S3.3.1'></a>
+
+### Constants used with voting operations
+
+Many voting operations may be parameterized by an unsigned integer.
+In some cases the integers are constant, but in others, they depend
+on the number of authorities, the number of votes cast, or the
+number of votes cast for a particular field.
+
+When we encode these values, we encode them as short strings
+rather than as integers.
+
+> I had thought of using negative integers here to encode these
+> special constants, but that seems too error-prone.
+
+The following constants are defined:
+
+`N_AUTH` -- the total number of authorities, including those whose
+votes are absent.
+
+`N_PRESENT` -- the total number of authorities whose votes are
+present for this vote.
+
+`N_FIELD` -- the total number of authorities whose votes for a given
+field are present.
+
+Necessarily, `N_FIELD` <= `N_PRESENT` <= `N_AUTH` -- you can't vote
+on a field unless you've cast a vote, and you can't cast a vote
+unless you're an authority.
+
+In the definitions below, `//` denotes the truncating integer division
+operation, as implemented with `/` in C.
+
+`QUORUM_AUTH` -- The lowest integer that is greater than half of
+`N_AUTH`.  Equivalent to `N_AUTH // 2 + 1`.
+
+`QUORUM_PRESENT` -- The lowest integer that is greater than half of
+`N_PRESENT`.  Equivalent to `N_PRESENT // 2 + 1`.
+
+`QUORUM_FIELD` -- The lowest integer that is greater than half of
+`N_FIELD`.  Equivalent to `N_FIELD // 2 + 1`.
+
+We define `SUPERQUORUM_`..., variants of these fields as well, based
+on the lowest integer that is greater than 2/3 majority of the
+underlying field.  `SUPERQUORUM_x` is thus equivalent to
+`(N_x * 2) // 3 + 1`.
+
+    ; We need to encode these arguments; we do so as short strings.
+    IntOpArgument = uint / "auth" / "present" / "field" /
+         "qauth" / "qpresent" / "qfield" /
+         "sqauth" / "sqpresent" / "sqfield"
+
+No IntOpArgument may be greater than AUTH.  If an IntOpArgument is
+given as an integer, and that integer is greater than AUTH, then it
+is treated as if it were AUTH.
+
+> This rule lets us say things like "at least 3 authorities must
+> vote on x...if there are 3 authorities."
+
+<!-- Section 3.3.2 --> <a id='S3.3.2'></a>
+
+### Producing consensus on a field
+
+Each voting operation will either produce a CBOR output, or produce
+no consensus.  Unless otherwise stated, all CBOR outputs are to be
+given in canonical form.
+
+Below we specify a number of operations, and the parameters that
+they take.  We begin with operations that apply to "simple" values
+(integers and binary strings), then show how to compose them to
+larger values.
+
+All of the descriptions below show how to apply a _single_ voting
+operation to a set of votes.  We will later describe how to behave when
+the authorities do not agree on which voting operation to use, in our
+discussion of the StructJoinOp operation.
+
+Note that while some voting operations take other operations as
+parameters, we are _not_ supporting full recursion here: there is a
+strict hierarchy of operations, and more complex operations can only
+have simpler operations in their parameters.
+
+All voting operations follow this metaformat:
+
+    ; All a generic voting operation has to do is say what kind it is.
+    GenericVotingOp = {
+        op: tstr,
+        * tstr => any,
+    }
+
+Note that some voting operations require a sort or comparison
+operation over CBOR values.  This operation is defined later in
+appendix E; it works only on homogeneous inputs.
+
+<!-- Section 3.3.3 --> <a id='S3.3.3'></a>
+
+### Generic voting operations
+
+<!-- Section 3.3.3.1 --> <a id='S3.3.3.1'></a>
+
+#### None
+
+This voting operation takes no parameters, and always produces "no
+consensus".  It is encoded as:
+
+    ; "Don't produce a consensus".
+    NoneOp = { op: "None" }
+
+When encountering an unrecognized or nonconforming voting operation,
+_or one which is not recognized by the consensus-method in use_, the
+authorities proceed as if the operation had been "None".
+
+<!-- Section 3.3.4 --> <a id='S3.3.4'></a>
+
+### Voting operations for simple values
+
+We define a "simple value" according to these cddl rules:
+
+    ; Simple values are primitive types, and tuples of primitive types.
+    SimpleVal = BasicVal / SimpleTupleVal
+    BasicVal = bool / int / bstr / tstr
+    SimpleTupleVal = [ *BasicVal ]
+
+We also need the ability to encode the types for these values:
+
+    ; Encoding a simple type.
+    SimpleType = BasicType / SimpleTupleType
+    BasicType = "bool" /  "uint" / "sint" / "bstr" / "tstr"
+    SimpleTupleType = [ "tuple", *BasicType ]
+
+In other words, a SimpleVal is either an non-compound base value, or is
+a tuple of such values.
+
+    ; We encode these operations as:
+    SimpleOp = MedianOp / ModeOp / ThresholdOp /
+        BitThresholdOp / CborSimpleOp / NoneOp
+
+We define each of these operations in the sections below.
+
+<!-- Section 3.3.4.1 --> <a id='S3.3.4.1'></a>
+
+#### Median
+
+_Parameters_: `MIN_VOTES` (an integer), `BREAK_EVEN_LOW` (a boolean),
+`TYPE` (a SimpleType)
+
+    ; Encoding:
+    MedianOp = { op: "Median",
+                 ? min_vote: IntOpArgument,  ; Default is 1.
+                 ? even_low: bool,           ; Default is true.
+                 type: SimpleType  }
+
+Discard all votes that are not of the specified `TYPE`. If there are
+fewer than `MIN_VOTES` votes remaining, return "no consensus".
+
+Put the votes in ascending sorted order. If the number of votes N
+is odd, take the center vote (the one at position (N+1)/2).  If N is
+even, take the lower of the two center votes (the one at position
+N/2) if `BREAK_EVEN_LOW` is true. Otherwise, take the higher of the
+two center votes (the one at position N/2 + 1).
+
+For example, the Median(…, even_low: True, type: "uint") of the votes
+["String", 2, 111, 6] is 6. The Median(…, even_low: True, type: "uint")
+of the votes ["String", 77, 9, 22, "String", 3] is 9.
+
+<!-- Section 3.3.4.2 --> <a id='S3.3.4.2'></a>
+
+#### Mode
+
+_Parameters_: `MIN_COUNT` (an integer), `BREAK_TIES_LOW` (a boolean),
+`TYPE` (a SimpleType)
+
+    ; Encoding:
+    ModeOp = { op: "Mode",
+               ? min_count: IntOpArgument,   ; Default 1.
+               ? tie_low: bool,              ; Default true.
+               type: SimpleType
+    }
+
+Discard all votes that are not of the specified `TYPE`.  Of the
+remaining votes, look for the value that has received the most
+votes.  If no value has received at least `MIN_COUNT` votes, then
+return "no consensus".
+
+If there is a single value that has received the most votes, return
+it. Break ties in favor of lower values if `BREAK_TIES_LOW` is true,
+and in favor of higher values if `BREAK_TIES_LOW` is false.
+(Perform comparisons in canonical cbor order.)
+
+<!-- Section 3.3.4.3 --> <a id='S3.3.4.3'></a>
+
+#### Threshold
+
+_Parameters_: `MIN_COUNT` (an integer), `BREAK_MULTI_LOW` (a boolean),
+`TYPE` (a SimpleType)
+
+    ; Encoding
+    ThresholdOp = { op: "Threshold",
+                    min_count: IntOpArgument,  ; No default.
+                    ? multi_low: bool,          ; Default true.
+                    type: SimpleType
+    }
+
+Discard all votes that are not of the specified `TYPE`.  Sort in
+canonical cbor order.  If `BREAK_MULTI_LOW` is false, reverse the
+order of the list.
+
+Return the first element that received at least `MIN_COUNT` votes.
+If no value has received at least `MIN_COUNT` votes, then return
+"no consensus".
+
+<!-- Section 3.3.4.4 --> <a id='S3.3.4.4'></a>
+
+#### BitThreshold
+
+Parameters: `MIN_COUNT` (an integer >= 1)
+
+    ; Encoding
+    BitThresholdOp = { op: "BitThreshold",
+                       min_count: IntOpArgument, ; No default.
+    }
+
+These are usually not needed, but are quite useful for
+building some ProtoVer operations.
+
+Discard all votes that are not of type uint or bstr; construe bstr
+inputs as having type "biguint".
+
+The output is a uint or biguint in which the b'th bit is set iff the
+b'th bit is set in at least `MIN_COUNT` of the votes.
+
+<!-- Section 3.3.5 --> <a id='S3.3.5'></a>
+
+### Voting operations for lists
+
+These operations work on lists of SimpleVal:
+
+    ; List type definitions
+    ListVal = [ * SimpleVal ]
+
+    ListType = [ "list",
+                 [ *SimpleType ] / nil ]
+
+They are encoded as:
+
+    ; Only one list operation exists right now.
+    ListOp = SetJoinOp
+
+<!-- Section 3.3.5.1 --> <a id='S3.3.5.1'></a>
+
+#### SetJoin
+
+Parameters: `MIN_COUNT` (an integer >= 1).
+Optional parameters: `TYPE` (a SimpleType.)
+
+    ; Encoding:
+    SetJoinOp = {
+       op: "SetJoin",
+       min_count: IntOpArgument,
+       ? type: SimpleType
+    }
+
+Discard all votes that are not lists.  From each vote,
+discard all members that are not of type 'TYPE'.
+
+For the consensus, construct a new list containing exactly those
+elements that appears in at least `MIN_COUNT` votes.
+
+(Note that the input votes may contain duplicate elements.  These
+must be treated as if there were no duplicates: the vote
+[1, 1, 1, 1] is the same as the vote [1]. Implementations may want
+to preprocess votes by discarding all but one instance of each
+member.)
+
+<!-- Section 3.3.6 --> <a id='S3.3.6'></a>
+
+### Voting operations for maps
+
+Map voting operations work over maps from key types to other non-map
+types.
+
+    ; Map type definitions.
+    MapVal = { * SimpleVal => ItemVal }
+    ItemVal = ListVal / SimpleVal
+
+    MapType = [ "map", [ *SimpleType ] / nil, [ *ItemType ] / nil ]
+    ItemType = ListType / SimpleType
+
+They are encoded as:
+
+    ; MapOp encodings
+    MapOp = MapJoinOp / StructJoinOp
+
+<!-- Section 3.3.6.1 --> <a id='S3.3.6.1'></a>
+
+#### MapJoin
+
+The MapJoin operation combines homogeneous maps (that is, maps from
+a single key type to a single value type.)
+
+Parameters:
+   `KEY_MIN_COUNT` (an integer >= 1)
+   `KEY_TYPE` (a SimpleType type)
+   `ITEM_OP` (A non-MapJoin voting operation)
+
+Encoding:
+
+    ; MapJoin operation encoding
+    MapJoinOp = {
+       op: "MapJoin"
+       ? key_min_count: IntOpArgument, ; Default 1.
+       key_type: SimpleType,
+       item_op: ListOp / SimpleOp
+    }
+
+First, discard all votes that are not maps.  Then consider the set
+of keys from each vote as if they were a list, and apply
+`SetJoin[KEY_MIN_COUNT,KEY_TYPE]` to those lists.  The resulting list
+is a set of keys to consider including in the output map.
+
+> We have a separate `key_min_count` field, even if `item_op` has
+> its own `min_count` field, because some min_count values (like
+> `qfield`) depend on the overall number of votes for the field.
+> Having `key_min_count` lets us specify rules like "the FOO of all
+> votes on this field, if there are at least 2 such votes."
+
+For each key in the output list, run the sub-voting operation
+`ItemOperation` on the values it received in the votes.  Discard all
+keys for which the outcome was "no consensus".
+
+The final vote result is a map from the remaining keys to the values
+produced by the voting operation.
+
+<!-- Section 3.3.6.2 --> <a id='S3.3.6.2'></a>
+
+#### StructJoin
+
+A StructJoinOp operation describes a way to vote on maps that encode a
+structure-like object.
+
+Parameters:
+    `KEY_RULES` (a map from int or string to StructItemOp)
+    `UNKNOWN_RULE` (An operation to apply to unrecognized keys.)
+
+    ; Encoding
+    StructItemOp = ListOp / SimpleOp / MapJoinOp / DerivedItemOp /
+        CborDerivedItemOp
+
+    VoteableStructKey = int / tstr
+
+    StructJoinOp = {
+        op: "StructJoin",
+        key_rules: {
+            * VoteableStructKey => StructItemOp,
+        }
+        ? unknown_rule: StructItemOp
+    }
+
+To apply a StructJoinOp to a set of votes, first discard every vote that is
+not a map.  Then consider the set of keys from all the votes as a single
+list, with duplicates removed.  Also remove all entries that are not integers
+or strings from the list of keys.
+
+For each key, then look for that key in the `KEY_RULES` map.  If there is an
+entry, then apply the StructItemOp for that entry to the values for that key
+in every vote.  Otherwise, apply the `UNKNOWN_RULE` operation to the values
+for that key in every vote.  Otherwise, there is no consensus for the values
+of this key.  If there _is_ a consensus for the values, then the key should
+map to that consensus in the result.
+
+This operation always reaches a consensus, even if it is an empty map.
+
+<!-- Section 3.3.6.3 --> <a id='S3.3.6.3'></a>
+
+#### CborData
+
+A CborData operation wraps another operation, and tells the authorities
+that after the operation is completed, its result should be decoded as a
+CBOR bytestring and interpolated directly into the document.
+
+Parameters: `ITEM_OP` (Any SingleOp that can take a bstr input.)
+
+     ; Encoding
+     CborSimpleOp = {
+         op: "CborSimple",
+         item-op: MedianOp / ModeOp / ThresholdOp / NoneOp
+     }
+     CborDerivedItemOp = {
+         op: "CborDerived",
+         item-op: DerivedItemOp,
+     }
+
+To apply either of these operations to a set of votes, first apply
+`ITEM_OP` to those votes.  After that's done, check whether the
+consensus from that operation is a bstr that encodes a single item of
+"well-formed" "valid" cbor.  If it is not, this operation gives no
+consensus.  Otherwise, the consensus value for this operation is the
+decoding of that bstr value.
+
+<!-- Section 3.3.6.4 --> <a id='S3.3.6.4'></a>
+
+#### DerivedFromField
+
+This operation can only occur within a StructJoinOp operation (or a
+semantically similar SectionRules). It indicates that one field
+should have been derived from another.  It can be used, for example,
+to say that a relay's version is "derived from" a relay's descriptor
+digest.
+
+Unlike other operations, this one depends on the entire consensus (as
+computed so far), and on the entirety of the set of votes.
+
+> This operation might be a mistake, but we need it to continue lots of
+> our current behavior.
+
+Parameters:
+    `FIELDS` (one or more other locations in the vote)
+    `RULE` (the rule used to combine values)
+
+Encoding
+    ; This item is "derived from" some other field.
+    DerivedItemOp = {
+        op: "DerivedFrom",
+        fields: [ +SourceField ],
+        rule: SimpleOp
+    }
+
+    ; A field in the vote.
+    SourceField = [ FieldSource, VoteableStructKey ]
+
+    ; A location in the vote.  Each location here can only
+    ; be referenced from later locations, or from itself.
+    FieldSource = "M" ; Meta.
+               / "CP" ; ClientParam.
+               / "SP" ; ServerParam.
+               / "RM" ; Relay-meta
+               / "RS" ; Relay-SNIP
+               / "RL" ; Relay-legacy
+
+To compute a consensus with this operation, first locate each field described
+in the SourceField entry in each VoteDocument (if present), and in the
+consensus computed so far.  If there is no such field in the
+consensus or if it has not been computed yet, then
+this operation produces "no consensus".  Otherwise, discard the VoteDocuments
+that do not have the same value for the field as the consensus, and their
+corresponding votes for this field.  Do this for every listed field.
+
+At this point, we have a set of votes for this field's value that all come
+from VoteDocuments that describe the same value for the source field(s).  Apply
+the `RULE` operation to those votes in order to give the result for this
+voting operation.
+
+The DerivedFromField members in a SectionRules or a StructJoinOp
+should be computed _after_ the other members, so that they can refer
+to those members themselves.
+
+<!-- Section 3.3.7 --> <a id='S3.3.7'></a>
+
+### Voting on document sections
+
+Voting on a section of the document is similar to the StructJoin
+operation, with some exceptions.  When we vote on a section of the
+document, we do *not* apply a single voting rule immediately.
+Instead, we first "_merge_" a set of SectionRules together, and then
+apply the merged rule to the votes.  This is the only place where we
+merge rules like this.
+
+A SectionRules is _not_ a voting operation, so its format is not
+tagged with an "op":
+
+    ; Format for section rules.
+    SectionRules = {
+      * VoteableStructKey => SectionItemOp,
+      ? nil => SectionItemOp
+    }
+    SectionItemOp = StructJoinOp / StructItemOp
+
+To merge a set of SectionRules together, proceed as follows. For each
+key, consider whether at least QUORUM_AUTH authorities have voted the
+same StructItemOp for that key.  If so, that StructItemOp is the
+resulting operation for this key.  Otherwise, there is no entry for this key.
+
+Do the same for the "nil" StructItemOp; use the result as the
+`UNKNOWN_RULE`.
+
+Note that this merging operation is *not* recursive.
+
+<!-- Section 3.4 --> <a id='S3.4'></a>
+
+## A CBOR-based metaformat for votes.
+
+A vote is a signed document containing a number of sections; each
+section corresponds roughly to a section of another document, a
+description of how the vote is to be conducted, or both.
+
+    ; VoteDocument is a top-level signed vote.
+    VoteDocument = [
+        ; Each signature may be produced by a different key, if they
+        ; are all held by the same authority.
+        sig: [ + SingleSig ],
+        lifetime: Lifespan,
+        digest-alg: DigestAlgorithm,
+        body: bstr .cbor VoteContent
+    ]
+
+    VoteContent = {
+        ; List of supported consensus methods.
+        consensus-methods: [ + uint ],
+
+        ; Text-based legacy vote to be used if the negotiated
+        ; consensus method is too old.  It should itself be signed.
+        ; It's encoded as a series of text chunks, to help with
+        ; cbor-based binary diffs.
+        ? legacy-vote: [ * tstr ],
+
+        ; How should the votes within the individual sections be
+        ; computed?
+        voting-rules: VotingRules,
+
+        ; Information that the authority wants to share about this
+        ; vote, which is not itself voted upon.
+        notes: NoteSection,
+
+        ; Meta-information that the authorities vote on, which does
+        ; not actually appear in the ENDIVE or consensus directory.
+        meta: MetaSection .within VoteableSection,
+
+        ; Fields that appear in the client network parameter document.
+        client-params: ParamSection .within VoteableSection,
+        ; Fields that appear in the server network parameter document.
+        server-params: ParamSection .within VoteableSection,
+
+        ; Information about each relay.
+        relays: RelaySection,
+
+        ; Information about indices.
+        indices: IndexSection,
+
+        * tstr => any
+    }
+
+    ; Self-description of a voter.
+    VoterSection = {
+        ; human-memorable name
+        name: tstr,
+
+        ; List of link specifiers to use when uploading to this
+        ; authority. (See proposal for dirport link specifier)
+        ? ul: [ *LinkSpecifier ],
+
+        ; List of link specifiers to use when downloading from this authority.
+        ? dl: [ *LinkSpecifier ],
+
+        ; contact information for this authority.
+        ? contact: tstr,
+
+        ; legacy certificate in format given by dir-spec.txt.
+        ? legacy-cert: tstr,
+
+        ; for extensions
+        * tstr => any,
+    }
+
+    ; An indexsection says how we think routing indices should be built.
+    IndexSection = {
+        * IndexId => bstr .cbor [ IndexGroupId, GenericIndexRule ],
+    }
+    IndexGroupId = uint
+    ; A mechanism for building a single routing index.  Actual values need to
+    ; be within RecognizedIndexRule or the authority can't complete the
+    ; consensus.
+    GenericIndexRule = {
+        type: tstr,
+        * tstr => any
+    }
+    RecognizedIndexRule = EdIndex / RSAIndex / BWIndex / WeightedIndex
+    ; The values in an RSAIndex are derived from digests of Ed25519 keys.
+    EdIndex = {
+        type: "ed-id",
+        alg: DigestAlgorithm,
+        prefix: bstr,
+        suffix: bstr
+    }
+    ; The values in an RSAIndex are derived from RSA keys.
+    RSAIndex = {
+        type: "rsa-id"
+    }
+    ; A BWIndex is built by taking some uint-valued field referred to by
+    ; SourceField from all the relays that have all of required_flags set.
+    BWIndex = {
+        type: "bw",
+        bwfield: SourceField,
+        require_flags: FlagSet,
+    }
+    ; A flag can be prefixed with "!" to indicate negation.  A flag
+    ; with a name like P@X indicates support for port class 'X' in its
+    ; exit policy.
+    ;
+    ; FUTURE WORK: perhaps we should add more structure here and it
+    ; should be a matching pattern?
+    FlagSet = [ *tstr ]
+    ; A WeightedIndex applies a set of weights to a BWIndex based on which
+    ; flags the various routers have.  Relays that match a set of flags have
+    ; their weights multiplied by the corresponding WeightVal.
+    WeightedIndex = {
+        type: "weighted",
+        source: BwIndex,
+        weight: { * FlagSet => WeightVal }
+    }
+    ; A WeightVal is either an integer to multiply bandwidths by, or a
+    ; string from the Wgg, Weg, Wbm, ... set as documented in dir-spec.txt,
+    ; or a reference to an earlier field.
+    WeightVal = uint / tstr / SourceField
+    VoteableValue =  MapVal / ListVal / SimpleVal
+
+    ; A "VoteableSection" is something that we apply part of the
+    ; voting rules to.  When we apply voting rules to these sections,
+    ; we do so without regards to their semantics.  When we are done,
+    ; we use these consensus values to make the final consensus.
+    VoteableSection = {
+       VoteableStructKey => VoteableValue,
+    }
+
+    ; A NoteSection is used to convey information about the voter and
+    ; its vote that is not actually voted on.
+    NoteSection = {
+       ; Information about the voter itself
+       voter: VoterSection,
+       ; Information that the voter used when assigning flags.
+       ? flag-thresholds: { tstr => any },
+       ; Headers from the bandwidth file to be reported as part of
+       ; the vote.
+       ? bw-file-headers: {tstr => any },
+       ? shared-rand-commit: SRCommit,
+       * VoteableStructKey => VoteableValue,
+    }
+
+    ; Shared random commitment; fields are as for the current
+    ; shared-random-commit fields.
+    SRCommit = {
+       ver: uint,
+       alg: DigestAlgorithm,
+       ident: bstr,
+       commit: bstr,
+       ? reveal: bstr
+    }
+
+    ; the meta-section is voted on, but does not appear in the ENDIVE.
+    MetaSection = {
+       ; Seconds to allocate for voting and distributing signatures
+       ; Analagous to the "voting-delay" field in the legacy algorithm.
+       voting-delay: [ vote_seconds: uint, dist_seconds: uint ],
+       ; Proposed time till next vote.
+       voting-interval: uint,
+       ; proposed lifetime for the SNIPs and ENDIVEs
+       snip-lifetime: Lifespan,
+       ; proposed lifetime for client params document
+       c-param-lifetime: Lifespan,
+       ; proposed lifetime for server params document
+       s-param-lifetime: Lifespan,
+       ; signature depth for ENDIVE
+       signature-depth: uint,
+       ; digest algorithm to use with ENDIVE.
+       signature-digest-alg: DigestAlgorithm,
+       ; Current and previous shared-random values
+       ? cur-shared-rand: [ reveals: uint, rand: bstr ],
+       ? prev-shared-rand: [ reveals: uint, rand: bstr ],
+       ; extensions.
+       * VoteableStructKey => VoteableValue,
+    };
+
+    ; A ParamSection will be made into a ParamDoc after voting;
+    ; the fields are analogous.
+    ParamSection = {
+       ? certs: [ 1*2 bstr .cbor VoterCert ],
+       ? recommend-versions: [ * tstr ],
+       ? require-protos: ProtoVersions,
+       ? recommend-protos: ProtoVersions,
+       ? params: NetParams,
+       * VoteableStructKey => VoteableValue,
+    }
+    RelaySection = {
+       ; Mapping from relay identity key (or digest) to relay information.
+       * bstr => RelayInfo,
+    }
+
+    ; A RelayInfo is a vote about a single relay.
+    RelayInfo = {
+       meta: RelayMetaInfo .within VoteableSection,
+       snip: RelaySNIPInfo .within VoteableSection,
+       legacy: RelayLegacyInfo .within VoteableSection,
+    }
+
+    ; Information about a relay that doesn't go into a SNIP.
+    RelayMetaInfo = {
+        ; Tuple of published-time and descriptor digest.
+        ? desc: [ uint , bstr ],
+        ; What flags are assigned to this relay?  We use a
+        ; string->value encoding here so that only the authorities
+        ; who have an opinion on the status of a flag for a relay need
+        ; to vote yes or no on it.
+        ? flags: { *tstr=>bool },
+        ; The relay's self-declared bandwidth.
+        ? bw: uint,
+        ; The relay's measured bandwidth.
+        ? mbw: uint,
+        ; The fingerprint of the relay's RSA identity key.
+        ? rsa-id: RSAIdentityFingerprint
+    }
+    ; SNIP information can just be voted on directly; the formats
+    ; are the same.
+    RelaySNIPInfo = SNIPRouterData
+
+    ; Legacy information is used to build legacy consensuses, but
+    ; not actually required by walking onions clients.
+    RelayLegacyInfo = {
+       ; Mapping from consensus version to microdescriptor digests
+       ; and microdescriptors.
+       ? mds: [ *Microdesc ],
+    }
+
+    ; Microdescriptor votes now include the digest AND the
+    ; microdescriptor-- see note.
+    Microdesc = [
+       low: uint,
+       high: uint,
+       digest: bstr .size 32,
+       ; This is encoded in this way so that cbor-based diff tools
+       ; can see inside it.  Because of compression and diffs,
+       ; including microdesc text verbatim should be comparatively cheap.
+       content: encoded-cbor .cbor [ *tstr ],
+    ]
+
+    ; ==========
+
+    ; The VotingRules field explains how to vote on the members of
+    ; each section
+    VotingRules = {
+        meta: SectionRules,
+        params: SectionRules,
+        relay: RelayRules,
+        indices: SectionRules,
+    }
+
+    ; The RelayRules object explains the rules that apply to each
+    ; part of a RelayInfo.  A key will appear in the consensus if it
+    ; has been listed by at least key_min_count authorities.
+    RelayRules = {
+        key_min_count: IntOpArgument,
+        meta: SectionRules,
+        snip: SectionRules,
+        legacy: SectionRules,
+    }
+
+<!-- Section 3.5 --> <a id='S3.5'></a>
+
+## Computing a consensus.
+
+To compute a consensus, the authorities first verify that all the votes are
+timely and correctly signed by real authorities.  This includes
+validating all invariants stated here, and all internal documents.
+
+If they have two votes from an authority, authorities SHOULD issue a
+warning, and they should take the one that is published more
+recently.
+
+> TODO: Teor suggests that maybe we shouldn't warn about two votes
+> from an authority for the same period, and we could instead have a
+> more resilient process here, where authorities can update their
+> votes at various times over the voting period, up to some point.
+>
+> I'm not sure whether this helps reliability more or less than it risks it,
+> but it worth investigating.
+
+Next, the authorities determine the consensus method as they do today,
+using the field "consensus-method".  This can also be expressed as
+the voting operation `Threshold[SUPERQUORUM_PRESENT, false, uint]`.
+
+If there is no consensus for the consensus-method, then voting stops
+without having produced a consensus.
+
+Note that in contrast with its behavior in the current voting algorithm, the
+consensus method does not determine the way to vote on every
+individual field: that aspect of voting is controlled by the
+voting-rules.  Instead, the consensus-method changes other aspects
+of this voting, such as:
+
+    * Adding, removing, or changing the semantics of voting
+      operations.
+    * Changing the set of documents to which voting operations apply.
+    * Otherwise changing the rules that are set out in this
+      document.
+
+Once a consensus-method is decided, the next step is to compute the
+consensus for other sections in this order: `meta`, `client-params`,
+`server-params`, and `indices`.  The consensus for each is calculated
+according to the operations given in the corresponding section of
+VotingRules.
+
+Next the authorities compute a consensus on the `relays` section,
+which is done slightly differently, according to the rules of
+RelayRules element of VotingRules.
+
+Finally, the authorities transform the resulting sections into an
+ENDIVE and a legacy consensus, as in "Computing an ENDIVE" and
+"Computing a legacy consensus" below.
+
+To vote on a single VotingSection, find the corresponding
+SectionRules objects in the VotingRules of this votes, and apply it
+as described above in "Voting on document sections".
+
+<!-- Section 3.6 --> <a id='S3.6'></a>
+
+## If an older consensus method is negotiated (Transitional)
+
+The `legacy-vote` field in the vote document contains an older (v3,
+text-style) consensus vote, and is used when an older consensus
+method is negotiated.  The legacy-vote is encoded by splitting it
+into pieces, to help with CBOR diff calculation.  Authorities MAY split at
+line boundaries, space boundaries, or anywhere that will help with
+diffs.   To reconstruct the legacy vote, concatenate the members of
+`legacy-vote` in order.  The resulting string MUST validate
+according to the rules of the legacy voting algorithm.
+
+If a legacy vote is present, then authorities SHOULD include the
+same view of the network in the legacy vote as they included in their
+real vote.
+
+If a legacy vote is present, then authorities MUST
+give the same list of consensus-methods and the same voting
+schedule in both votes.  Authorities MUST reject noncompliant votes.
+
+<!-- Section 3.7 --> <a id='S3.7'></a>
+
+## Computing an ENDIVE.
+
+If a consensus-method is negotiated that is high enough to support
+ENDIVEs, then the authorities proceed as follows to transform the consensus
+sectoins above into an ENDIVE.
+
+The ParamSections from the consensus are used verbatim as the bodies of the
+`client-params` and `relay-params` fields.
+
+The fields that appear in each RelaySNIPInfo determine what goes
+into the SNIPRouterData for each relay. To build the relay section,
+first decide which relays appear according to the `key_min_count`
+field in the RelayRules.  Then collate relays across all the votes
+by their keys, and see which ones are listed.  For each key that
+appears in at least `key_min_count` votes, apply the RelayRules to
+each section of the RelayInfos for that key.
+
+The sig_params section is derived from fields in the meta section.
+Fields with identical names are simply copied; Lifespan values are
+copied to the corresponding documents (snip-lifetime as the lifespan
+for SNIPs and ENDIVEs, and c and s-param-lifetime as the lifespan
+for ParamDocs).
+
+To compute the signature nonce, use the signature digest algorithm
+to compute the digest of each input vote body, sort those digests
+lexicographically, and concatenate and hash those digests again.
+
+Routing indices are built according to named IndexRules, and grouped
+according to fields in the meta section.  See "Constructing Indices" below.
+
+> (At this point extra fields may be copied from the Meta section of
+> each RelayInfo into the ENDIVERouterData depending on the meta
+> document; we do not, however, currently specify any case where this
+> is done.)
+
+<!-- Section 3.7.1 --> <a id='S3.7.1'></a>
+
+### Constructing indices
+
+After having built the list of relays, the authorities construct and
+encode the indices that appear in the ENDIVEs.  The voted-upon
+GenericIndexRule values in the IndexSection of the consensus say how
+to build the indices in the ENDIVE, as follows.
+
+An `EdIndex` is built using the IndexType_Ed25519Id value, with the
+provided prefix and suffix values.  Authorities don't need to expand
+this index in the ENDIVE, since the relays can compute it
+deterministically.
+
+An `RSAIndex` is built using the IndexType_RSAId type.  Authorities
+don't need to expand this index in the ENDIVE, since the relays can
+compute it deterministically.
+
+A `BwIndex` is built using the IndexType_Weighted type. Each relay has a
+weight equal to some specified bandwidth field in its consensus
+RelayInfo.  If a relay is missing any of the `required_flags` in
+its meta section, or if it does not have the specified bandwidth
+field, that relay's weight becomes 0.
+
+A `WeightedIndex` is built by computing a BwIndex, and then
+transforming each relay in the list according to the flags that it
+has set.  Relays that match any set of flags in the WeightedIndex
+rule get their bandwidths multiplied by _all_ WeightVals that
+apply.  Some WeightVals are computed according to special rules,
+such as "Wgg", "Weg", and so on.  These are taken from the current
+dir-spec.txt.
+
+For both BwIndex and WeightedIndex values, authorities MUST scale
+the computed outputs so that no value is greater than UINT32_MAX;
+they MUST do by shifting all values right by lowest number of bits
+that achieves this.
+
+> We could specify a more precise algorithm, but this is simpler.
+
+Indices with the same IndexGroupId are placed in the same index
+group; index groups are ordered numerically.
+
+<!-- Section 3.8 --> <a id='S3.8'></a>
+
+## Computing a legacy consensus.
+
+When using a consensus method that supports Walking Onions, the
+legacy consensus is computed from the same data as the ENDIVE.
+Because the legacy consensus format will be frozen once Walking
+Onions is finalized, we specify this transformation directly, rather
+than in a more extensible way.
+
+The published time and descriptor digest are used directly.
+Microdescriptor negotiation proceeds as before.  Bandwidths,
+measured bandwidths, descriptor digests, published times, flags, and
+rsa-id values are taken from the RelayMetaInfo section.  Addresses,
+protovers, versions, and so on are taken from the RelaySNIPInfo. Header
+fields are all taken from the corresponding header fields in the
+MetaSection or the ClientParamsSection. All parameters are copied
+into the net-params field.
+
+<!-- Section 3.9 --> <a id='S3.9'></a>
+
+## Managing indices over time.
+
+> The present voting mechanism does not do a great job of handling
+> the authorities
+
+The semantic meaning of most IndexId values, as understood by
+clients should remain unchanging; if a client uses index 6 for
+middle nodes, 6 should _always_ mean "middle nodes".
+
+If an IndexId is going to change its meaning over time, it should
+_not_ be hardcoded by clients; it should instead be listed in the
+NetParams document, as the exit indices are in the `port-classes`
+field. (See also section 6 and appendix AH.)  If such a field needs
+to change, it also needs a migration method that allows clients with
+older and newer parameters documents to exist at the same time.
+
+<!-- Section 4 --> <a id='S4'></a>
+
+# Relay operations: Receiving and expanding ENDIVEs
+
+Previously, we introduced a format for ENDIVEs to be transmitted
+from authorities to relays.  To save on bandwidth, the relays
+download diffs rather than entire ENDIVEs.  The ENDIVE format makes
+several choices in order to make these diffs small: the Merkle tree
+is omitted, and routing indices are not included directly.
+
+To address those issues, this document describes the steps that a
+relay needs to perform, upon receiving an ENDIVE document, to derive
+all the SNIPs for that ENDIVE.
+
+Here are the steps to be followed.  We'll describe them in order,
+though in practice they could be pipelined somewhat.  We'll expand
+further on each step later on.
+
+  1. Compute routing indices positions.
+
+  2. Compute truncated SNIPRouterData variations.
+
+  3. Build signed SNIP data.
+
+  4. Compute Merkle tree.
+
+  5. Build authenticated SNIPs.
+
+Below we'll specify specific algorithms for these steps.  Note that
+relays do not need to follow the steps of these algorithms exactly,
+but they MUST produce the same outputs as if they had followed them.
+
+<!-- Section 4.1 --> <a id='S4.1'></a>
+
+## Computing index positions.
+
+For every IndexId in every Index Group, the relay will compute the
+full routing index.  Every routing index is a mapping from
+index position ranges (represented as 2-tuples) to relays, where the
+relays are represented as ENDIVERouterData members of the ENDIVE.  The
+routing index must map every possible value of the index to exactly one
+relay.
+
+An IndexSpec field describes how the index is to be constructed.  There
+are four types of IndexSpec: Raw, Raw Spans, Weighted, RSAId, and
+Ed25519Id.  We'll describe how to build the indices for each.
+
+Every index may either have an integer key, or a binary-string
+key. We define the "successor" of an integer index as the succeeding
+integer.  We define the "successor" of a binary string as the next
+binary string of the same length in lexicographical (memcmp) order.  We
+define "predecessor" as the inverse of "successor".  Both these
+operations "wrap around" the index.
+
+The algorithms here describe a set of invariants that are
+"verified".  Relays SHOULD check each of these invariants;
+authorities MUST NOT generate any ENDIVEs that violate them.  If a
+relay encounters an ENDIVE that cannot be verified, then the ENDIVE
+cannot be expanded.
+
+> NOTE: conceivably should there be some way to define an index as a
+> subset of another index, with elements weighted in different ways?  In
+> other words, "Index a is index b, except multiply these relays by 0 and
+> these relays by 1.2".  We can keep this idea sitting around in case there
+> turns out to be a use for it.
+
+<!-- Section 4.1.1 --> <a id='S4.1.1'></a>
+
+### Raw indices
+
+When the IndexType is Indextype_Raw, then its members are listed
+directly in the IndexSpec.
+
+    Algorithm: Expanding a "Raw" indexspec.
+
+    Let result_idx = {} (an empty mapping).
+
+    Let previous_pos = indexspec.first_index
+
+    For each element [i, pos2] of indexspec.index_ranges:
+
+        Verify that i is a valid index into the list of ENDIVERouterData.
+
+        Set pos1 = the successor of previous_pos.
+
+        Verify that pos1 and pos2 have the same type.
+
+        Append the mapping (pos1, pos2) => i to result_idx
+
+        Set previous_pos to pos2.
+
+    Verify that previous_pos = the predecessor of indexspec.first_index.
+
+    Return result_idx.
+
+<!-- Section 4.1.2 --> <a id='S4.1.2'></a>
+
+### Raw numeric indices
+
+If the IndexType is Indextype_RawNumeric, it is described by a set of
+spans on a 32-bit index range.
+
+    Algorithm: Expanding a RawNumeric index.
+
+    Let prev_pos = 0
+
+    For each element [i, span] of indexspec.index_ranges:
+
+        Verify that i is a valid index into the list of ENDIVERouterData.
+
+        Verify that prev_pos <= UINT32_MAX - span.
+
+        Let pos2 = prev_pos + span.
+
+        Append the mapping (pos1, pos2) => i to result_idx.
+
+        Let prev_pos = successor(pos2)
+
+    Verify that prev_pos = UINT32_MAX.
+
+    Return result_idx.
+
+<!-- Section 4.1.3 --> <a id='S4.1.3'></a>
+
+### Weighted indices
+
+If the IndexSpec type is Indextype_Weighted, then the index is
+described by assigning a probability weight to each of a number of relays.
+From these, we compute a series of 32-bit index positions.
+
+This algorithm uses 64-bit math, and 64-by-32-bit integer division.
+
+It requires that the sum of weights is no more than UINT32_MAX.
+
+    Algorithm: Expanding a "Weighted" indexspec.
+
+    Let total_weight = SUM(indexspec.index_weights)
+
+    Verify total_weight <= UINT32_MAX.
+
+    Let total_so_far = 0.
+
+    Let result_idx = {} (an empty mapping).
+
+    Define POS(b) = FLOOR( (b << 32) / total_weight).
+
+    For 0 <= i < LEN(indexspec.indexweights):
+
+       Let w = indexspec.indexweights[i].
+
+       Let lo = POS(total_so_far).
+
+       Let total_so_far = total_so_far + w.
+
+       Let hi = POS(total_so_far) - 1.
+
+       Append (lo, hi) => i to result_idx.
+
+    Verify that total_so_far = total_weight.
+
+    Verify that the last value of "hi" was UINT32_MAX.
+
+    Return result_idx.
+
+This algorithm is a bit finicky in its use of division, but it
+results in a mapping onto 32 bit integers that completely covers the
+space of available indices.
+
+<!-- Section 4.1.4 --> <a id='S4.1.4'></a>
+
+### RSAId indices
+
+If the IndexSpec type is Indextype_RSAId then the index is a set of
+binary strings describing the routers' legacy RSA identities, for
+use in the HSv2 hash ring.
+
+These identities are truncated to a fixed length.  Though the SNIP
+format allows _variable_-length binary prefixes, we do not use this
+feature.
+
+    Algorithm: Expanding an "RSAId" indexspec.
+
+    Let R = [ ] (an empty list).
+
+    Take the value n_bytes from the IndexSpec.
+
+    For 0 <= b_idx < MIN( LEN(indexspec.members) * 8,
+                          LEN(list of ENDIVERouterData) ):
+
+       Let b = the b_idx'th bit of indexspec.members.
+
+       If b is 1:
+           Let m = the b_idx'th member of the ENDIVERouterData list.
+
+           Verify that m has its RSAIdentityFingerprint set.
+
+           Let pos = m.RSAIdentityFingerprint, truncated to n_bytes.
+
+           Add (pos, b_idx) to the list R.
+
+    Return INDEX_FROM_RING_KEYS(R).
+
+    Sub-Algorithm: INDEX_FROM_RING_KEYS(R)
+
+    First, sort R according to its 'pos' field.
+
+    For each member (pos, idx) of the list R:
+
+        If this is the first member of the list R:
+            Let key_low = pos for the last member of R.
+        else:
+            Let key_low = pos for the previous member of R.
+
+        Let key_high = predecessor(pos)
+
+        Add (key_low, key_high) => idx to result_idx.
+
+    Return result_idx.
+
+<!-- Section 4.1.5 --> <a id='S4.1.5'></a>
+
+### Ed25519 indices
+
+If the IndexSpec type is Indextype_Ed25519, then the index is a set of
+binary strings describing the routers' positions in a hash ring,
+derived from their Ed25519 identity keys.
+
+This algorithm is a generalization of the one used for hsv3 rings,
+to be used to compute the hsv3 ring and other possible future
+derivatives.
+
+    Algorithm: Expanding an "Ed25519Id" indexspec.
+
+    Let R = [ ] (an empty list).
+
+    Take the values prefix, suffix, and n_bytes from the IndexSpec.
+
+    Let H() be the digest algorithm specified by d_alg from the
+    IndexSpec.
+
+    For 0 <= b_idx < MIN( LEN(indexspec.members) * 8,
+                          LEN(list of ENDIVERouterData) ):
+
+       Let b = the b_idx'th bit of indexspec.members.
+
+       If b is 1:
+           Let m = the b_idx'th member of the ENDIVERouterData list.
+
+           Let key = m's ed25519 identity key, as a 32-byte value.
+
+           Compute pos = H(prefix || key || suffix)
+
+           Truncate pos to n_bytes.
+
+           Add (pos, b_idx) to the list R.
+
+    Return INDEX_FROM_RING_KEYS(R).
+
+<!-- Section 4.1.6 --> <a id='S4.1.6'></a>
+
+### Building a SNIPLocation
+
+After computing all the indices in an IndexGroup, relays combine
+them into a series of SNIPLocation objects. Each SNIPLocation
+MUST contain all the IndexId => IndexRange entries that point to a
+given ENDIVERouterData, for the IndexIds listed in an IndexGroup.
+
+    Algorithm: Build a list of SNIPLocation objects from a set of routing indices.
+
+    Initialize R as [ { } ] * LEN(relays)   (A list of empty maps)
+
+    For each IndexId "ID" in the IndexGroup:
+
+       Let router_idx be the index map calculated for ID.
+       (This is what we computed previously.)
+
+       For each entry ( (LO, HI) => idx) in router_idx:
+
+          Let R[idx][ID] = (LO, HI).
+
+SNIPLocation objects are thus organized in the order in which they will
+appear in the Merkle tree: that is, sorted by the position of their
+corresponding ENDIVERouterData.
+
+Because SNIPLocation objects are signed, they must be encoded as "canonical"
+cbor, according to section 3.9 of RFC 7049.
+
+If R[idx] is {} (the empty map) for any given idx, then no SNIP will be
+generated for the SNIPRouterData at that routing index for this index group.
+
+<!-- Section 4.2 --> <a id='S4.2'></a>
+
+## Computing truncated SNIPRouterData.
+
+An index group can include an `omit_from_snips` field to indicate that
+certain fields from a SNIPRouterData should not be included in the
+SNIPs for that index group.
+
+Since a SNIPRouterData needs to be signed, this process has to be
+deterministic.  Thus, the truncated SNIPRouterData should be computed by
+removing the keys and values for EXACTLY the keys listed and no more.  The
+remaining keys MUST be left in the same order that they appeared in the
+original SNIPRouterData, and they MUST NOT be re-encoded.
+
+(Two keys are "the same" if and only if they are integers encoding the same
+value, or text strings with the same UT-8 content.)
+
+There is no need to compute a SNIPRouterData when no SNIP is going to be
+generated for a given router.
+
+<!-- Section 4.3 --> <a id='S4.3'></a>
+
+## Building the Merkle tree.
+
+After computing a list of (SNIPLocation, SNIPRouterData) for every entry
+in an index group, the relay needs to expand a Merkle tree to
+authenticate every SNIP.
+
+There are two steps here: First the relay generates the leaves, and then
+it generates the intermediate hashes.
+
+To generate the list of leaves for an index group, the relay first
+removes all entries from the (SNIPLocation, SNIPRouterData) list that
+have an empty index map.  The relay then puts `n_padding_entries` "nil"
+entries at the end of the list.
+
+To generate the list of leaves for the whole Merkle tree, the relay
+concatenates these index group lists in the order in which they appear
+in the ENDIVE, and pads the resulting list with "nil" entries until the
+length of the list is a power of two: 2^`tree-depth` for some integer
+`tree-depth`.  Let LEAF(IDX) denote the entry at position IDX in this
+list, where IDX is a D-bit bitstring.  LEAF(IDX) is either a byte string
+or nil.
+
+The relay then recursively computes the hashes in the Merkle tree as
+follows.  (Recall that `H_node()` and `H_leaf()` are hashes taking
+a bit-string PATH, a LIFESPAN and NONCE from the signature information,
+and a variable-length string ITEM.)
+
+    Recursive defintion: HM(PATH)
+
+    Given PATH a bitstring of length no more than tree-depth.
+
+    Define S:
+        S(nil) = an all-0 string of the same length as the hash output.
+        S(x) = x, for all other x.
+
+    If LEN(PATH) = tree-depth:   (Leaf case.)
+       If LEAF(PATH) = nil:
+         HM(PATH) = nil.
+       Else:
+         HM(PATH) = H_node(PATH, LIFESPAN, NONCE, LEAF(PATH)).
+
+    Else:
+       Let LEFT = HM(PATH || 0)
+       Let RIGHT = HM(PATH || 1)
+       If LEFT = nil and RIGHT = nil:
+           HM(PATH) = nil
+       else:
+           HM(PATH) = H_node(PATH, LIFESPAN, NONCE, S(LEFT) || S(RIGHT))
+
+Note that entries aren't computed for "nil" leaves, or any node all of
+whose children are "nil".  The "nil" entries only exist to place all
+leaves at a constant depth, and to enable spacing out different sections
+of the tree.
+
+If `signature-depth` for the ENDIVE is N, the relay does not need to
+compute any Merkle tree entries for PATHs of length shorter than N bits.
+
+<!-- Section 4.4 --> <a id='S4.4'></a>
+
+## Assembling the SNIPs
+
+Finally, the relay has computed a list of encoded (SNIPLocation,
+RouterData) values, and a Merkle tree to authenticate them.  At this
+point, the relay builds them into SNIPs, using the `sig_params` and
+`signatures` from the ENDIVE.
+
+    Algorithm: Building a SNIPSignature for a SNIP.
+
+    Given a non-nil (SNIPLocation, RouterData) at leaf position PATH.
+
+    Let SIG_IDX = PATH, truncated to signature-depth bits.
+    Consider SIG_IDX as an integer.
+
+    Let Sig = signatures[SIG_IDX] -- either the SingleSig or the MultiSig
+    for this snip.
+
+    Let HashPath = []   (an empty list).
+    For bitlen = signature-depth+1 ... tree-depth-1:
+        Let X = PATH, truncated to bitlen bits.
+        Invert the final bit of PATH.
+        Append HM(PATH) to HashPath.
+
+    The SnipSignature's signature values is Sig, and its merkle_path is
+    HashPath.
+
+<!-- Section 4.5 --> <a id='S4.5'></a>
+
+## Implementation considerations
+
+A relay only needs to hold one set of SNIPs at a time: once one
+ENDIVE's SNIPs have been extracted, then the SNIPs from the previous
+ENDIVE can be discarded.
+
+To save memory, a relay MAY store SNIPs to disk, and mmap them as
+needed.
+
+<!-- Section 5 --> <a id='S5'></a>
+
+# Extending circuits with Walking Onions
+
+When a client wants to extend a circuit, there are several
+possibilities.  It might need to extend to an unknown relay with
+specific properties.  It might need to extend to a particular relay
+from which it has received a SNIP before.  In both cases, there are
+changes to be made in the circuit extension process.
+
+Further, there are changes we need to make for the handshake between
+the extending relay and the target relay.  The target relay is no
+longer told by the client which of its onion keys it should use... so
+the extending relay needs to tell the target relay which keys are in
+the SNIP that the client is using.
+
+<!-- Section 5.1 --> <a id='S5.1'></a>
+
+## Modifying the EXTEND/CREATE handshake
+
+First, we will require that proposal 249 (or some similar proposal
+for wide CREATE and EXTEND cells) is in place, so that we can have
+EXTEND cells larger than can fit in a single cell.  (See
+319-wide-everything.md for an example proposal to supersede 249.)
+
+We add new fields to the CREATE2 cell so that relays can send each
+other more information without interfering with the client's part of
+the handshake.
+
+The CREATE2, CREATED2, and EXTENDED2 cells change as follows:
+
+      struct create2_body {
+         // old fields
+         u16 htype; // client handshake type
+         u16 hlen; // client handshake length
+         u8 hdata[hlen]; // client handshake data.
+
+         // new fields
+         u8 n_extensions;
+         struct extension extension[n_extensions];
+      }
+
+      struct created2_body {
+         // old fields
+         u16 hlen;
+         u8 hdata[hlen];
+
+         // new fields
+         u8 n_extensions;
+         struct extension extension[n_extensions];
+      }
+
+      struct truncated_body {
+         // old fields
+         u8 errcode;
+
+         // new fields
+         u8 n_extensions;
+         struct extension extension[n_extensions];
+      }
+
+      // EXTENDED2 cells can now use the same new fields as in the
+      // created2 cell.
+
+      struct extension {
+         u16 type;
+         u16 len;
+         u8 body[len];
+      }
+
+These extensions are defined by this proposal:
+
+  [01] -- `Partial_SNIPRouterData` -- Sent from an extending relay
+          to a target relay. This extension holds one or more fields
+          from the SNIPRouterData that the extending relay is using,
+          so that the target relay knows (for example) what keys to
+          use.  (These fields are determined by the
+          "forward_with_extend" field in the ENDIVE.)
+
+  [02] -- Full_SNIP -- an entire SNIP that was used in an attempt to
+          extend the circuit.  This must match the client's provided
+          index position.
+
+  [03] -- Extra_SNIP -- an entire SNIP that was not used to extend
+          the circuit, but which the client requested anyway.  This
+          can be sent back from the extending relay when the client
+          specifies multiple index positions, or uses a nonzero "nth" value
+          in their `snip_index_pos` link specifier.
+
+  [04] -- SNIP_Request -- a 32-bit index position, or a single zero
+          byte, sent away from the client.  If the byte is 0, the
+          originator does not want a SNIP.  Otherwise, the
+          originator does want a SNIP containing the router and the
+          specified index.  Other values are unspecified.
+
+By default, EXTENDED2 cells are sent with a SNIP iff the EXTENDED2
+cell used a `snip_index_pos` link specifier, and CREATED2 cells are
+not sent with a SNIP.
+
+<!-- Section 5.1.1 --> <a id='S5.1.1'></a>
+
+### New link specifiers
+
+We add a new link specifier type for a router index, using the
+following coding for its contents:
+
+    /* Using trunnel syntax here. */
+    struct snip_index_pos {
+        u32 index_id; // which index is it?
+        u8 nth; // how many SNIPs should be skipped/included?
+        u8 index_pos[]; // extends to the end of the link specifier.
+    }
+
+The `index_pos` field can be longer or shorter than the actual width of
+the router index.  If it is too long, it is truncated.  If it is too
+short, it is extended with zero-valued bytes.
+
+Any number of these link specifiers may appear in an EXTEND cell.
+If there is more then one, then they should appear in order of
+client preference; the extending relay may extend to any of the
+listed routers.
+
+This link specifier SHOULD NOT be used along with IPv4, IPv6, RSA
+ID, or Ed25519 ID link specifiers.  Relays receiving such a link
+specifier along with a `snip_index_pos` link specifier SHOULD reject
+the entire EXTEND request.
+
+If `nth` is nonzero, then link specifier means "the n'th SNIP after
+the one defined by the SNIP index position."  A relay MAY reject
+this request if `nth` is greater than 4.  If the relay does not
+reject this request, then it MUST include all snips between
+`index_pos` and the one that was actually used in an Extra_Snip
+extension.  (Otherwise, the client would not be able to verify that
+it had gotten the correct SNIP.)
+
+> I've avoided use of CBOR for these types, under the assumption that we'd
+> like to use CBOR for directory stuff, but no more.  We already have
+> trunnel-like objects for this purpose.
+
+<!-- Section 5.2 --> <a id='S5.2'></a>
+
+## Modified ntor handshake
+
+We adapt the ntor handshake from tor-spec.txt for this use, with the
+following main changes.
+
+  * The NODEID and KEYID fields are omitted from the input.
+    Instead, these fields _may_ appear in a PartialSNIPData extension.
+
+  * The NODEID and KEYID fields appear in the reply.
+
+  * The NODEID field is extended to 32 bytes, and now holds the
+    relay's ed25519 identity.
+
+So the client's message is now:
+
+   CLIENT_PK [32 bytes]
+
+And the relay's reply is now:
+
+   NODEID    [32 bytes]
+   KEYID     [32 bytes]
+   SERVER_PK [32 bytes]
+   AUTH      [32 bytes]
+
+otherwise, all fields are computed as described in tor-spec.
+
+When this handshake is in use, the hash function is SHA3-256 and keys
+are derived using SHAKE-256, as in rend-spec-v3.txt.
+
+> Future work: We may wish to update this choice of functions
+> between now and the implementation date, since SHA3 is a bit
+> pricey.  Perhaps one of the BLAKEs would be a better choice.  If
+> so, we should use it more generally.  On the other hand, the
+> presence of public-key operations in the handshake _probably_
+> outweighs the use of SHA3.
+
+We will have to give this version of the handshake a new handshake
+type.
+
+<!-- Section 5.3 --> <a id='S5.3'></a>
+
+## New relay behavior on EXTEND and CREATE failure.
+
+If an EXTEND2 cell based on an routing index fails, the relay should
+not close the circuit, but should instead send back a TRUNCATED cell
+containing the SNIP in an extension.
+
+If a CREATE2 cell fails and a SNIP was requested, then instead of
+sending a DESTROY cell, the relay SHOULD respond with a CREATED2
+cell containing 0 bytes of handshake data, and the SNIP in an
+extension.  Clients MAY re-extend or close the circuit, but should
+not leave it dangling.
+
+<!-- Section 5.4 --> <a id='S5.4'></a>
+
+## NIL handshake type
+
+We introduce a new handshake type, "NIL".  The NIL handshake always
+fails.  A client's part of the NIL handshake is an empty bytestring;
+there is no server response that indicates success.
+
+The NIL handshake can used by the client when it wants to fetch a
+SNIP without creating a circuit.
+
+Upon receiving a request to extend with the NIL circuit type, a
+relay SHOULD NOT actually open any connection or send any data to
+the target relay.  Instead, it should respond with a TRUNCATED cell
+with the SNIP(s) that the client requested in one or more Extra_SNIP
+extensions.
+
+<!-- Section 5.5 --> <a id='S5.5'></a>
+
+## Padding handshake cells to a uniform size
+
+To avoid leaking information, all CREATE/CREATED/EXTEND/EXTENDED
+cells SHOULD be padded to the same sizes.  In all cases, the amount
+of padding is controlled by a set of network parameters:
+"create-pad-len", "created-pad-len", "extend-pad-len" and
+"extended-pad-len".  These parameters determine the minimum length
+that the cell body or relay cell bodies should be.
+
+If a cell would be sent whose body is less than the corresponding
+parameter value, then the sender SHOULD pad the body by adding
+zero-valued bytes to the cell body.  As usual, receivers MUST ignore
+extra bytes at the end of cells.
+
+> ALTERNATIVE: We could specify a more complicated padding
+> mechanism, eg. 32 bytes of zeros then random bytes.
+
+
+<!-- Section 6 --> <a id='S6'></a>
+
+# Client behavior with walking onions
+
+Today's Tor clients have several behaviors that become somewhat
+more difficult to implement with Walking Onions.  Some of these
+behaviors are essential and achievable.  Others can be achieved with
+some effort, and still others appear to be incompatible with the
+Walking Onions design.
+
+<!-- Section 6.1 --> <a id='S6.1'></a>
+
+## Bootstrapping and guard selection
+
+When a client first starts running, it has no guards on the Tor
+network, and therefore can't start building circuits immediately.
+To produce a list of possible guards, the client begins connecting
+to one or more fallback directories on their ORPorts, and building
+circuits through them.  These are 3-hop circuits.  The first hop of
+each circuit is the fallback directory; the second and third hops
+are chosen from the Middle routing index.  At the third hop, the
+client then sends an informational request for a guard's SNIP.  This
+informational request is an EXTEND2 cell with handshake type NIL,
+using a random spot on the Guard routing index.
+
+Each such request yields a single SNIP that the client will store.
+These SNIPs, in the order in which they were _requested_, will form the
+client's list of "Sampled" guards as described in guard-spec.txt.
+
+Clients SHOULD ensure that their sampled guards are not
+linkable to one another.  In particular, clients SHOULD NOT add more
+than one guard retrieved from the same third hop on the same
+circuit. (If it did, that third hop would realize that some client using
+guard A was also using guard B.)
+
+> Future work: Is this threat real?  It seems to me that knowing one or two
+> guards at a time in this way is not a big deal, though knowing the whole
+> set would sure be bad.  However, we shouldn't optimize this kind of
+> defense away until we know that it's actually needless.
+
+If a client's network connection or choice of entry nodes is heavily
+restricted, the client MAY request more than one guard at a time, but if
+it does so, it SHOULD discard all but one guard retrieved from each set.
+
+After choosing guards, clients will continue to use them even after
+their SNIPs expire.  On the first circuit through each guard after
+opening a channel, clients should ask that guard for a fresh SNIP for
+itself, to ensure that the guard is still listed in the consensus, and
+to keep the client's information up-to-date.
+
+<!-- Section 6.2 --> <a id='S6.2'></a>
+
+## Using bridges
+
+As now, clients are configured to use a bridge by using an address and a
+public key for the bridge.  Bridges behave like guards, except that they
+are not listed in any directory or ENDIVE, and so cannot prove
+membership when the client connects to them.
+
+On the first circuit through each channel to a bridge, the client
+asks that bridge for a SNIP listing itself in the `Self` routing
+index.  The bridge responds with a self-created unsigned SNIP:
+
+     ; This is only valid when received on an authenticated connection
+     ; to a bridge.
+     UnsignedSNIP = [
+        ; There is no signature on this SNIP.
+        auth : nil,
+
+        ; Next comes the location of the SNIP within the ENDIVE.  This
+        ; SNIPLocation will list only the Self index.
+        index : bstr .cbor SNIPLocation,
+
+        ; Finally comes the information about the router.
+        router : bstr .cbor SNIPRouterData,
+     ]
+
+*Security note*: Clients MUST take care to keep UnsignedSNIPs separated
+from signed ones. These are not part of any ENDIVE, and so should not be
+used for any purpose other than connecting through the bridge that the
+client has received them from.  They should be kept associated with that
+bridge, and not used for any other, even if they contain other link
+specifiers or keys.  The client MAY use link specifiers from the
+UnsignedSNIP on future attempts to connect to the bridge.
+
+<!-- Section 6.3 --> <a id='S6.3'></a>
+
+## Finding relays by exit policy
+
+To find a relay by exit policy, clients might choose the exit
+routing index corresponding to the exit port they want to use.  This
+has negative privacy implications, however, since the middle node
+discovers what kind of exit traffic the client wants to use.
+Instead, we support two other options.
+
+First, clients may build anonymous three-hop circuits and then use those
+circuits to request the SNIPs that they will use for their exits.  This
+may, however, be inefficient.
+
+Second, clients may build anonymous three-hop circuits and then use a
+BEGIN cell to try to open the connection when they want.  When they do
+so, they may include a new flag in the begin cell, "DVS" to enable
+Delegated Verifiable Selection.  As described in the Walking Onions
+paper, DVS allows a relay that doesn't support the requested port to
+instead send the client the SNIP of a relay that does.  (In the paper,
+the relay uses a digest of previous messages to decide which routing
+index to use. Instead, we have the client send an index field.)
+
+This requires changes to the BEGIN and END cell formats.  After the
+"flags" field in BEGIN cells, we add an extension mechanism:
+
+    struct begin_cell {
+        nulterm addr_port;
+        u32 flags;
+        u8 n_extensions;
+        struct extension exts[n_extensions];
+    }
+
+We allow the `snip_index_pos` link specifier type to appear as a begin
+extension.
+
+END cells will need to have a new format that supports including policy and
+SNIP information.  This format is enabled whenever a new `EXTENDED_END_CELL`
+flag appears in the begin cell.
+
+    struct end_cell {
+        u8 tag IN [ 0xff ]; // indicate that this isn't an old-style end cell.
+        u8 reason;
+        u8 n_extensions;
+        struct extension exts[n_extensions];
+    }
+
+We define three END cell extensions.  Two types are for addresses, that
+indicate what address was resolved and the associated TTL:
+
+    struct end_ext_ipv4 {
+        u32 addr;
+        u32 ttl;
+    }
+    struct end_ext_ipv6 {
+        u8 addr[16];
+        u32 ttl;
+    }
+
+One new END cell extension is used for delegated verifiable selection:
+
+    struct end_ext_alt_snip {
+        u16 index_id;
+        u8 snip[..];
+    }
+
+This design may require END cells to become wider; see
+319-wide-everything.md for an example proposal to
+supersede proposal 249 and allow more wide cell types.
+
+<!-- Section 6.4 --> <a id='S6.4'></a>
+
+## Universal path restrictions
+
+There are some restrictions on Tor paths that all clients should obey,
+unless they are configured not to do so.  Some of these restrictions
+(like "start paths with a Guard node" or "don't use an Exit as a middle
+when Exit bandwidth is scarce") are captured by the index system. Some
+other restrictions are not.  Here we describe how to implement those.
+
+The general approach taken here is "build and discard".  Since most
+possible paths will not violate these universal restrictions, we
+accept that a fraction of the paths built will not be usable.
+Clients tear them down a short time after they are built.
+
+Clients SHOULD discard a circuit if, after it has been built, they
+find that it contains the same relay twice, or it contains more than
+one relay from the same family or from the same subnet.
+
+Clients MAY remember the SNIPs they have received, and use those
+SNIPs to avoid index ranges that they would automatically reject.
+Clients SHOULD NOT store any SNIP for longer than it is maximally
+recent.
+
+> NOTE: We should continue to monitor the fraction of paths that are
+> rejected in this way.  If it grows too high, we either need to amend
+> the path selection rules, or change authorities to e.g. forbid more
+> than a certain fraction of relay weight in the same family or subnet.
+
+> FUTURE WORK: It might be a good idea, if these restrictions truly are
+> 'universal', for relays to have a way to say "You wouldn't want that
+> SNIP; I am giving you the next one in sequence" and send back both
+> SNIPs.  This would need some signaling in the EXTEND/EXTENDED cells.
+
+<!-- Section 6.5 --> <a id='S6.5'></a>
+
+## Client-configured path restrictions
+
+Sometimes users configure their clients with path restrictions beyond
+those that are in ordinary use.  For example, a user might want to enter
+only from US relays, but never exit from US.  Or they might be
+configured with a short list of vanguards to use in their second
+position.
+
+<!-- Section 6.5.1 --> <a id='S6.5.1'></a>
+
+### Handling "light" restrictions
+
+If a restriction only excludes a small number of relays, then clients
+can continue to use the "build and discard" methodology described above.
+
+<!-- Section 6.5.2 --> <a id='S6.5.2'></a>
+
+### Handling some "heavy" restrictions
+
+Some restrictions can exclude most relays, and still be reasonably easy
+to implement if they only _include_ a small fraction of relays.  For
+example, if the user has a EntryNodes restriction that contains only a
+small group of relays by exact IP address, the client can connect or
+extend to one of those addresses specifically.
+
+If we decide IP ranges are important, that IP addresses without
+ports are important, or that key specifications are important, we
+can add routing indices that list relays by IP, by RSAId, or by
+Ed25519 Id.  Clients could then use those indices to remotely
+retrieve SNIPs, and then use those SNIPs to connect to their
+selected relays.
+
+> Future work: we need to decide how many of the above functions to actually
+> support.
+
+<!-- Section 6.5.3 --> <a id='S6.5.3'></a>
+
+### Recognizing too-heavy restrictions
+
+The above approaches do not handle all possible sets of restrictions. In
+particular, they do a bad job for restrictions that ban a large fraction
+of paths in a way that is not encodeable in the routing index system.
+
+If there is substantial demand for such a path restriction, implementors
+and authority operators should figure out how to implement it in the
+index system if possible.
+
+Implementations SHOULD track what fraction of otherwise valid circuits
+they are closing because of the user's configuration.  If this fraction
+is above a certain threshold, they SHOULD issue a warning; if it is
+above some other threshold, they SHOULD refuse to build circuits
+entirely.
+
+> Future work: determine which fraction appears in practice, and use that to
+> set the appropriate thresholds above.
+
+<!-- Section 7 --> <a id='S7'></a>
+
+# Using and providing onion services with Walking Onions
+
+Both live versions of the onion service design rely on a ring of
+hidden service directories for use in uploading and downloading
+hidden service descriptors.  With Walking Onions, we can use routing
+indices based on Ed25519 or RSA identity keys to retrieve this data.
+
+(The RSA identity ring is unchanging, whereas the Ed25519 ring
+changes daily based on the shared random value: for this reason, we
+have to compute two simultaneous indices for Ed25519 rings: one for
+the earlier date that is potentially valid, and one for the later
+date that is potentially valid. We call these `hsv3-early` and
+`hsv3-late`.)
+
+Beyond the use of these indices, however, there are other steps that
+clients and services need to take in order to maintain their privacy.
+
+<!-- Section 7.1 --> <a id='S7.1'></a>
+
+## Finding HSDirs
+
+When a client or service wants to contact an HSDir, it SHOULD do so
+anonymously, by building a three-hop anonymous circuit, and then
+extending it a further hop using the snip_span link specifier to
+upload to any of the first 3 replicas on the ring.  Clients SHOULD
+choose an 'nth' at random; services SHOULD upload to each replica.
+
+Using a full 80-bit or 256-bit index position in the link specifier
+would leak the chosen service to somebody other than the directory.
+Instead, the client or service SHOULD truncate the identifier to a
+number of bytes equal to the network parameter `hsv2-index-bytes` or
+`hsv3-index-bytes` respectively.  (See Appendix C.)
+
+<!-- Section 7.2 --> <a id='S7.2'></a>
+
+## SNIPs for introduction points
+
+When services select an introduction point, they should include the
+SNIP for the introduction point in their hidden service directory
+entry, along with the introduction-point fields.  The format for
+this entry is:
+
+    "snip" NL snip NL
+      [at most once per introduction points]
+
+Clients SHOULD begin treating the link specifier and onion-key
+fields of each introduction point as optional when the "snip" field
+is present, and when the `hsv3-tolerate-no-legacy` network parameter
+is set to 1. If either of these fields _is_ present, and the SNIP is
+too, then these fields MUST match those listed in the SNIPs.
+Clients SHOULD reject descriptors with mismatched fields, and alert
+the user that the service may be trying a partitioning attack.
+The "legacy-key" and "legacy-key-cert" fields, if present, should be
+checked similarly.
+
+> Using the SNIPs in these ways allows services to prove that their
+> introduction points have actually been listed in the consensus
+> recently.  It also lets clients use introduction point features
+> that the relay might not understand.
+
+Services should include these fields based on a set of network
+parameters: `hsv3-intro-snip` and `hsv3-intro-legacy-fields`.
+(See appendix C.)
+
+Clients should use these fields only when Walking Onions support is
+enabled; see section 09.
+
+<!-- Section 7.3 --> <a id='S7.3'></a>
+
+## SNIPs for rendezvous points
+
+When a client chooses a rendezvous point for a v3 onion service, it
+similarly has the opportunity to include the SNIP of its rendezvous
+point in the encrypted part of its INTRODUCE cell.  (This may cause
+INTRODUCE cells to become fragmented; see proposal about fragmenting
+relay cells.)
+
+> Using the SNIPs in these ways allows services to prove that their
+> introduction points have actually been listed in the consensus
+> recently.  It also lets services use introduction point features
+> that the relay might not understand.
+
+To include the SNIP, the client places it in an extension in the
+INTRODUCE cell.  The onion key can now be omitted[*], along with
+the link specifiers.
+
+> [*] Technically, we use a zero-length onion key, with a new type
+> "implicit in SNIP".
+
+To know whether the service can recognize this kind of cell, the
+client should look for the presence of a "snips-allowed 1" field in
+the encrypted part of the hidden service descriptor.
+
+In order to prevent partitioning, services SHOULD NOT advertise
+"snips-allowed 1" unless the network parameter
+"hsv3-rend-service-snip" is set to 1.  Clients SHOULD NOT use this
+field unless "hsv3-rend-client-snip" is set to 1.
+
+<!-- Section 7.4 --> <a id='S7.4'></a>
+
+## TAP keys and where to find them
+
+If v2 hidden services are still supported when Walking Onions arrives
+on the network, we have two choices:  We could migrate them to use
+ntor keys instead of TAP, or we could provide a way for TAP keys to
+be advertised with Walking Onions.
+
+The first option would appear to be far simpler. See
+proposal draft 320-tap-out-again.md.
+
+The latter option would require us to put RSA-1024 keys in SNIPs, or
+put a digest of them in SNIPs and give some way to retrieve them
+independently.
+
+(Of course, it's possible that we will have v2 onion services
+deprecated by the time Walking Onions is implemented.  If so, that
+will simplify matters a great deal too.)
+
+
+<!-- Section 8 --> <a id='S8'></a>
+
+# Tracking Relay honesty
+
+Our design introduces an opportunity for dishonest relay behavior:
+since multiple ENDIVEs are valid at the same time, a malicious relay
+might choose any of several possible SNIPs in response to a client's
+routing index value.
+
+Here we discuss several ways to mitigate this kind of attack.
+
+<!-- Section 8.1 --> <a id='S8.1'></a>
+
+## Defense: index stability
+
+First, the voting process should be designed such that relays do not
+needlessly move around the routing index.  For example, it would
+_not_ be appropriate to add an index type whose value is computed by
+first putting the relays into a pseudorandom order.  Instead, index
+voting should be deterministic and tend to give similar outputs for
+similar inputs.
+
+This proposal tries to achieve this property in its index voting
+algorithms.  We should measure the degree to which we succeed over
+time, by looking at all of the ENDIVEs that are valid at any
+particular time, and sampling several points for each index to see
+how many distinct relays are listed at each point, across all valid
+ENDIVEs.
+
+We do not need this stability property for routing indices whose
+purpose is nonrandomized relay selection, such as those indices used
+for onion service directories.
+
+<!-- Section 8.2 --> <a id='S8.2'></a>
+
+## Defense: enforced monotonicity
+
+Once an honest relay has received an ENDIVE, it has no reason to
+keep any previous ENDIVEs or serve SNIPs from them.  Because of
+this, relay implementations SHOULD ensure that no data is served
+from a new ENDIVE until all the data from an old ENDIVE is
+thoroughly discarded.
+
+Clients and relays can use this monotonicity property to keep relays
+honest: once a relay has served a SNIP with some timestamp `T`, that
+relay should never serve any other SNIP with a timestamp earlier than
+`T`.  Clients SHOULD track the most recent SNIP timestamp that they
+have received from each of their guards, and MAY track the most
+recent SNIP timestamps that they have received from other relays as
+well.
+
+<!-- Section 8.3 --> <a id='S8.3'></a>
+
+## Defense: limiting ENDIVE variance within the network.
+
+The primary motivation for allowing long (de facto) lifespans on
+today's consensus documents is to keep the network from grinding to
+a halt if the authorities fail to reach consensus for a few hours.
+But in practice, _if_ there is a consensus, then relays should have
+it within an hour or two, so they should not be falling a full day out
+of date.
+
+Therefore we can potentially add a client behavior that, within N
+minutes after the client has seen any SNIP with timestamp `T`,
+the client should not accept any SNIP with timestamp earlier than
+`T - Delta`.
+
+Values for N and Delta are controlled by network parameters
+(`enforce-endive-dl-delay-after` and `allow-endive-dl-delay`
+respectively in appendix C).  N should be about as long as we expect
+it to take for a single ENDIVE to propagate to all the relays on the
+network; Delta should be about as long as we would like relays to go
+between updating ENDIVEs under ideal circumstances.
+
+<!-- Section 9 --> <a id='S9'></a>
+
+# Migrating to Walking Onions
+
+This proposal is a major change in the Tor network that will
+eventually require the participation of all relays [*], and will make
+clients who support it distinguishable from clients that don't.
+
+> [*] Technically, the last relay in the path doesn't need support.
+
+To keep the compatibility issues under control, here is the order in which it
+should be deployed on the network.
+
+1. First, authorities should add support for voting on ENDIVEs.
+
+2. Relays may immediately begin trying to download and reconstruct
+   ENDIVEs. (Relay versions are public, so they leak nothing by
+   doing this.)
+
+3. Once a sufficient number of authorities are voting on ENDIVEs and
+   unlikely to downgrade, relays should begin serving parameter documents
+   and responding to walking-onion EXTEND and CREATE cells.  (Again,
+   relay versions are public, so this doesn't leak.)
+
+4. In parallel with relay support, Tor should also add client
+   support for Walking Onions.  This should be disabled by default,
+   however, since it will only be usable with the subset of relays
+   that support Walking Onions, and since it would make clients
+   distinguishable.
+
+5. Once enough of the relays (possibly, all) support Walking Onions,
+   the client support can be turned on.  They will not be able to
+   use old relays that do not support Walking Onions.
+
+6. Eventually, relays that do not support Walking Onions should not
+   be listed in the consensus.
+
+Client support for Walking Onions should be enabled or disabled, at
+first, with a configuration option.  Once it seems stable, the
+option should have an "auto" setting that looks at a network
+parameter. This parameter should NOT be a simple "on" or "off",
+however: it should be the minimum client version whose support for
+Walking Onions is believed to be correct.
+
+<!-- Section 9.1 --> <a id='S9.1'></a>
+
+## Future work: migrating away from sedentary onions
+
+Once all clients are using Walking Onions, we can take a pass
+through the Tor specifications and source code to remove
+no-longer-needed code.
+
+Clients should be the first to lose support for old directories,
+since nobody but the clients depends on the clients having them.
+Only after obsolete clients represent a very small fraction of the
+network should relay or authority support be disabled.
+
+Some fields in router descriptors become obsolete with Walking
+Onions, and possibly router descriptors themselves should be
+replaced with cbor objects of some kind.  This can only happen,
+however, after no descriptor users remain.
+
+<!-- Section A --> <a id='SA'></a>
+
+# Appendices
+
+<!-- Section A.1 --> <a id='SA.1'></a>
+
+## Appendix A: Glossary
+
+I'm going to put a glossary here so I can try to use these terms
+consistently.
+
+*SNIP* -- A "Separable Network Index Proof".  Each SNIP contains the
+information necessary to use a single Tor relay, and associates the relay
+with one or more index ranges. SNIPs are authenticated by the directory
+authorities.
+
+*ENDIVE* -- An "Efficient Network Directory with Individually Verifiable
+Entries".  An ENDIVE is a collection of SNIPS downloaded by relays,
+authenticated by the directory authorities.
+
+*Routing index* -- A routing index is a map from binary strings to relays,
+with some given property.  Each relay that is in the routing index is
+associated with a single *index range*.
+
+*Index range* -- A range of positions withing a routing index.  Each range
+ contains many positions.
+
+*Index position* -- A single value within a routing index.  Every position in
+ a routing index corresponds to a single relay.
+
+*ParamDoc* -- A network parameters document, describing settings for the
+ whole network.  Clients download this infrequently.
+
+*Index group* -- A collection of routing indices that are encoded in the same
+ SNIPs.
+
+<!-- Section A.2 --> <a id='SA.2'></a>
+
+## Appendix B: More cddl definions
+
+    ; These definitions are used throughout the rest of the
+    ; proposal
+
+    ; Ed25519 keys are 32 bytes, and that isn't changing.
+    Ed25519PublicKey = bstr .size 32
+
+    ; Curve25519 keys are 32 bytes, and that isn't changing.
+    Curve25519PublicKey = bstr .size 32
+
+    ; 20 bytes or fewer: legacy RSA SHA1 identity fingerprint.
+    RSAIdentityFingerprint = bstr
+
+    ; A 4-byte integer -- or to be cddl-pedantic, one that is
+    ; between 0 and UINT32_MAX.
+    uint32 = uint .size 4
+
+    ; Enumeration to define integer equivalents for all the digest algorithms
+    ; that Tor uses anywhere.  Note that some of these are not used in
+    ; this spec, but are included so that we can use this production
+    ; whenever we need to refer to a hash function.
+    DigestAlgorithm = &(
+        NoDigest: 0,
+        SHA1    : 1,     ; deprecated.
+        SHA2-256: 2,
+        SHA2-512: 3,
+        SHA3-256: 4,
+        SHA3-512: 5,
+        Kangaroo12-256: 6,
+        Kangaroo12-512: 7,
+    )
+
+    ; A digest is represented as a binary blob.
+    Digest = bstr
+
+    ; Enumeration for different signing algorithms.
+    SigningAlgorithm = &(
+       RSA-OAEP-SHA1  : 1,     ; deprecated.
+       RSA-OAEP-SHA256: 2,     ; deprecated.
+       Ed25519        : 3,
+       Ed448          : 4,
+       BLS            : 5,     ; Not yet standardized.
+    )
+
+    PKAlgorithm = &(
+       SigningAlgorithm,
+
+       Curve25519: 100,
+       Curve448  : 101
+    )
+
+    KeyUsage = &(
+       ; A master unchangeable identity key for this authority.  May be
+       ; any signing key type.  Distinct from the authority's identity as a
+       ; relay.
+       AuthorityIdentity: 0x10,
+       ; A medium-term key used for signing SNIPs, votes, and ENDIVEs.
+       SNIPSigning: 0x11,
+
+       ; These are designed not to collide with the "list of certificate
+       ; types" or "list of key types" in cert-spec.txt
+    )
+
+    CertType = &(
+       VotingCert: 0x12,
+       ; These are designed not to collide with the "list of certificate
+       ; types" in cert-spec.txt.
+    )
+
+    LinkSpecifier = bstr
+
+<!-- Section A.3 --> <a id='SA.3'></a>
+
+## Appendix C: new numbers to assign.
+
+Relay commands:
+
+* We need a new relay command for "FRAGMENT" per proposal 319.
+
+CREATE handshake types:
+
+* We need a type for the NIL handshake.
+
+* We need a handshake type for the new ntor handshake variant.
+
+Link specifiers:
+
+* We need a link specifier for extend-by-index.
+
+* We need a link specifier for dirport URL.
+
+Certificate Types and Key Types:
+
+* We need to add the new entries from CertType and KeyUsage to
+  cert-spec.txt, and possibly merge the two lists.
+
+Begin cells:
+
+* We need a flag for Delegated Verifiable Selection.
+
+* We need an extension type for extra data, and a value for indices.
+
+End cells:
+
+* We need an extension type for extra data, a value for indices, a
+  value for IPv4 addresses, and a value for IPv6 addresses.
+
+Extensions for decrypted INTRODUCE2 cells:
+
+* A SNIP for the rendezvous point.
+
+Onion key types for decrypted INTRODUCE2 cells:
+
+* An "onion key" to indicate that the onion key for the rendezvous point is
+  implicit in the SNIP.
+
+New URLs:
+
+* A URL for fetching ENDIVEs.
+
+* A URL for fetching client / relay parameter documents
+
+* A URL for fetching detached SNIP signatures.
+
+Protocol versions:
+
+(In theory we could omit many new protovers here, since being listed
+in an ENDIVE implies support for the new protocol variants.  We're
+going to use new protovers anyway, however, since doing so keeps our
+numbering consistent.)
+
+We need new versions for these subprotocols:
+
+* _Relay_ to denote support for new handshake elements.
+
+* _DirCache_ to denote support for ENDIVEs, paramdocs, binary diffs, etc.
+
+* _Cons_ to denote support for ENDIVEs
+
+
+<!-- Section A.4 --> <a id='SA.4'></a>
+
+## Appendix D: New network parameters.
+
+We introduce these network parameters:
+
+From section 5:
+
+* `create-pad-len` -- Clients SHOULD pad their CREATE cell bodies
+  to this size.
+
+* `created-pad-len` -- Relays SHOULD pad their CREATED cell bodies to this
+  size.
+
+* `extend-pad-len` -- Clients SHOULD pad their EXTEND cell bodies to this
+  size.
+
+* `extended-pad-len` -- Relays SHOULD pad their EXTENDED cell bodies to this
+size.
+
+From section 7:
+
+* `hsv2-index-bytes` -- how many bytes to use when sending an hsv2 index
+  position to look up a hidden service directory.  Min: 1,
+  Max: 40. Default: 4.
+
+* `hsv3-index-bytes` -- how many bytes to use when sending an hsv3 index
+  position to look up a hidden service directory.  Min: 1,
+  Max: 128. Default: 4.
+
+* `hsv3-intro-legacy-fields` -- include legacy fields in service descriptors.
+  Min: 0. Max: 1. Default: 1.
+
+* `hsv3-intro-snip` -- include intro point SNIPs in service descriptors.
+  Min: 0. Max: 1. Default: 0.
+
+* `hsv3-rend-service-snip` -- Should services advertise and accept rendezvous
+  point SNIPs in INTRODUCE2 cells?    Min: 0. Max: 1. Default: 0.
+
+* `hsv3-rend-client-snip` -- Should clients place rendezvous point SNIPS in
+  INTRODUCE2 cells when the service supports it?
+  Min: 0. Max: 1. Default: 0.
+
+* `hsv3-tolerate-no-legacy` -- Should clients tolerate v3 service descriptors
+  that don't have legacy fields? Min: 0. Max: 1. Default: 0.
+
+From section 8:
+
+* `enforce-endive-dl-delay-after` -- How many seconds after receiving a
+  SNIP with some timestamp T does a client wait for rejecting older SNIPs?
+  Equivalent to "N" in "limiting ENDIVE variance within the network."
+  Min: 0. Max: INT32_MAX. Default: 3600 (1 hour).
+
+* `allow-endive-dl-delay` -- Once a client has received an SNIP with
+  timestamp T, it will not accept any SNIP with timestamp earlier than
+  "allow-endive-dl-delay" seconds before T.
+  Equivalent to "Delta" in "limiting ENDIVE variance within the network."
+  Min: 0. Max: 2592000 (30 days). Default: 10800 (3 hours).
+
+<!-- Section A.5 --> <a id='SA.5'></a>
+
+## Appendix E: Semantic sorting for CBOR values.
+
+Some voting operations assume a partial ordering on CBOR values.  We define
+such an ordering as follows:
+
+  * bstr and tstr items are sorted lexicographically, as if they were
+    compared with a version of strcmp() that accepts internal NULs.
+  * uint and int items are are sorted by integer values.
+  * arrays are sorted lexicographically by elements.
+  * Tagged items are sorted as if they were not tagged.
+  * Maps do not have any sorting order.
+  * False precedes true.
+  * Otherwise, the ordering between two items is not defined.
+
+More specifically:
+
+     Algorithm: compare two cbor items A and B.
+
+     Returns LT, EQ, GT, or NIL.
+
+     While A is tagged, remove the tag from A.
+     While B is tagged, remove the tag from B.
+
+     If A is any integer type, and B is any integer type:
+          return A cmp B
+
+     If the type of A is not the same as the type of B:
+          return NIL.
+
+     If A and B are both booleans:
+          return int(A) cmp int(B), where int(false)=0 and int(B)=1.
+
+     If A and B are both tstr or both bstr:
+          while len(A)>0 and len(B)>0:
+             if A[0] != B[0]:
+                  return A[0] cmp B[0]
+             Discard A[0] and B[0]
+          If len(A) == len(B) == 0:
+             return EQ.
+          else if len(A) == 0:
+             return LT.  (B is longer)
+          else:
+             return GT.  (A is longer)
+
+     If A and B are both arrays:
+          while len(A)>0 and len(B)>0:
+             Run this algorithm recursively on A[0] and B[0].
+             If the result is not EQ:
+                 Return that result.
+             Discard A[0] and B[0]
+          If len(A) == len(B) == 0:
+             return EQ.
+          else if len(A) == 0:
+             return LT.  (B is longer)
+          else:
+             return GT.  (A is longer)
+
+    Otherwise, A and B are a type for which we do not define an ordering,
+    so return NIL.
+
+<!-- Section A.6 --> <a id='SA.6'></a>
+
+## Appendix F: Example voting rules
+
+Here we give a set of voting rules for the fields described in our initial
+VoteDocuments.
+
+    {
+      meta: {
+         voting-delay: { op: "Mode", tie_low:false,
+                           type:["tuple","uint","uint"] },
+         voting-interval: { op: "Median", type:"uint" },
+         snip-lifespan: {op: "Mode", type:["tuple","uint","uint","uint"] },
+         c-param-lifetime: {op: "Mode", type:["tuple","uint","uint","uint"] },
+         s-param-lifetime: {op: "Mode", type:["tuple","uint","uint","uint"] },
+         cur-shared-rand: {op: "Mode", min_count: "qfield",
+                             type:["tuple","uint","bstr"]},
+         prev-shared-rand: {op: "Mode", min_count: "qfield",
+                             type:["tuple","uint","bstr"]},
+      client-params: {
+         recommend-versions: {op:"SetJoin", min_count:"qfield",type:"tstr"},
+         require-protos: {op:"BitThreshold", min_count:"sqauth"},
+         recommend-protos: {op:"BitThreshold", min_count:"qauth"},
+         params: {op:"MapJoin",key_min_count:"qauth",
+                     keytype:"tstr",
+                     item_op:{op:"Median",min_vote:"qauth",type:"uint"},
+                     },
+         certs: {op:"SetJoin",min_count:1, type: 'bstr'},
+      },
+      ; Use same value for server-params.
+      relay: {
+         meta: {
+            desc: {op:"Mode", min_count:"qauth",tie_low:false,
+                   type:["uint","bstr"] },
+            flags: {op:"MapJoin", key_type:"tstr",
+                    item_op:{op:"Mode",type:"bool"}},
+            bw: {op:"Median", type:"uint" },
+            mbw :{op:"Median", type:"uint" },
+            rsa-id: {op:"Mode", type:"bstr"},
+        },
+        snip: {
+           ; ed25519 key is handled as any other value.
+           0: { op:"DerivedFrom", fields:[["RM","desc"]],
+                 rule:{op:"Mode",type="bstr"} },
+
+           ; ntor onion key.
+           1: { op:"DerivedFrom", fields:[["RM","desc"]],
+                 rule:{op:"Mode",type="bstr"} },
+
+           ; link specifiers.
+           2: { op: "CborDerived",
+                 item-op: { op:"DerivedFrom", fields:[["RM","desc"]],
+                            rule:{op:"Mode",type="bstr" } } },
+
+           ; software description.
+           3: { op:"DerivedFrom", fields:[["RM","desc"]],
+                 rule:{op:"Mode",type=["tuple", "tstr", "tstr"] } },
+
+           ; protovers.
+           4: { op: "CborDerived",
+                 item-op: { op:"DerivedFrom", fields:[["RM","desc"]],
+                          rule:{op:"Mode",type="bstr" } } },
+
+           ; families.
+           5: { op:"SetJoin", min_count:"qfield", type:"bstr" },
+
+           ; countrycode
+           6: { op:"Mode", type="tstr" } ,
+
+           ; 7: exitpolicy.
+           7: { op: "CborDerived",
+                 item-op: { op: "DerivedFrom", fields:[["RM","desc"],["CP","port-classes"]],
+                          rule:{op:"Mode",type="bstr" } } },
+        },
+        legacy: {
+          "sha1-desc": { op:"DerivedFrom",
+                          fields:[["RM","desc"]],
+                          rule:{op:"Mode",type="bstr"} },
+          "mds": { op:"DerivedFrom",
+                    fields:[["RM":"desc"]],
+                    rule: { op:"ThresholdOp", min_count: "qauth",
+                             multi_low:false,
+                             type:["tuple", "uint", "uint",
+                                   "bstr", "bstr" ] }},
+        }
+      }
+      indices: {
+         ; See appendix G.
+      }
+    }
+
+<!-- Section A.7 --> <a id='SA.7'></a>
+
+## Appendix G: A list of routing indices
+
+Middle -- general purpose index for use when picking middle hops in
+circuits.  Bandwidth-weighted for use as middle relays.  May exclude
+guards and/or exits depending on overall balance of resources on the
+network.
+
+Formula:
+      type: 'weighted',
+      source: {
+          type:'bw', require_flags: ['Valid'], 'bwfield' : ["RM", "mbw"]
+      },
+      weight: {
+          [ "!Exit", "!Guard" ] => "Wmm",
+          [ "Exit", "Guard" ] => "Wbm",
+          [ "Exit", "!Guard" ] => "Wem",
+          [ "!Exit", "Guard" ] => "Wgm",
+      }
+
+Guard -- index for choosing guard relays. This index is not used
+directly when extending, but instead only for _picking_ guard relays
+that the client will later connect to directly.  Bandwidth-weighted
+for use as guard relays. May exclude guard+exit relays depending on
+resource balance.
+
+      type: 'weighted',
+      source: {
+           type:'bw',
+           require_flags: ['Valid', "Guard"],
+           bwfield : ["RM", "mbw"]
+      },
+      weight: {
+          [ "Exit", ] => "Weg",
+      }
+
+HSDirV2 -- index for finding spots on the hsv2 directory ring.
+
+Formula:
+      type: 'rsa-id',
+
+HSDirV3-early -- index for finding spots on the hsv3 directory ring
+for the earlier of the two "active" days. (The active days are
+today, and whichever other day is closest to the time at which the
+ENDIVE becomes active.)
+
+Formula:
+      type: 'ed-id'
+      alg: SHA3-256,
+      prefix: b"node-idx",
+      suffix: (depends on shared-random and time period)
+
+HSDirV3-late -- index for finding spots on the hsv3 directory ring
+for the later of the two "active" days.
+
+Formula: as HSDirV3-early, but with a different suffix.
+
+Self -- A virtual index that never appears in an ENDIVE.  SNIPs with
+this index are unsigned, and occupy the entire index range.  This
+index is used with bridges to represent each bridge's uniqueness.
+
+Formula: none.
+
+Exit0..ExitNNN -- Exits that can connect to all ports within a given
+PortClass 0 through NNN.
+
+Formula:
+
+      type: 'weighted',
+      source: {
+           type:'bw',
+           ; The second flag here depends on which portclass this is.
+           require_flags: [ 'Valid', "P@3" ],
+           bwfield : ["RM", "mbw"]
+       },
+      weight: {
+          [ "Guard", ] => "Wge",
+      }
+
+<!-- Section A.8 --> <a id='SA.8'></a>
+
+## Appendix H: Choosing good clusters of exit policies
+
+With Walking Onions, we cannot easily support all the port
+combinations [*] that we currently allow in the "policy summaries"
+that we support in microdescriptors.
+
+> [*] How many "short policy summaries" are there? The number would be
+> 2^65535, except for the fact today's Tor doesn't permit exit policies to
+> get maximally long.
+
+In the Walking Onions whitepaper
+(https://crysp.uwaterloo.ca/software/walkingonions/) we noted in
+section 6 that we can group exit policies by class, and get down to
+around 220 "classes" of port, such that each class was either
+completely supported or completely unsupported by every relay.  But
+that number is still impractically large: if we need ~11 bytes to
+represent a SNIP index range, we would need an extra 2320 bytes per
+SNIP, which seems like more overhead than we really want.
+
+We can reduce the number of port classes further, at the cost of
+some fidelity.  For example, suppose that the set {https,http} is
+supported by relays {A,B,C,D}, and that the set {ssh,irc} is
+supported by relays {B,C,D,E}.  We could combine them into a new
+port class {https,http,ssh,irc}, supported by relays {B,C,D} -- at
+the expense of no longer being able to say that relay A supported
+{https,http}, or that relay E supported {ssh,irc}.
+
+This loss would not necessarily be permanent: the operator of relay
+A might be willing to add support for {ssh,irc}, and the operator of
+relay E might be willing to add support for {https,http}, in order
+to become useful as an exit again.
+
+(We might also choose to add a configuration option for relays to
+take their exit policies directly from the port classes in the
+consensus.)
+
+How might we select our port classes?  Three general categories of
+approach seem possible: top-down, bottom-up, and hybrid.
+
+In a top-down approach, we would collaborate with authority and exit
+operators to identify _a priori_ reasonable classes of ports, such
+as "Web", "Chat", "Miscellaneous internet", "SMTP", and "Everything
+else".  Authorities would then base exit indices on these classes.
+
+In a bottom-up approach, we would find an algorithm to run on the
+current exit policies in order to find the "best" set of port
+classes to capture the policies as they stand with minimal loss.
+(Quantifying this loss is nontrivial: do we weight by bandwidth? Do
+we weight every port equally, or do we call some more "important"
+than others?)
+
+> See exit-analysis for an example tool that runs a greedy algorithm
+> to find a "good" partition using an unweighted,
+> all-ports-are-equal cost function.  See the files
+> "greedy-set-cov-{4,8,16}" for examples of port classes produced
+> by this algorithm.
+
+In a hybrid approach, we'd use top-down and bottom-up techniques
+together. For example, we could start with an automated bottom-up
+approach, and then evaluate it based feedback from operators.  Or we
+could start with a handcrafted top-down approach, and then use
+bottom-up cost metrics to look for ways to split or combine those
+port classes in order to represent existing policies with better
+fidelity.
+
+
+<!-- Section A.9 --> <a id='SA.9'></a>
+
+## Appendix I: Non-clique topologies with Walking Onions
+
+For future work, we can expand the Walking Onions design to
+accommodate network topologies where relays are divided into groups,
+and not every group connects to every other.  To do so requires
+additional design work, but here I'll provide what I hope will be a
+workable sketch.
+
+First, each SNIP needs to contain an ID saying which relay group it
+belongs to, and an ID saying which relay group(s) may serve it.
+
+When downloading an ENDIVE, each relay should report its own
+identity, and receive an ENDIVE for that identity's group.  It
+should contain both the identities of relays in the group, and the
+SNIPs that should be served for different indices by members of that
+group.
+
+The easy part would be to add an optional group identity field to
+SNIPs, defaulting to 0, indicating that the relay belongs to that
+group, and an optional served-by field to each SNIP, indicating
+groups that may serve the SNIP.  You'd only accept SNIPs if they
+were served by a relay in a group that was allowed to serve them.
+
+Would guards work?  Sure: we'd need to have guard SNIPS served by
+middle relays.
+
+For hsdirs, we'd need to have either multiple shards of the hsdir
+ring (which seems like a bad idea?) or have all middle nodes able to
+reach the hsdir ring.
+
+Things would get tricky with making onion services work: if you need
+to use an introduction point or a rendezvous point in group X, then
+you need to get there from a relay that allows connections to group
+X.  Does this imply indices meaning "Can reach group X" or
+"two-degrees of group X"?
+
+The question becomes: "how much work on alternative topologies does
+it make sense to deploy in advance?"  It seems like there are
+unknowns affecting both client and relay operations here, which
+suggests that advance deployment for either case is premature: we
+can't necessarily make either clients or relays "do the right thing"
+in advance given what we now know of the right thing.
+
+<!-- Section A.10 --> <a id='SA.10'></a>
+
+## Appendix Z: acknowledgments
+
+Thanks to Peter Palfrader for his original design in proposal 141,
+and to the designers of PIR-Tor, both of which inspired aspects of
+this Walking Onions design.
+
+Thanks to Chelsea Komlo, Sajin Sasy, and Ian Goldberg for feedback on
+an earlier version of this design.
+
+Thanks to David Goulet, Teor, and George Kadianakis for commentary on
+earlier versions of proposal 300.
+
+Thanks to Chelsea Komlo and Ian Goldberg for their help fleshing out
+so many ideas related to Walking Onions in their work on the design
+paper.
+
+Thanks to Teor for improvements to diff format, ideas about grouping
+exit ports, and numerous ideas about getting topology and
+distribution right.
+
+These specifications were supported by a grant from the Zcash
+Foundation.
+