-
Notifications
You must be signed in to change notification settings - Fork 268
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
Add router API for invoice routing hints #1590
Conversation
The router can return local channels, with all necessary information to build routing hints from these channels. It's not eclair-core's responsibility to choose what channels to use in routing hints: this is really a wallet strategy, so each wallet should have its own heuristics to choose what channels to include (if any).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't "add a router API for invoice routing hints"?
def getRemoteNodeId(localNodeId: PublicKey): PublicKey = channel.fold( | ||
c => c.remoteNodeId, | ||
c => if (localNodeId == c.ann.nodeId1) c.ann.nodeId2 else c.ann.nodeId1 | ||
) | ||
|
||
/** Get our remote peer's channel_update: this is what must be used in invoice routing hints. */ | ||
def getRemoteUpdate(localNodeId: PublicKey): Option[ChannelUpdate] = channel.fold( | ||
c => if (localNodeId == c.nodeId1) c.update_2_opt else c.update_1_opt, | ||
c => if (localNodeId == c.ann.nodeId1) c.update_2_opt else c.update_1_opt | ||
) | ||
|
||
/** Create an invoice routing hint from that channel. Note that if the channel is private, the invoice will leak its existence. */ | ||
def toExtraHop(localNodeId: PublicKey): Option[ExtraHop] = getRemoteUpdate(localNodeId).map(remoteUpdate => | ||
ExtraHop(getRemoteNodeId(localNodeId), remoteUpdate.shortChannelId, remoteUpdate.feeBaseMsat, remoteUpdate.feeProportionalMillionths, remoteUpdate.cltvExpiryDelta) | ||
) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems to me that we could make remoteNodeId
part of the constructor. It is a bit strange that we need to provide more info for a class named LocalChannel
to tell which side is the local one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, I'll revisit that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in 273dd81, let me know what you think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's better.
Yes it does, but only to the router :). It doesn't add it to the HTTP API as I think it's unnecessary, it's meant to be used by plugins for nodes that offer custodial wallet capabilities (for public nodes you usually don't need any routing hint, you have public channels). |
Yes, my rationale is that some nodes may start pruning smaller public channels at some point to keep graph manageable, so adding hints for smaller public channels can be useful. |
The router can now return local channels, with all necessary information to build routing hints from these channels.
It's not eclair-core's responsibility to choose what channels to use in routing hints: this is really a wallet strategy, so each wallet should have its own heuristics to choose what channels to include (if any).
I think @btcontract was interested in these.