fixup: use return packet instead of reason field

Author: joostjager

04-onion-routing.md

@@ -1037,7 +1037,8 @@ route, so it knows where to return-forward any eventual return packets.
 
 ## Erring node
 
-The node generating the error message (_erring node_) builds a return packet (the `reason` field in `update_fail_htlc`) consisting of the following fields:
+The node generating the error message builds a _return packet_
+consisting of the following fields:
 
 1. data:
    * [`32*byte`:`hmac`]
@@ -1066,7 +1067,7 @@ The erring node puts its hold time at the start of this array and zeroes out the
 field is based on the maximum supported number of hops in a route (20).
 
 The field `truncated_hmacs` contains truncated authentication codes series for each hop, with the
-same `um` key that is used for `hmac` in the `reason` field. Regular 32 byte HMACs are
+same `um` key that is used for `hmac` in the return packet. Regular 32 byte HMACs are
 truncated to the first 4 bytes to save space.
 
 In theory this truncation makes it possible for malicious nodes to guess the
@@ -1092,7 +1093,7 @@ away from the erring node.
 
 Each HMAC covers the following data:
 
-* The `reason` field.
+* The return packet.
 
 * The first `y+1` hold times in `htlc_hold_times`. For example, `hmac_0_2` would cover
   all three hold times.
@@ -1158,7 +1159,7 @@ result to obfuscate the `attribution_data` field.
 Furthermore every hop, also the ones that do no support attributable failures, performs these steps:
 
 * Generate its `ammag` key, generate the pseudo-random byte streams, and apply the
-result to obfuscate the `reason` field
+result to obfuscate the return packet. This is then stored as the `reason` field of the `update_htlc_fail` message.
 
   These obfuscation steps are identical to the obfuscation steps that the erring node carries out.
 
@@ -1185,9 +1186,9 @@ For nodes supporting attributable failures:
 
 For all nodes:
 
-* Compute the HMAC for the `reason` field, using the hop's `um` key.
+* Compute the HMAC for the return packet, using the hop's `um` key.
 
-* When the computed HMAC matches `hmac` in the `reason` field, the sender will know that the current hop is the sender of the failure. They can then parse `failuremsg`.
+* When the computed HMAC matches `hmac` in the return packet, the sender will know that the current hop is the sender of the failure. They can then parse `failuremsg`.
 
 The association between the forward and return packets is handled outside of
 this onion routing protocol, e.g. via association with an HTLC in a payment