diff options
Diffstat (limited to 'proposals/323-walking-onions-full.md')
| -rw-r--r-- | proposals/323-walking-onions-full.md | 39 |
1 files changed, 22 insertions, 17 deletions
diff --git a/proposals/323-walking-onions-full.md b/proposals/323-walking-onions-full.md index 86d57b2..192ae48 100644 --- a/proposals/323-walking-onions-full.md +++ b/proposals/323-walking-onions-full.md @@ -1572,9 +1572,9 @@ 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. +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> @@ -1681,7 +1681,7 @@ 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 +`[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.) @@ -1827,10 +1827,12 @@ computed so far), and on the entirety of the set of votes. > our current behavior. Parameters: + `FIELDS` (one or more other locations in the vote) `RULE` (the rule used to combine values) -Encoding +Encoding: + ; This item is "derived from" some other field. DerivedItemOp = { op: "DerivedFrom", @@ -2646,7 +2648,7 @@ 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 +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> @@ -2839,6 +2841,7 @@ The CREATE2, CREATED2, and EXTENDED2 cells change as follows: These extensions are defined by this proposal: +```text [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, @@ -2861,6 +2864,7 @@ These extensions are defined by this proposal: 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 @@ -2923,14 +2927,14 @@ following main changes. So the client's message is now: - CLIENT_PK [32 bytes] + CLIENT_PK [32 bytes] And the relay's reply is now: - NODEID [32 bytes] - KEYID [32 bytes] - SERVER_PK [32 bytes] - AUTH [32 bytes] + NODEID [32 bytes] + KEYID [32 bytes] + SERVER_PK [32 bytes] + AUTH [32 bytes] otherwise, all fields are computed as described in tor-spec. @@ -3330,10 +3334,10 @@ relay cells.) > 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 +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 +> \[\*\] 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 @@ -3445,10 +3449,10 @@ between updating ENDIVEs under ideal circumstances. # 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 +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. +> \[\*\] 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. @@ -3903,6 +3907,7 @@ 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"] @@ -3978,10 +3983,10 @@ Formula: ## 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" +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 +> \[\*\] 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. |