keysend: Add routehints argument to the keysend command #4611
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
cdecker
force-pushed
the
keysend-routehints
branch
from
d58f53f
to
553fd61
Compare
rustyrussell
approved these changes
Jun 20, 2021
| name, json_strdup(tmpctx, buffer, tok)); | ||
| } | ||
|
|
||
| *ris = tal_arr(cmd, struct route_info *, 0); |
There was a problem hiding this comment.
I tried this but there are just too many levels of indirection and my head started hurting: we're passing a pointer of position in an array, which should then be initialized in the callee, and is itself a variable length array. What would the canonical way of doing this be? And is there a trick to make this clearer in the code (parentheses, ...)?
cdecker
force-pushed
the
keysend-routehints
branch
2 times, most recently
from
15bb806
to
8b22989
Compare
cdecker
force-pushed
the
keysend-routehints
branch
from
8b22989
to
b3b3f53
Compare
|
Ack: b3b3f53 |
Incoming HTLCs are rejected by the HTLC logic if the payload contains an even type that `lightningd` doesn't recognize. This is to prevent us from accidentally accepting a payment that has extra semantics attached (for example if we get a keysend payment and don't know what to do with the TLV field containing the message we should reject it, otherwise the overall semantics of the message delivery fail).
We'll start passing routehints manually to keysend to reach non-public nodes as well.
So far we could not reach non-publicly reachable nodes with the keysend command since we couldn't compute a route to them. With this change we can add some routehints that we may have gotten from an address book or a previous invoice, and make it more likely that we can reach the destination. Changelog-Added: keysend: `keysend` can now reach non-public nodes by providing the `routehints` argument if they are known.
cdecker
force-pushed
the
keysend-routehints
branch
from
b3b3f53
to
4b42c3c
Compare
|
ACK 4b42c3c |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
So far we could not reach non-publicly reachable nodes with the
keysend command since we couldn't compute a route to them. With this
change we can add some routehints that we may have gotten from an
address book or a previous invoice, and make it more likely that we
can reach the destination.
Builds on top of #4610 to avoid rebase conflicts, but I can separate them out if that's preferred. This PR consists only of the last 3 commits.