add new truncated origin signed fields to messages

1 files changed, 139 insertions, 75 deletions

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 641397c..c662e87 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -133,7 +133,7 @@
         permissionless participation and support for
         topologies in restricted-route environments.  R<sup>5</sup>N also
         includes advanced features like tracing paths messages take through the
-        network, response filters and on-path application-specific data validation. 
+        network, response filters and on-path application-specific data validation.
       </t>
       <t>
         This document defines the normative wire format of peer-to-peer
@@ -195,7 +195,7 @@
           a peer in the underlay.
          The Peer ID is the public key of the corresponding
          Ed25519<xref target="ed25519" /> peer private key.
-          
+
         </dd>
         <dt>Peer Address:</dt>
         <dd>
@@ -619,7 +619,7 @@ Connectivity | |Underlay|  |Underlay|
       <t>
         These signals then drive updates of the routing table, local storage
         and message transmission.
-      </t>      
+      </t>
     </section>
     <section anchor="bootstrapping">
       <name>Bootstrapping</name>
@@ -630,7 +630,7 @@ Connectivity | |Underlay|  |Underlay|
         least one working HELLO to the DHT for bootstrapping.
         While details on how the first connection is established <bcp14>MAY</bcp14>
         depend on the specific implementation, this <bcp14>SHOULD</bcp14> usually be done
-        by an out-of-band exchange of the information from a HELLO block. 
+        by an out-of-band exchange of the information from a HELLO block.
         For this, section <xref target="hello_url"/> specifies a URL format for encoding HELLO
         blocks as text strings which <bcp14>SHOULD</bcp14> be supported by implementations.
       </t>
@@ -654,20 +654,20 @@ Connectivity | |Underlay|  |Underlay|
       </t>
       <t>
         The frequency of advertisement and peer discovery messages
-        <bcp14>MAY</bcp14> be adapted according to network conditions, 
+        <bcp14>MAY</bcp14> be adapted according to network conditions,
         the set of already connected neighbors,
         the workload of the system and other factors which are at the discretion of
         the developer.
       </t>
       <t>
-        Any implementation encountering a HELLO GET request <bcp14>MUST</bcp14> respond 
+        Any implementation encountering a HELLO GET request <bcp14>MUST</bcp14> respond
         with its own HELLO block except if that block is
-        filtered by the request's result filter (see <xref target="result_filter"/>).  
-        Implementations <bcp14>MAY</bcp14> respond 
+        filtered by the request's result filter (see <xref target="result_filter"/>).
+        Implementations <bcp14>MAY</bcp14> respond
         with additional valid HELLO blocks of other peers with keys
         closest to the key of the GET request.  A HELLO block is "valid"
         if it is non-expired and
-        is not excluded by the result filter.  "closest" is defined 
+        is not excluded by the result filter.  "closest" is defined
         by considering the distances between the request's key and the
         peer addresses of all of the valid HELLO blocks known at the local node.
       </t>
@@ -678,7 +678,7 @@ Connectivity | |Underlay|  |Underlay|
           as the scheme, followed by "hello/" for the name
           of the GNUnet subsystem, followed by "/"-separated values
           with the GNS
-          Base32 encoding (FIXME: described here or reference GNS draft?) of 
+          Base32 encoding (FIXME: described here or reference GNS draft?) of
           the <tt>Peer ID</tt>, a Base32-encoded EdDSA signature, and an expiration
           time in seconds since the UNIX Epoch in decimal format.
           After this a "?" begins a list of key-value pairs where the key
@@ -700,7 +700,7 @@ ZFK0G9BWETY3CCE2QWGVT4WA7JN5M9HMWG\
 FIXME: signature is invalid, should
 maybe generate proper test vector.
 ]]>
-        </artwork> 
+        </artwork>
         </figure>
         <t>
           It specifies that the peer with the ID "RH1M...6Y3G"
@@ -728,7 +728,7 @@ addr-name = scheme
 addr-value = *pchar
 bchar = *(ALPHA / DIGIT)
 ]]>
-        </artwork> 
+        </artwork>
         </figure>
         <t>
          'scheme' is defined in <xref target="RFC3986" /> in Section 3.1.
@@ -787,10 +787,10 @@ bchar = *(ALPHA / DIGIT)
         follows an XOR-based peer distance calculation.
       </t>
       <t>
-        To enable routing, any R<sup>5</sup>N implementation must keep 
+        To enable routing, any R<sup>5</sup>N implementation must keep
         information about its current set of neighbors.
         Upon receiving a connection notification from the Underlay through
-        <tt>PEER_CONNECTED</tt>, information on the new neighbor 
+        <tt>PEER_CONNECTED</tt>, information on the new neighbor
         <bcp14>MUST</bcp14> be added, and similarly when
         a disconnect is indicated by the Underlay through
         <tt>PEER_DISCONNECTED</tt> the peer <bcp14>MUST</bcp14> be removed.
@@ -826,7 +826,7 @@ bchar = *(ALPHA / DIGIT)
           signalling to indicate that they are merely a client utilizing a
           DHT and not able to participate in routing.  DHT peers receiving
           such connections <bcp14>MUST NOT</bcp14> include connections to
-          such restricted systems in their k-buckets, thereby effectively 
+          such restricted systems in their k-buckets, thereby effectively
           excluding them when making routing decisions.
         </t>
         <t>
@@ -843,7 +843,7 @@ bchar = *(ALPHA / DIGIT)
           To build its routing table, a peer will send out requests
           asking for blocks of type HELLO using its own location as the key,
           but filtering all of its neighbors via the Bloom filter described
-          in <xref target="result_filter"/>. 
+          in <xref target="result_filter"/>.
           These requests <bcp14>MUST</bcp14> use the FindApproximate and DemultiplexEverywhere
           flags. FindApproximate will ensure that other peers will reply
           with keys they merely consider close-enough, while DemultiplexEverywhere
@@ -885,7 +885,7 @@ bchar = *(ALPHA / DIGIT)
         <t>
           The peer Bloom filter is always a 128 byte field. The elements
           hashed into the Bloom filter are the 32 byte peer IDs.  We note
-          that the peer Bloom filter may exclude peers due to false-postive 
+          that the peer Bloom filter may exclude peers due to false-postive
           matches.  This is acceptable as routing should nevertheless
           terminate (with high probability) in close vicinity of the key.
         </t>
@@ -893,9 +893,9 @@ bchar = *(ALPHA / DIGIT)
       <section anchor="routing_functions">
         <name>Routing Functions</name>
          <t>
-           Using the data structures described so far, 
-           the R<sup>5</sup>N routing component provides 
-           the following functions for 
+           Using the data structures described so far,
+           the R<sup>5</sup>N routing component provides
+           the following functions for
            message processing (<xref target="p2p_messages"/>):
         </t>
         <dl>
@@ -915,16 +915,16 @@ bchar = *(ALPHA / DIGIT)
             routing table with the shortest XOR-distance to the key <tt>K</tt>.
             This means that for all other peers <tt>N'</tt> in the routing table
             <tt>GetDistance(N, K) &lt; GetDistance(N',K)</tt>.
-            Peers with a positive test against the peer Bloom 
+            Peers with a positive test against the peer Bloom
             filter <tt>B</tt> are not considered.
           </dd>
           <dt>
             <tt>SelectRandompeer(B) -&gt; N</tt>
           </dt>
           <dd>
-            This function selects a random peer <tt>N</tt> from 
+            This function selects a random peer <tt>N</tt> from
             all neighbors.
-            Peers with a positive test in the peer Bloom 
+            Peers with a positive test in the peer Bloom
             filter <tt>B</tt> are not considered.
           </dd>
           <dt>
@@ -974,7 +974,7 @@ BEGIN
   if (REPL_LEVEL > 16)
     REPL_LEVEL = 16
   RM1 = REPL_LEVEL - 1
-  return 1 + (RM1 / (L2NSE + RM1 * HOPCOUNT))  
+  return 1 + (RM1 / (L2NSE + RM1 * HOPCOUNT))
 ]]></artwork>
             </figure>
             <t>
@@ -1030,7 +1030,7 @@ BEGIN
           track requests from local applications separately and
           preserve the information until the application explicitly
           stops the request.
-        </t>     
+        </t>
       </section>
     </section>
     <section anchor="p2p_messages" numbered="true" toc="default">
@@ -1070,13 +1070,20 @@ BEGIN
           <dt>1: RecordRoute</dt>
           <dd>
             This bit indicates to keep track of the path that the message takes
-            in the P2P network. 
+            in the P2P network.
           </dd>
           <dt>2: FindApproximate</dt>
           <dd>
             This bit allows results where the key does not match exactly.
           </dd>
-          <dt>3-15: Reserved</dt>
+          <dt>3: Truncated</dt>
+          <dd>
+            This is a special flag which is set if a peer truncated the path
+            and thus the first hop on the path is given without a signature
+            to enable checking of the next signature. MUST never be set in
+            a query.
+          </dd>
+          <dt>4-15: Reserved</dt>
           <dd>
             The remaining bits are reserved for future use and
             <bcp14>MUST</bcp14> be set to 0 when initiating an operation.
@@ -1101,7 +1108,7 @@ BEGIN
         <t>
           The public key of the peer which created the signature is in the
           next path element, or is the sender of the message if this was the
-          last path element. 
+          last path element.
           The wire format of a Path Element is illustrated in
           <xref target="figure_pathelement"/>.
         </t>
@@ -1141,7 +1148,7 @@ BEGIN
           The SIGNATURE covers a 64-bit contextualization header, the
           the block expiration, a hash of the block
           payload, as well as the predecessor peer ID and the peer ID of the
-          successor that the peer making the signature is routing the 
+          successor that the peer making the signature is routing the
           message to.  Thus, the signature made by SELF basically says that
           SELF received the block payload from PEER PREDECESSOR and has forwarded
           it to PEER SUCCESSOR.  The wire format is illustrated
@@ -1212,7 +1219,7 @@ BEGIN
       <section anchor="p2p_hello" numbered="true" toc="default">
         <name>HelloMessage</name>
         <t>
-          <tt>HelloMessage</tt>s are used to inform neighbors of 
+          <tt>HelloMessage</tt>s are used to inform neighbors of
           a peer about the sender's available addresses. The
           recipients use these messages to inform their respective
           Underlays about ways to sustain the connections and to
@@ -1221,11 +1228,11 @@ BEGIN
           from other peers. In contrast to a HELLO block, a
           <tt>HelloMessage</tt> does not contain the ID of
           the peer the address information is about: in a
-          <tt>HelloMessage</tt>, the address information is always 
+          <tt>HelloMessage</tt>, the address information is always
           about the sender. Since
           the Underlay is responsible to determine the
           peer ID of the sender for all messages, it would thus be
-          redundant to also include the peer ID in the 
+          redundant to also include the peer ID in the
           <tt>HelloMessage</tt>.
         </t>
         <section anchor="p2p_hello_wire">
@@ -1340,8 +1347,12 @@ BEGIN
 |                  BLOCK_KEY                    /
 /                 (64 byte)                     |
 +-----+-----+-----+-----+-----+-----+-----+-----+
+/       TRUNCATED ORIGIN (0 or 32 bytes)        /
++-----+-----+-----+-----+-----+-----+-----+-----+
 /              PUTPATH (variable length)        /
 +-----+-----+-----+-----+-----+-----+-----+-----+
+/      LAST HOP SIGNATURE (0 or 64 bytes)       /
++-----+-----+-----+-----+-----+-----+-----+-----+
 /              BLOCK (variable length)          /
 +-----+-----+-----+-----+-----+-----+-----+-----+
 ]]></artwork>
@@ -1398,11 +1409,35 @@ BEGIN
               The key under which the <tt>PutMessage</tt> wants to store content
               under.
             </dd>
+            <dt>TRUNCATED ORIGIN</dt>
+            <dd>
+              is only provided if the TRUNCATED flag
+              is set in OPTIONS. If present, this is
+              the public key of the peer just before
+              the first entry on the PUTPATH and the
+              first peer on the PUTPATH is not the
+              actual origin of the message.  Thus, to
+              verify the first signature on the PUTPATH,
+              this public key must be used.  Note that
+              due to the truncation, this last hop
+              cannot be verified to exist.
+            </dd>
             <dt>PUTPATH</dt>
             <dd>
               the variable-length PUT path.
               The path consists of a list of PATH_LEN Path Elements.
             </dd>
+            <dt>LAST HOP SIGNATURE</dt>
+            <dd>
+              is only provided if the RECORD ROUTE flag
+              is set in OPTIONS. If present, this is
+              an EdDSA signature of the sender of this message
+              (using the same format as the signatures in PUTPATH)
+              affirming that the sender forwarded the message from
+              the predecessor (all zeros if PATH_LEN is 0,
+              otherwise the last peer in PUTPATH) to
+              the target peer.
+            </dd>
             <dt>BLOCK</dt>
             <dd>
               the variable-length block payload. The contents are determined
@@ -1448,14 +1483,14 @@ BEGIN
             <li>
               If the <tt>RecordRoute</tt> flag is set in FLAGS,
               the local peer address <bcp14>MUST</bcp14> be appended to the <tt>PUTPATH</tt>
-              of the message.  If the flag is not set, the <tt>PATH_LEN</tt> 
+              of the message.  If the flag is not set, the <tt>PATH_LEN</tt>
               <bcp14>MUST</bcp14> be set to zero.
             </li>
             <li>
-              If the <tt>PATH_LEN</tt> is non-zero, 
+              If the <tt>PATH_LEN</tt> is non-zero,
               the local peer <bcp14>SHOULD</bcp14> verify the signatures from the <tt>PUTPATH</tt>.
               Verification <bcp14>MAY</bcp14> involve checking all signatures or any random
-              subset of the signatures.  It is <bcp14>RECOMMENDED</bcp14> that peers adapt 
+              subset of the signatures.  It is <bcp14>RECOMMENDED</bcp14> that peers adapt
               their behavior to available computational resources so as to not make signature
               verification a bottleneck.  If an invalid signature is found, the
               <tt>PUTPATH</tt> <bcp14>MUST</bcp14> be truncated to only include the elements
@@ -1469,9 +1504,9 @@ BEGIN
             </li>
             <li>
               If the <tt>MTYPE</tt> of the message indicates a HELLO block, the
-              peer <bcp14>MUST</bcp14> be considered for the local routing 
+              peer <bcp14>MUST</bcp14> be considered for the local routing
               table if the respective k-bucket is not yet full. In this case,
-              the local peer <bcp14>MUST</bcp14> try to establish a connection 
+              the local peer <bcp14>MUST</bcp14> try to establish a connection
               to the peer indicated in the HELLO block using the address information
               from the HELLO block. If a connection is established,
               the peer is added to the respective k-bucket of the routing table.
@@ -1482,7 +1517,7 @@ BEGIN
               Given the value in <tt>REPL_LVL</tt>, <tt>HOPCOUNT</tt> and the
               result of <tt>IsClosestpeer(SELF, BLOCK_KEY)</tt> the number of peers to
               forward to <bcp14>MUST</bcp14> be calculated
-              using <tt>ComputeOutDegree()</tt>. 
+              using <tt>ComputeOutDegree()</tt>.
               The implementation <bcp14>SHOULD</bcp14> select up to this
               number of peers to forward the message to. The implementation <bcp14>MAY</bcp14>
               forward to fewer or no peers in order to handle resource constraints
@@ -1491,7 +1526,7 @@ BEGIN
               <tt>PEER_BF</tt> before forwarding the message.
               For all peers with peer address <tt>P</tt> selected to forward the message
               to, <tt>SEND(P, PutMessage')</tt> is called. Here, <tt>PutMessage'</tt>
-              is the original message with updated fields. In particular, <tt>HOPCOUNT</tt> 
+              is the original message with updated fields. In particular, <tt>HOPCOUNT</tt>
               <bcp14>MUST</bcp14> be incremented by 1.
             </li>
           </ol>
@@ -1604,7 +1639,7 @@ BEGIN
                   <t>
             How exactly a block result is added to a result filter
             <bcp14>MUST</bcp14> be
-            specified as part of the definition of a block type.  
+            specified as part of the definition of a block type.
           </t>
         </section>
         <section anchor="p2p_get_processing">
@@ -1669,7 +1704,7 @@ BEGIN
               </t>
               <t>
                If the <tt>BTYPE</tt> is supported and <tt>ValidateBlockReply</tt> for the given
-               query has yielded a status of <tt>FILTER_LAST</tt>, processing 
+               query has yielded a status of <tt>FILTER_LAST</tt>, processing
                <bcp14>MUST</bcp14> end and not continue with forwarding of
                the request to other peers.
               </t>
@@ -1687,7 +1722,7 @@ BEGIN
               peer address <tt>SELF</tt>.
               For all peers with peer address <tt>P'</tt> chosen to forward the message
               to, <tt>SEND(P', GetMessage')</tt> is called.  Here, <tt>GetMessage'</tt>
-              is the original message with updated fields. In particular, <tt>HOPCOUNT</tt> 
+              is the original message with updated fields. In particular, <tt>HOPCOUNT</tt>
               <bcp14>MUST</bcp14> be incremented by 1.
             </li>
           </ol>
@@ -1713,12 +1748,16 @@ BEGIN
 |                  QUERY_HASH                   /
 /                 (64 byte)                     |
 +-----+-----+-----+-----+-----+-----+-----+-----+
+/       TRUNCATED ORIGIN (0 or 32 bytes)        /
++-----+-----+-----+-----+-----+-----+-----+-----+
 /                  PUTPATH                      /
 /                 (variable length)             /
 +-----+-----+-----+-----+-----+-----+-----+-----+
 /                  GETPATH                      /
 /                 (variable length)             /
 +-----+-----+-----+-----+-----+-----+-----+-----+
+/      LAST HOP SIGNATURE (0 or 64 bytes)       /
++-----+-----+-----+-----+-----+-----+-----+-----+
 /                  BLOCK                        /
 /                 (variable length)             /
 +-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1737,7 +1776,7 @@ BEGIN
             </dd>
             <dt>RESERVED</dt>
             <dd>
-              is a 32-bit value. Implementations <bcp14>MUST</bcp14> 
+              is a 32-bit value. Implementations <bcp14>MUST</bcp14>
               set this value to zero when originating a result message.
               Implementations <bcp14>MUST</bcp14> forward
               this value unchanged even if it is non-zero.
@@ -1772,6 +1811,19 @@ BEGIN
               the query hash corresponding to the <tt>GetMessage</tt> which
               caused this reply message to be sent.
             </dd>
+            <dt>TRUNCATED ORIGIN</dt>
+            <dd>
+              is only provided if the TRUNCATED flag
+              is set in OPTIONS. If present, this is
+              the public key of the peer just before
+              the first entry on the PUTPATH and the
+              first peer on the PUTPATH is not the
+              actual origin of the message.  Thus, to
+              verify the first signature on the PUTPATH,
+              this public key must be used.  Note that
+              due to the truncation, this last hop
+              cannot be verified to exist.
+            </dd>
             <dt>PUTPATH</dt>
             <dd>
               the variable-length PUT path.
@@ -1782,6 +1834,17 @@ BEGIN
               the variable-length PUT path.
               The path consists of a list of <tt>GET_PATH_LEN</tt> Path Elements.
             </dd>
+            <dt>LAST HOP SIGNATURE</dt>
+            <dd>
+              is only provided if the RECORD ROUTE flag
+              is set in OPTIONS. If present, this is
+              an EdDSA signature of the sender of this message
+              (using the same format as the signatures in PUTPATH)
+              affirming that the sender forwarded the message from
+              the predecessor (all zeros if PATH_LEN is 0,
+              otherwise the last peer in PUTPATH) to
+              the target peer.
+            </dd>
             <dt>BLOCK</dt>
             <dd>
               the variable-length resource record data payload.
@@ -1801,19 +1864,19 @@ BEGIN
               If the message is expired, it <bcp14>MUST</bcp14> be discarded.
             </li>
             <li>
-              If the <tt>BTYPE</tt> is supported, then the <tt>BLOCK</tt> 
-              <bcp14>MUST</bcp14> be validated against the 
+              If the <tt>BTYPE</tt> is supported, then the <tt>BLOCK</tt>
+              <bcp14>MUST</bcp14> be validated against the
               requested <tt>BTYPE</tt>.  To do this, the peer
               checks that the block is valid using <tt>ValidateBlockStoreRequest</tt>.
               If the result is <tt>BLOCK_INVALID</tt>, the message <bcp14>MUST</bcp14> be
               discarded.
             </li>
             <li>
-              If the <tt>PUT_PATH_LEN</tt> or the <tt>GET_PATH_LEN</tt> are non-zero, 
+              If the <tt>PUT_PATH_LEN</tt> or the <tt>GET_PATH_LEN</tt> are non-zero,
               the local peer <bcp14>SHOULD</bcp14> verify the signatures from the <tt>PUTPATH</tt>
               and the <tt>GETPATH</tt>.
               Verification <bcp14>MAY</bcp14> involve checking all signatures or any random
-              subset of the signatures.  It is <bcp14>RECOMMENDED</bcp14> that peers adapt 
+              subset of the signatures.  It is <bcp14>RECOMMENDED</bcp14> that peers adapt
               their behavior to available computational resources so as to not make signature
               verification a bottleneck.  If an invalid signature is found, the
               path <bcp14>MUST</bcp14> be truncated to only include the elements
@@ -1828,9 +1891,9 @@ BEGIN
             </li>
             <li>
               If the <tt>MTYPE</tt> of the message indicates a HELLO block, the
-              peer <bcp14>MUST</bcp14> be considered for the local routing 
+              peer <bcp14>MUST</bcp14> be considered for the local routing
               table if the respective k-bucket is not yet full. In this case,
-              the local peer <bcp14>MUST</bcp14> try to establish a connection 
+              the local peer <bcp14>MUST</bcp14> try to establish a connection
               to the peer indicated in the HELLO block using the address information
               from the HELLO block. If a connection is established,
               the peer is added to the respective k-bucket of the routing table.
@@ -1848,7 +1911,7 @@ BEGIN
                   If the <tt>FindApproximate</tt> flag was not set in the query and the <tt>BTYPE</tt> allowed the
                   implementation to compute the key from the block, the computed key must
                   exactly match the <tt>QUERY_HASH</tt>, otherwise the result does
-                  not match the pending query and processing continues with the next pending query.               
+                  not match the pending query and processing continues with the next pending query.
                 </li>
                 <li>
                   If the <tt>BTYPE</tt> is supported, result block <bcp14>MUST</bcp14>
@@ -1859,7 +1922,7 @@ BEGIN
                   query.
                 </li>
                 <li>
-                  If the <tt>BTYPE</tt> is not supported, filtering of exact duplicate 
+                  If the <tt>BTYPE</tt> is not supported, filtering of exact duplicate
                   replies <bcp14>MUST</bcp14> still be performed before forwarding
                   the reply.
                   Such duplicate filtering <bcp14>MAY</bcp14> be implemented
@@ -1872,8 +1935,8 @@ BEGIN
                   the local peer address <bcp14>MUST</bcp14> be appended to the <tt>GETPATH</tt>
                   of the message and the respective signature <bcp14>MUST</bcp14> be
                   set using the query origin as the <tt>PEER SUCCESSOR</tt> and the
-                  response origin as the <tt>PEER PREDECESSOR</tt>.  If the flag is not set, 
-                  the <tt>GET_PATH_LEN</tt> and <tt>PUT_PATH_LEN</tt> 
+                  response origin as the <tt>PEER PREDECESSOR</tt>.  If the flag is not set,
+                  the <tt>GET_PATH_LEN</tt> and <tt>PUT_PATH_LEN</tt>
                   <bcp14>MUST</bcp14> be set to zero when forwarding the result.
                 </li>
               </ol>
@@ -1885,9 +1948,9 @@ BEGIN
               </t>
             </li>
             <li>
-              Finally, the implementation <bcp14>MAY</bcp14> choose to 
+              Finally, the implementation <bcp14>MAY</bcp14> choose to
               cache data from <tt>ResultMessage</tt>s.
-            </li>       
+            </li>
           </ol>
         </section>
       </section>
@@ -1896,7 +1959,7 @@ BEGIN
       <name>Blocks</name>
       <t>
         This section describes various considerations R<sup>5</sup>N
-        implementations must consider with respect to blocks. 
+        implementations must consider with respect to blocks.
         Specifically, implementations <bcp14>SHOULD</bcp14> be able
         to validate and persist blocks.  Implementations
         <bcp14>MAY</bcp14> not support validation for all types
@@ -1907,7 +1970,7 @@ BEGIN
         Applications can and should define their own block types.
         The block type determines the format and handling of the block
         payload by peers in <tt>PutMessage</tt>s and <tt>ResultMessage</tt>s.
-        Block types <bcp14>MUST</bcp14> be registered with GANA 
+        Block types <bcp14>MUST</bcp14> be registered with GANA
         (see <xref target="gana_block_type"/>).
       </t>
       <t>
@@ -1916,7 +1979,7 @@ BEGIN
         <name>Block Operations</name>
           <t>
             Block validation may be necessary for all types of DHT
-            messages.  To enable these validations, any block type 
+            messages.  To enable these validations, any block type
             specification <bcp14>MUST</bcp14> define the following functions:
           </t>
           <dl>
@@ -1926,7 +1989,7 @@ BEGIN
               <t>
               is used to evaluate the request for a block as part of
               <tt>GetMessage</tt> processing. Here, the block payload is unkown,
-              but if possible the <tt>XQuery</tt> and <tt>Key</tt> 
+              but if possible the <tt>XQuery</tt> and <tt>Key</tt>
               <bcp14>SHOULD</bcp14> be verified.  Possible values for
               the <tt>RequestEvaluationResult</tt> are:
               </t>
@@ -1943,7 +2006,7 @@ BEGIN
             </dd>
             <dt>DeriveBlockKey(Block) -&gt; Key | NONE</dt>
             <dd>
-              is used to synthesize the block key from the block payload as 
+              is used to synthesize the block key from the block payload as
               part of <tt>PutMessage</tt> and <tt>ResultMessage</tt> processing.
               The special return value of <tt>NONE</tt> implies that this block type does not
               permit deriving the key from the block.  A Key may be returned
@@ -1963,8 +2026,8 @@ BEGIN
                <dt>BLOCK_INVALID</dt>
                <dd>Block payload does not match the block type.
                </dd>
-              </dl>            
-            </dd> 
+              </dl>
+            </dd>
             <dt>SetupResultFilter(FilterSize, Mutator) -&gt; RF</dt>
             <dd>
               is used to setup an empty result filter.  The arguments
@@ -1999,7 +2062,7 @@ BEGIN
               <t>
               If the main evaluation result is <tt>FILTER_MORE</tt>, the function also returns
               and updated result filter where the block is added to the set of
-              filtered replies.  An implementation is not expected to actually differenciate 
+              filtered replies.  An implementation is not expected to actually differenciate
               between the <tt>FILTER_DUPLICATE</tt> and <tt>FILTER_IRRELEVANT</tt> return
               values: in both cases the block is ignored for this query.
               </t>
@@ -2021,7 +2084,7 @@ BEGIN
             The HELLO block type wire format is illustrated in
             <xref target="figure_hello"/>. A query for block of type HELLO <bcp14>MUST NOT</bcp14>
             include extended query data (XQuery). Any implementation
-            encountering a request for a HELLO with non-empty XQuery 
+            encountering a request for a HELLO with non-empty XQuery
             data <bcp14>MUST</bcp14> consider the request invalid and ignore it.
           </t>
           <figure anchor="figure_hello" title="The HELLO Block Format.">
@@ -2204,8 +2267,8 @@ gnunet+tcp://12.3.4.5/ \
             deterministic across peers.  The 32-bit <tt>MUTATOR</tt>
             value is set by the peer initiating the GET request, and changed
             every time the GET request is repeated by the initiator. Peers
-            forwarding GET requests <bcp14>MUST</bcp14> not change the 
-            mutator value included in the <tt>RESULT_FILTER</tt> as they might not 
+            forwarding GET requests <bcp14>MUST</bcp14> not change the
+            mutator value included in the <tt>RESULT_FILTER</tt> as they might not
             be able to recalculate the result filter with a different <tt>MUTATOR</tt>
             value.
           </t>
@@ -2214,11 +2277,11 @@ gnunet+tcp://12.3.4.5/ \
             requests have statistically independent probabilities of creating
             false-positives in a result filter. Thus, even if for one request
             a result filter may exclude a result as a false-positive
-            match, subsequent requests are likely to not have the same 
+            match, subsequent requests are likely to not have the same
             false-positives.
           </t>
           <t>
-            HELLO result filters can be merged if the 
+            HELLO result filters can be merged if the
             Bloom filters have the same size and
             <tt>MUTATOR</tt> by setting all bits to 1 that are
             set in either Bloom filter.  This is done whenever
@@ -2233,8 +2296,8 @@ gnunet+tcp://12.3.4.5/ \
              the <tt>ADDRESSES</tt>) and XORed with the SHA-512
              hash of the <tt>MUTATOR</tt> (in network byte order).
              The resulting value is then used when hashing into the
-             Bloom filter as described in <xref target="bloom_filters" />. 
-             Consequently, HELLOs with completely identical sets of 
+             Bloom filter as described in <xref target="bloom_filters" />.
+             Consequently, HELLOs with completely identical sets of
              addresses will be filtered and FILTER_DUPLICATE is returned.
              Any small variation in the set of addresses will cause the block
              to no longer be filtered (with high probability) and
@@ -2246,8 +2309,8 @@ gnunet+tcp://12.3.4.5/ \
         <name>Persistence</name>
         <t>
           An implementation <bcp14>SHOULD</bcp14> provide a local persistence mechanism for
-          blocks.  Embedded systems that lack storage capability <bcp14>MAY</bcp14> use 
-          connection-level signalling to indicate that they are merely a client utilizing a 
+          blocks.  Embedded systems that lack storage capability <bcp14>MAY</bcp14> use
+          connection-level signalling to indicate that they are merely a client utilizing a
           DHT and are not able to participate with storage.
           The local storage <bcp14>MUST</bcp14> provide the following functionality:
         </t>
@@ -2257,7 +2320,8 @@ gnunet+tcp://12.3.4.5/ \
             Stores a block under the specified key. If an block with identical
             payload exists already under the same key, the meta data should
             be set to the maximum expiration time of both blocks and use the
-            corresponding <tt>PUTPATH</tt> of that version of the block.
+            corresponding <tt>PUTPATH</tt> (and if applicable
+            <tt>TRUNCATED ORIGIN</tt>) of that version of the block.
           </dd>
           <dt>Lookup(Key) -&gt; List of Blocks</dt>
           <dd>
@@ -2358,7 +2422,7 @@ gnunet+tcp://12.3.4.5/ \
         The <tt>ComputeOutDegree</tt> function limits the
         <tt>REPL_LVL</tt> to a maximum of 16. This imposes
         an upper limit on bandwidth amplification an attacker
-        may achieve for a given network size and topology.  
+        may achieve for a given network size and topology.
 </t>
       <section>
         <name>Approximate Result Filtering</name>
@@ -2404,7 +2468,7 @@ gnunet+tcp://12.3.4.5/ \
         </t>
       </section>
     </section>
-      
+
     <section anchor="gana" numbered="true" toc="default">
     <name>GANA Considerations</name>
       <section anchor="gana_block_type" numbered="true" toc="default">