routing+htlcswitch: fix typos/grammar

Author: C-Otto

htlcswitch/switch.go

@@ -851,7 +851,7 @@ func (s *Switch) getLocalLink(pkt *htlcPacket, htlc *lnwire.UpdateAddHTLC) (
 		// If the link was not found for the outgoingChanID, an outside
 		// subsystem may be using the confirmed SCID of a zero-conf
 		// channel. In this case, we'll consult the Switch maps to see
-		// if an alias exists and use the alias to lookup the link.
+		// if an alias exists and use the alias to look up the link.
 		// This extra step is a consequence of not updating the Switch
 		// forwardingIndex when a zero-conf channel is confirmed. We
 		// don't need to change the outgoingChanID since the link will
@@ -1125,7 +1125,7 @@ func (s *Switch) handlePacketForward(packet *htlcPacket) error {
 				"destination %v", packet.outgoingChanID)
 
 			// If packet was forwarded from another channel link
-			// than we should notify this link that some error
+			// then we should notify this link that some error
 			// occurred.
 			linkError := NewLinkError(
 				&lnwire.FailUnknownNextPeer{},

routing/result_interpretation.go

@@ -307,10 +307,10 @@ func (i *interpretedResult) processPaymentOutcomeIntermediate(
 
 	// If a node reports onion payload corruption or an invalid version,
 	// that node may be responsible, but it could also be that it is just
-	// relaying a malformed htlc failure from it successor. By reporting the
+	// relaying a malformed htlc failure from its successor. By reporting the
 	// outgoing channel set, we will surely hit the responsible node. At
 	// this point, it is not possible that the node's predecessor corrupted
-	// the onion blob. If the predecessor would have corrupted the payload,
+	// the onion blob. If the predecessor had corrupted the payload,
 	// the error source wouldn't have been able to encrypt this failure
 	// message for us.
 	case *lnwire.FailInvalidOnionVersion,
@@ -360,7 +360,7 @@ func (i *interpretedResult) processPaymentOutcomeIntermediate(
 	// When an HTLC parameter is incorrect, the node sending the error may
 	// be doing something wrong. But it could also be that its predecessor
 	// is intentionally modifying the htlc parameters that we instructed it
-	// via the hop payload. Therefore we penalize the incoming node pair. A
+	// via the hop payload. Therefore, we penalize the incoming node pair. A
 	// third cause of this error may be that we have an out of date channel
 	// update. This is handled by the second chance logic up in mission
 	// control.