Are there other reasons for FAILURE_REASON_NO_ROUTE with keysend ?

[Cameron-IPFSPodcasting]

I am able to use lncli to make a keysend payment, but when I try the same payment via python gRPC, it returns FAILURE_REASON_NO_ROUTE.

I'm doing the pre_image & payment_hash "thing' explained here and here for sending keysend payments. This is my relevant code to setup the request...

pre_image = os.urandom(32).hex()
payment_hash = hashlib.sha256(pre_image.encode()).hexdigest()
request = routerrpc.SendPaymentRequest(
  dest = bytes.fromhex(address),
  amt = int(sats),
  payment_hash = bytes.fromhex(payment_hash),
  timeout_seconds = 5,
  dest_custom_records = { 5482373484: bytes.fromhex(pre_image), 7629169: bytes(tlvtxt, 'utf-8') },
)

"address" is a string (converted to 33 bytes). "tlvtxt" is the json text of the 7629169 TLV record. I've also tried sending the TLV in hex (like lncli) with the same result.

My response from stub.SendPaymentV2(request) is...

payment_hash: "1b87ec94b4dd2851146a9ff5f7ea2b8b2fe4560cfe0c74087e92301e6d9dbeed"
value: 55
creation_date: 1687745762
payment_preimage: "0000000000000000000000000000000000000000000000000000000000000000"
value_sat: 55
value_msat: 55000
status: IN_FLIGHT
creation_time_ns: 1687745762348636588
payment_index: 9014

...followed by...

payment_hash: "1b87ec94b4dd2851146a9ff5f7ea2b8b2fe4560cfe0c74087e92301e6d9dbeed"
value: 55
creation_date: 1687745762
payment_preimage: "0000000000000000000000000000000000000000000000000000000000000000"
value_sat: 55
value_msat: 55000
status: FAILED
creation_time_ns: 1687745762348636588
payment_index: 9014
failure_reason: FAILURE_REASON_NO_ROUTE

...which both happen almost instantaneously (from the LND log)...

2023-06-26 02:16:02.777 [WRN] CRTR: Failed to find route for payment 1b87ec94b4dd2851146a9ff5f7ea2b8b2fe4560cfe0c74087e92301e6d9dbeed: unable to find a path to destination
2023-06-26 02:16:02.789 [ERR] CRTR: Payment 1b87ec94b4dd2851146a9ff5f7ea2b8b2fe4560cfe0c74087e92301e6d9dbeed failed: no_route

I don't believe this is a route failure. When I use lncli to the same address with the same TLV, the payment succeeds. The only other possibility (that I can see) is the pre_image / payment_hash setup. Or that I'm using gRPC and the examples are REST (which use b64 encoding). AFAIK, gRPC doesn't need b64.

Would a bad request cause a route failure error (even though it passed validation)?

Thanks to anyone who can help,

Cameron

[guggero]

Take a look at the routing fee option. I think some RPCs have a default value that is sane and others unfortunately have a default value of 0, meaning it's looking for free routes only (which results in no route being found).

[Cameron-IPFSPodcasting]

Thanks for the tip. I'll post what I find.

[Cameron-IPFSPodcasting]

That was the issue. Once I set a fee_limit_sat the routing error was resolved.

But now I'm getting INCORRECT_OR_UNKNOWN_PAYMENT_DETAILS which I suspect is the pre_image/payment_hash setup.
My latest request is...

pre_image = os.urandom(32).hex()
payment_hash = hashlib.sha256(pre_image.encode()).hexdigest()
request = routerrpc.SendPaymentRequest(
  dest = bytes.fromhex(address),
  amt = int(sats),
  payment_hash = bytes.fromhex(payment_hash),
  timeout_seconds = 5,
  fee_limit_sat = 10,
  dest_custom_records = { 5482373484: bytes(pre_image, 'utf-8'), 7629169: bytes(tlvtxt, 'utf-8') },
)

From what I understand, the payment_hash is the sha256 of the (random) 32 bit pre_image. i.e. payment_hash=sha256(pre_image). My response seems to make sense. I'm sending this value (pre_image)...

      custom_records {
        key: 5482373484
        value: "5fc8750a6698c8d60b0df8694c2f7821ec57fe51a656ca46f639fd3e5275e198"
      }

...which after I run sha256, matches the payment hash

payment_hash: "e2d8875d4cd77c4150739f5a058ff7be9fe7882125540ed7a50d6708fad6f9fe"

I also notice that payment_preimage in the response is all zeros...

payment_preimage: "0000000000000000000000000000000000000000000000000000000000000000"

Is this a clue, or not filled out until the payment succeeds?

I can post the entire response results (but it's long).

[guggero]

I would guess it's some kind of encoding issue. Not really proficient with Python, so couldn't point to a specific place. But when I run echo 5fc8750a6698c8d60b0df8694c2f7821ec57fe51a656ca46f639fd3e5275e198 | xxd -r -p | sha256sum in my console, I get 736cbccd712de02a4063eaeebe0e63b15ae21c0e23d8fc33540b29e8ef7b733e and not e2d8875d4cd77c4150739f5a058ff7be9fe7882125540ed7a50d6708fad6f9fe. So you need to take the hash of the raw bytes of the preimage, not the hex encoded string.

[guggero]

I think the preimage is only filled in once the payment has been completed (because in the normal flow with an invoice lnd doesn't know it upfront).

[Cameron-IPFSPodcasting]

Thank you, Thank you!

I've been pulling my hair out for days and thought I tried every combination of encoding (monkeys typing shakespear). More eyes on the issue always helps.

This is my final setup for anyone having issues figuring out python gRPC keysend payments.

pre_image = os.urandom(32).hex()
payment_hash = hashlib.sha256(bytes.fromhex(pre_image)).hexdigest()
request = routerrpc.SendPaymentRequest(
  dest = bytes.fromhex(address),
  amt = int(sats),
  payment_hash = bytes.fromhex(payment_hash),
  timeout_seconds = 5,
  fee_limit_sat = 10,
  dest_custom_records = { 5482373484: bytes.fromhex(pre_image), 7629169: bytes(tlvtxt, 'utf-8') },
)

BTW, This is for a new feature to pay v4v bootagrams & streaming payments to IPFS nodes hosting podcast episodes via ipfspodcasting.net

[Cameron-IPFSPodcasting]

The 66 character hex string (036107c5e53241315268f7439d7c5666ff86e1b793d1a185cf9326c0c094cffef9) is converted to binary with bytes.fromhex to give you a 33 byte binary address.

[BitcoinCoderBob]

got this working in go in this repo: https://github.com/BitcoinCoderBob/Satogram

the hex string for the pubkey specifically here: https://github.com/BitcoinCoderBob/Satogram/blob/c8b0e1534780d9fefbacd8aa9d4fa6c705e9d939/node/keysend.go#L69C40-L69C40