Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

keysend only working with other c-lightning nodes #3968

Closed
Fonta1n3 opened this issue Aug 23, 2020 · 8 comments · Fixed by #4236
Closed

keysend only working with other c-lightning nodes #3968

Fonta1n3 opened this issue Aug 23, 2020 · 8 comments · Fixed by #4236
Assignees
Labels
pay-plugin state::fixed These issues should have been addressed. Pending confirmation by OP, will close soon otherwise

Comments

@Fonta1n3
Copy link

I have been testing keysend and it quite reliably only seems to work with other c-lightning nodes.

This recipient for example has keysend enabled and is able to send me keysends but I am unable to return the favor and generally get an error:

error =     {
        "amount_msat" = 1000msat;
        "amount_sent_msat" = 0msat;
        code = 203;
        "created_at" = 1598181774;
        destination = 02f7dcc28e15c0b55238a0f7db02b2082b1c2fa5adf66ff96e79db8f7ae17fe7d3;
        "erring_index" = 4;
        "erring_node" = 02f7dcc28e15c0b55238a0f7db02b2082b1c2fa5adf66ff96e79db8f7ae17fe7d3;
        failcode = 16399;
        failcodename = "WIRE_INCORRECT_OR_UNKNOWN_PAYMENT_DETAILS";
        id = 343;
        message = "failed: WIRE_INCORRECT_OR_UNKNOWN_PAYMENT_DETAILS (reply from remote)";
        msatoshi = 1000;
        "msatoshi_sent" = 0;
        "payment_hash" = 1887be8ddb26b3336494899f0a58d068f4343ba4160c38d05ee28986426744ca;
        "raw_message" = 400f00000000000003e80009d777;
        status = pending;
    }
@ZmnSCPxj
Copy link
Collaborator

Hmm looks like we need to know exactly what keysend implementation the recipient is using. Do you know? Logs from the recipient implementation would be nice as well.

@Fonta1n3
Copy link
Author

@ZmnSCPxj I know this peer is on LND v0.10.3 beta but that’s all I know right now.

Will ask around to a few others.

@Fonta1n3
Copy link
Author

Another is on LND 0.10.4.

@rustyrussell
Copy link
Contributor

Hmm. Keysend is undocumented, so perhaps we implemented it wrong? @cdecker

rustyrussell added a commit to rustyrussell/lightning that referenced this issue Sep 10, 2020
As revealed by the failure of tests in ElementsProject#3936, where we ended up trying
to send a partial payment using legacy style, we are not handling
style properly.

1. BOLT9 has features, so we can *know* that the destination supports
   MPP.  We may not have seen a node_announcement.
2. We can't assume that nodes inside routehints support TLV.
3. We can't assume direct peers support TLV.

The keysend code tried to fix this up, so I'm not sure that this caused
the issue in ElementsProject#3968, though.

Signed-off-by: Rusty Russell <[email protected]>
rustyrussell added a commit to rustyrussell/lightning that referenced this issue Sep 10, 2020
As revealed by the failure of tests in ElementsProject#3936, where we ended up trying
to send a partial payment using legacy style, we are not handling
style properly.

1. BOLT9 has features, so we can *know* that the destination supports
   MPP.  We may not have seen a node_announcement.
2. We can't assume that nodes inside routehints support TLV.
3. We can't assume direct peers support TLV.

The keysend code tried to fix this up, so I'm not sure that this caused
the issue in ElementsProject#3968, though.

Signed-off-by: Rusty Russell <[email protected]>
Changelog-Fixed: `pay` will now make reliable multi-part payments to nodes it doesn't have a node_announcement for.
rustyrussell added a commit to rustyrussell/lightning that referenced this issue Sep 10, 2020
As revealed by the failure of tests in ElementsProject#3936, where we ended up trying
to send a partial payment using legacy style, we are not handling
style properly.

1. BOLT9 has features, so we can *know* that the destination supports
   MPP.  We may not have seen a node_announcement.
2. We can't assume that nodes inside routehints support TLV.
3. We can't assume direct peers support TLV.

The keysend code tried to fix this up, so I'm not sure that this caused
the issue in ElementsProject#3968, though.

Signed-off-by: Rusty Russell <[email protected]>
Changelog-Fixed: `pay` will now make reliable multi-part payments to nodes it doesn't have a node_announcement for.
@cdecker
Copy link
Member

cdecker commented Sep 10, 2020

Indeed there is no official specification for keysend, so I had to reverse engineer it. It was working for a while, but I can't guarantee it hasn't changed on the lnd side. I'll see what I can do 👍

rustyrussell added a commit that referenced this issue Sep 10, 2020
As revealed by the failure of tests in #3936, where we ended up trying
to send a partial payment using legacy style, we are not handling
style properly.

1. BOLT9 has features, so we can *know* that the destination supports
   MPP.  We may not have seen a node_announcement.
2. We can't assume that nodes inside routehints support TLV.
3. We can't assume direct peers support TLV.

The keysend code tried to fix this up, so I'm not sure that this caused
the issue in #3968, though.

Signed-off-by: Rusty Russell <[email protected]>
Changelog-Fixed: `pay` will now make reliable multi-part payments to nodes it doesn't have a node_announcement for.
@d4amenace
Copy link

Don't know if this is helpful, but I was trying to do a keysend to my Eclair Mobile wallet version 0.4.12 and it to is failing.

@Fonta1n3
Copy link
Author

Fonta1n3 commented Oct 9, 2020

From my experience it literally only works c-lightning to c-lightning although i haven’t tested since latest release.

@cdecker
Copy link
Member

cdecker commented Nov 30, 2020

The error message got me thinking that the recipient might not support keysend at all, and checking with my local gossip (which might look different now), it doesn't seem the destination supports it:

{
  "nodeid": "02f7dcc28e15c0b55238a0f7db02b2082b1c2fa5adf66ff96e79db8f7ae17fe7d3",
  "alias": "Satoshi Nakamoto",
  "color": "000000",
  "last_timestamp": 1606207493,
  "features": "02a2a1",
  "addresses": [
    {
      "type": "torv3",
      "address": "p3hv5427zr3obj2edec4uva3jvcs37jus5adpxpxy2xw4jwivfm5hvad.onion",
      "port": 9735
    }
  ]
}

(Notice that 0x02a2a1 >> 55 & 0x01 == 0x00, i.e., the keysend bit 55 is not set)

So adding the check before initiating a payment, and failing with a more informative error message, like we do in #4236 should address this issue.

@cdecker cdecker added state::fixed These issues should have been addressed. Pending confirmation by OP, will close soon otherwise pay-plugin labels Nov 30, 2020
vibhaa pushed a commit to spider-pcn/lightning that referenced this issue Mar 24, 2021
As revealed by the failure of tests in ElementsProject#3936, where we ended up trying
to send a partial payment using legacy style, we are not handling
style properly.

1. BOLT9 has features, so we can *know* that the destination supports
   MPP.  We may not have seen a node_announcement.
2. We can't assume that nodes inside routehints support TLV.
3. We can't assume direct peers support TLV.

The keysend code tried to fix this up, so I'm not sure that this caused
the issue in ElementsProject#3968, though.

Signed-off-by: Rusty Russell <[email protected]>
Changelog-Fixed: `pay` will now make reliable multi-part payments to nodes it doesn't have a node_announcement for.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pay-plugin state::fixed These issues should have been addressed. Pending confirmation by OP, will close soon otherwise
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants