routing/pathfind: ensure final hop supports payment addrs

This commit adds an optional PaymentAddr field to the RestrictParams, so
that we can verify the final hop can support it before doing an
expensive round of pathfindig.

routing/pathfind.go

@@ -70,6 +70,11 @@ var (
 	errNoTlvPayload = errors.New("destination hop doesn't " +
 		"understand new TLV payloads")
 
+	// errNoPaymentAddr is returned when the destination hop does not
+	// support payment addresses.
+	errNoPaymentAddr = errors.New("destination hop doesn't " +
+		"understand payment addresses")
+
 	// errNoPathFound is returned when a path to the target destination does
 	// not exist in the graph.
 	errNoPathFound = errors.New("unable to find a path to destination")
@@ -298,6 +303,11 @@ type RestrictParams struct {
 	// supports. If none are provided, pathfinding will try to inspect any
 	// features on the node announcement instead.
 	DestFeatures *lnwire.FeatureVector
+
+	// PaymentAddr is a random 32-byte value generated by the receiver to
+	// mitigate probing vectors and payment sniping attacks on overpaid
+	// invoices.
+	PaymentAddr *[32]byte
 }
 
 // PathFindingConfig defines global parameters that control the trade-off in
@@ -447,6 +457,14 @@ func findPath(g *graphParams, r *RestrictParams, cfg *PathFindingConfig,
 		return nil, errNoTlvPayload
 	}
 
+	// If the caller has a payment address to attach, check that our
+	// destination feature vector supports them.
+	if r.PaymentAddr != nil &&
+		!features.HasFeature(lnwire.PaymentAddrOptional) {
+
+		return nil, errNoPaymentAddr
+	}
+
 	// If we are routing from ourselves, check that we have enough local
 	// balance available.
 	if source == self {