convert text blocks into widely compatible "blockquote" syntax

This only adds newline characters to make the existing text blocks act like
"blockquote" or "code block" syntax in Markdown, asciidoc, and others.
This was accomplished by manually reviewing the output of this script:

```bash
for f in *.txt; do
  cat $f | python -c "import sys,re;print(re.sub(r'(\n {0,3}[^ \n][^\n]*\n)( {4,}[^\n]*)', r'\1\n\2', sys.stdin.read()))" > ${f}.tmp
  mv ${f}.tmp $f
done
```

1 files changed, 51 insertions, 0 deletions

diff --git a/tor-spec.txt b/tor-spec.txt
index 552a453..6881436 100644
--- a/tor-spec.txt
+++ b/tor-spec.txt
@@ -226,6 +226,7 @@ see tor-design.pdf.
    certificate containing its identity key.  The other party sends a similar
    certificate chain.  The initiator's ClientHello MUST NOT include any
    ciphersuites other than:
+
      TLS_DHE_RSA_WITH_AES_256_CBC_SHA
      TLS_DHE_RSA_WITH_AES_128_CBC_SHA
      SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
@@ -248,12 +249,14 @@ see tor-design.pdf.
    which the initiator can use to learn that the in-protocol handshake
    is in use.  Specifically, at least one of these properties must be
    true of the certificate:
+
       * The certificate is self-signed
       * Some component other than "commonName" is set in the subject or
         issuer DN of the certificate.
       * The commonName of the subject or issuer of the certificate ends
         with a suffix other than ".net".
       * The certificate's public key modulus is longer than 1024 bits.
+
    The initiator then sends a VERSIONS cell to the responder, which then
    replies with a VERSIONS cell; they have then negotiated a Tor
    protocol version.  Assuming that the version they negotiate is 3 or higher
@@ -355,6 +358,7 @@ see tor-design.pdf.
    cipher is one not supported by OpenSSL 1.0.1.
 
    The fixed ciphersuite list is:
+
      TLS1_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
      TLS1_ECDHE_RSA_WITH_AES_256_CBC_SHA
      TLS1_DHE_RSA_WITH_AES_256_SHA
@@ -450,6 +454,7 @@ see tor-design.pdf.
 
    The 'Command' field of a fixed-length cell holds one of the following
    values:
+
          0 -- PADDING     (Padding)                 (See Sec 7.2)
          1 -- CREATE      (Create a circuit)        (See Sec 5.1)
          2 -- CREATED     (Acknowledge create)      (See Sec 5.1)
@@ -464,6 +469,7 @@ see tor-design.pdf.
          12 -- PADDING_NEGOTIATE   (Padding negotiation)    (See Sec 7.2)
 
     Variable-length command values are:
+
          7 -- VERSIONS    (Negotiate proto version) (See Sec 4)
          128 -- VPADDING  (Variable-length padding) (See Sec 7.2)
          129 -- CERTS     (Certificates)            (See Sec 4.2)
@@ -472,6 +478,7 @@ see tor-design.pdf.
          132 -- AUTHORIZE (Client authorization)    (Not yet used)
 
    The interpretation of 'Payload' depends on the type of the cell.
+
       VPADDING/PADDING:
                Payload contains padding bytes.
       CREATE/CREATE2:  Payload contains the handshake challenge.
@@ -479,6 +486,7 @@ see tor-design.pdf.
       RELAY/RELAY_EARLY: Payload contains the relay header and relay body.
       DESTROY: Payload contains a reason for closing the circuit.
                (see 5.4)
+
    Upon receiving any other value for the command field, an OR must
    drop the cell.  Since more cell types may be added in the future, ORs
    should generally not warn when encountering unrecognized commands.
@@ -486,6 +494,7 @@ see tor-design.pdf.
    The cell is padded up to the cell length with padding bytes.
 
    Senders set padding bytes depending on the cell's command:
+
       VERSIONS:  Payload MUST NOT contain padding bytes.
       AUTHORIZE: Payload is unspecified and reserved for future use.
       Other variable-length cells:
@@ -496,6 +505,7 @@ see tor-design.pdf.
       Other fixed-length cells:
                  Payload MUST be padded to PAYLOAD_LEN with padding bytes.
                  Padding bytes SHOULD be set to NUL.
+
    We recommend random padding in RELAY/RELAY_EARLY cells, so that the cell
    content is unpredictable. See proposal 289 for details. For other
    cells, TLS authenticates cell content, so randomised padding bytes are
@@ -594,6 +604,7 @@ see tor-design.pdf.
    list at least version 3.
 
    Link protocols differences are:
+
      1 -- The "certs up front" handshake.
      2 -- Uses the renegotiation-based handshake. Introduces
           variable-length cells.
@@ -633,6 +644,7 @@ see tor-design.pdf.
 
    To authenticate the responder as having a given Ed25519,RSA identity key
    combination, the initiator MUST check the following.
+
      * The CERTS cell contains exactly one CertType 2 "ID" certificate.
      * The CERTS cell contains exactly one CertType 4 Ed25519
        "Id->Signing" cert.
@@ -658,6 +670,7 @@ see tor-design.pdf.
 
    To authenticate the responder as having a given RSA identity only,
    the initiator MUST check the following:
+
      * The CERTS cell contains exactly one CertType 1 "Link" certificate.
      * The CERTS cell contains exactly one CertType 2 "ID" certificate.
      * Both certificates have validAfter and validUntil dates that
@@ -678,6 +691,7 @@ see tor-design.pdf.
 
    To authenticate the initiator as having a given Ed25519,RSA
    identity key combination, the responder MUST check the following:
+
      * The CERTS cell contains exactly one CertType 2 "ID" certificate.
      * The CERTS cell contains exactly one CertType 4 Ed25519
        "Id->Signing" certificate.
@@ -701,6 +715,7 @@ see tor-design.pdf.
 
    To authenticate the initiator as having an RSA identity key only,
    the responder MUST check the following:
+
      * The CERTS cell contains exactly one CertType 3 "AUTH" certificate.
      * The CERTS cell contains exactly one CertType 2 "ID" certificate.
      * Both certificates have validAfter and validUntil dates that
@@ -712,6 +727,7 @@ see tor-design.pdf.
      * The auth certificate is correctly signed with the key in the
        ID certificate.
      * The ID certificate is correctly self-signed.
+
    Checking these conditions is NOT sufficient to authenticate that the
    initiator has the ID it claims; to do so, the cells in 4.3 and 4.4
    below must be exchanged.
@@ -721,6 +737,7 @@ see tor-design.pdf.
 
    An AUTH_CHALLENGE cell is a variable-length cell with the following
    fields:
+
        Challenge [32 octets]
        N_Methods [2 octets]
        Methods   [2 * N_Methods octets]
@@ -864,6 +881,7 @@ see tor-design.pdf.
           AVAL    (Address value in NBO))        [ALEN bytes]
 
    Recognized address types (ATYPE) are:
+
      [04] IPv4.
      [06] IPv6.
 
@@ -903,23 +921,29 @@ see tor-design.pdf.
    newer format is extensible by design; the older one is not.
 
    A CREATE2 cell contains:
+
        HTYPE     (Client Handshake Type)     [2 bytes]
        HLEN      (Client Handshake Data Len) [2 bytes]
        HDATA     (Client Handshake Data)     [HLEN bytes]
 
    A CREATED2 cell contains:
+
        HLEN      (Server Handshake Data Len) [2 bytes]
        HDATA     (Server Handshake Data)     [HLEN bytes]
 
    Recognized handshake types are:
+
        0x0000  TAP  -- the original Tor handshake; see 5.1.3
        0x0001  reserved
        0x0002  ntor -- the ntor+curve25519+sha256 handshake; see 5.1.4
 
 
    The format of a CREATE cell is one of the following:
+
        HDATA     (Client Handshake Data)     [TAP_C_HANDSHAKE_LEN bytes]
+
    or
+
        HTAG      (Client Handshake Type Tag) [16 bytes]
        HDATA     (Client Handshake Data)     [TAP_C_HANDSHAKE_LEN-16 bytes]
 
@@ -931,7 +955,9 @@ see tor-design.pdf.
        ntor -- 'ntorNTORntorNTOR'
 
    The format of a CREATED cell is:
+
        HDATA     (Server Handshake Data)     [TAP_S_HANDSHAKE_LEN bytes]
+
    (It's equivalent to a CREATED2 cell with length of TAP_S_HANDSHAKE_LEN.)
 
    As usual with DH, x and y MUST be generated randomly.
@@ -979,6 +1005,7 @@ see tor-design.pdf.
    relay cell to the last node in the circuit.
 
    An EXTEND2 cell's relay payload contains:
+
        NSPEC      (Number of link specifiers)     [1 byte]
          NSPEC times:
            LSTYPE (Link specifier type)           [1 byte]
@@ -990,6 +1017,7 @@ see tor-design.pdf.
 
    Link specifiers describe the next node in the circuit and how to
    connect to it. Recognized specifiers are:
+
       [00] TLS-over-TCP, IPv4 address
            A four-byte IPv4 address plus two-byte ORPort
       [01] TLS-over-TCP, IPv6 address
@@ -1004,6 +1032,7 @@ see tor-design.pdf.
    instances of specifiers other than 'legacy identity'.
 
    The relay payload for an EXTEND relay cell consists of:
+
          Address                       [4 bytes]
          Port                          [2 bytes]
          Onion skin                    [TAP_C_HANDSHAKE_LEN bytes]
@@ -1080,6 +1109,7 @@ see tor-design.pdf.
 
    The payload for a CREATED cell, or the relay payload for an
    EXTENDED cell, contains:
+
          DH data (g^y)                 [DH_LEN bytes]
          Derivative key data (KH)      [HASH_LEN bytes]   <see 5.2 below>
 
@@ -1112,6 +1142,7 @@ see tor-design.pdf.
    [The ntor handshake was added in Tor 0.2.4.8-alpha.]
 
    In this section, define:
+
       H(x,t) as HMAC_SHA256 with message x and key t.
       H_LENGTH  = 32.
       ID_LENGTH = 20.
@@ -1132,8 +1163,11 @@ see tor-design.pdf.
    digest for the server, and an ntor onion key (a curve25519 public
    key) for that server. Call the ntor onion key "B".  The client
    generates a temporary keypair:
+
        x,X = KEYGEN()
+
    and generates a client-side handshake with contents:
+
        NODEID      Server identity digest  [ID_LENGTH bytes]
        KEYID       KEYID(B)                [H_LENGTH bytes]
        CLIENT_PK   X                       [G_LENGTH bytes]
@@ -1147,6 +1181,7 @@ see tor-design.pdf.
      auth_input = verify | ID | B | Y | X | PROTOID | "Server"
 
    The server's handshake reply is:
+
        SERVER_PK   Y                       [G_LENGTH bytes]
        AUTH        H(auth_input, t_mac)    [H_LENGTH bytes]
 
@@ -1214,6 +1249,7 @@ see tor-design.pdf.
 
    From the base key material K0, they compute KEY_LEN*2+HASH_LEN*3 bytes of
    derivative key data as
+
        K = H(K0 | [00]) | H(K0 | [01]) | H(K0 | [02]) | ...
 
    The first HASH_LEN bytes of K form KH; the next HASH_LEN form the forward
@@ -1333,6 +1369,7 @@ see tor-design.pdf.
    To prevent this, when an OR gets an extend request, it SHOULD use an
    existing OR connection if the ID matches, and ANY of the following
    conditions hold:
+
        - The IP matches the requested IP.
        - The OR knows that the IP of the connection it's using is canonical
          because it was listed in the NETINFO cell.
@@ -1346,12 +1383,14 @@ see tor-design.pdf.
    circuit's intended lifetime is over.
 
    ORs SHOULD also tear down circuits which attempt to create:
+
    * streams with RELAY_BEGIN, or
    * rendezvous points with ESTABLISH_RENDEZVOUS,
    ending at the first hop. Letting Tor be used as a single hop proxy makes
    exit and rendezvous nodes a more attractive target for compromise.
 
    ORs MAY use multiple methods to check if they are the first hop:
+
    * If an OR sees a circuit created with CREATE_FAST, the OR is sure to be
      the first hop of a circuit.
    * If an OR is the responder, and the initiator:
@@ -1401,6 +1440,7 @@ see tor-design.pdf.
    this error code to 0, to avoid leaking its version.
 
    The error codes are:
+
      0 -- NONE            (No reason given.)
      1 -- PROTOCOL        (Tor protocol violation.)
      2 -- INTERNAL        (Internal error.)
@@ -1438,6 +1478,7 @@ see tor-design.pdf.
 
    When a relay cell is sent from an OP, the OP encrypts the payload
    with the stream cipher as follows:
+
       OP sends relay cell:
          For I=N...1, where N is the destination node:
             Encrypt with Kf_I.
@@ -1447,6 +1488,7 @@ see tor-design.pdf.
 
    When a forward relay cell is received by an OR, it decrypts the payload
    with the stream cipher, as follows:
+
       'Forward' relay cell:
          Use Kf as key; decrypt.
 
@@ -1469,6 +1511,7 @@ see tor-design.pdf.
 
    When a backward relay cell is received by an OR, it encrypts the payload
    with the stream cipher, as follows:
+
       'Backward' relay cell:
          Use Kb as key; encrypt.
 
@@ -1476,6 +1519,7 @@ see tor-design.pdf.
 
    When a relay cell arrives at an OP, the OP decrypts the payload
    with the stream cipher as follows:
+
          OP receives relay cell from node 1:
             For I=1...N, where N is the final node on the circuit:
                 Decrypt with Kb_I.
@@ -1517,6 +1561,7 @@ see tor-design.pdf.
    * onion services (RELAY_BEGIN, anonymous via a rendezvous point).
 
    The payload of each unencrypted RELAY cell consists of:
+
          Relay command           [1 byte]
          'Recognized'            [2 bytes]
          StreamID                [2 bytes]
@@ -1525,6 +1570,7 @@ see tor-design.pdf.
          Data                    [PAYLOAD_LEN-11 bytes]
 
    The relay commands are:
+
          1 -- RELAY_BEGIN     [forward]
          2 -- RELAY_DATA      [forward or backward]
          3 -- RELAY_END       [forward or backward]
@@ -1633,9 +1679,12 @@ see tor-design.pdf.
    exit node replies with a RELAY_END cell.  (See 6.4 below.)
    Otherwise, the exit node replies with a RELAY_CONNECTED cell, whose
    payload is in one of the following formats:
+
        The IPv4 address to which the connection was made [4 octets]
        A number of seconds (TTL) for which the address may be cached [4 octets]
+
     or
+
        Four zero-valued octets [4 octets]
        An address type (6)     [1 octet]
        The IPv6 address to which the connection was made [16 octets]
@@ -1783,6 +1832,7 @@ see tor-design.pdf.
        TTL    (4 octets)
    "Length" is the length of the Value field.
    "Type" is one of:
+
       0x00 -- Hostname
       0x04 -- IPv4 address
       0x06 -- IPv6 address
@@ -1842,6 +1892,7 @@ see tor-design.pdf.
    enabled as per padding-spec.txt. On these connections, clients may
    negotiate the use of padding with a CELL_PADDING_NEGOTIATE command
    whose format is as follows:
+
          Version           [1 byte]
          Command           [1 byte]
          ito_low_ms        [2 bytes]