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

Light-152 multihop routing #37

Closed
wants to merge 2 commits into from
Closed

Light-152 multihop routing #37

wants to merge 2 commits into from

Conversation

BitfuryLightning
Copy link
Contributor

A simple implementation of multihop payments.
Integration with routing and path validation.

Add multihop/payment initialisation and
integration with routing.
Path are validated by sending each node
message requesting if it is able to make
HTLC payment. It is implemented in parallel
style, not onion like.
Add comment to make multihop payment to a given address
which integrates routing, path validation and multihop
payment.
Copy link
Member

@Roasbeef Roasbeef left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for another PR!

As details within the review, I think many parts of this PR can be omitted due to redundancy compared to the latest version of master. Let's discuss the other components such as the pre-send HTLC lock-up and the placement of the sender/receiver protocol within the LN stack.

@@ -866,3 +868,228 @@ func printRTAsJSON(r *rt.RoutingTable) {
}
printRespJson(channels)
}

var SendMultihopPayment = cli.Command{
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think there should be distinct cli nor RPC commands for sending multi-hop payments vs single hop payments. At the time this PR was being put together the onion routing stuff wasn't in place, but it is now so the caller doesn't require any knowledge of the full route, only the final destination.

However, I can see how it might be useful to give the caller full control over the final path which the payment is execute over. So how about we merge this behavior into the existing SendPayment command with an additional argument which provides full "path selection".

if err != nil {
return err
}
if len(p) != 32 {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the latest version of master, when sending payments compressed public keys are used, so this should check for a length of 33 instead.


var FindPathCommand = cli.Command{
Name: "findpath",
Description: "finds path from node to some other node",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the description should be updated to be a bit more explicit. How about something along the lines of:

"attempts to find a path to the target destination node"

Flags: []cli.Flag{
cli.StringFlag{
Name: "destination",
Usage: "lightningID of destination",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In order to be in line with the latest version of master, a compressed public key should be expected instead.

Usage: "lightningID of destination",
},
cli.IntFlag{
Name: "maxpath",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To make the arg a bit more explicit, it should be extended a bit to be named maxpathlength.

@@ -1247,7 +1275,7 @@ func (p *peer) updateCommitTx(state *commitmentState) (bool, error) {
// log entry the corresponding htlcPacket with src/dest set along with the
// proper wire message. This helepr method is provided in order to aide an
// htlcManager in forwarding packets to the htlcSwitch.
func (p *peer) logEntryToHtlcPkt(pd *lnwallet.PaymentDescriptor) *htlcPacket {
func (p *peer) logEntryToHtlcPkt(pd *lnwallet.PaymentDescriptor, chanPoint *wire.OutPoint) *htlcPacket {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These changes are unnecessary from the PoV of the latest version of master.

@@ -519,3 +521,53 @@ func (r *rpcServer) ShowRoutingTable(ctx context.Context,
Channels: channels,
}, nil
}

func (r *rpcServer) SendMultihopPayment(ctx context.Context, in *lnrpc.MultihopPaymentRequest) (* lnrpc.MultihopPaymentResponse, error){
Copy link
Member

@Roasbeef Roasbeef Sep 22, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As detailed above, I don't think the addition of the RPC is necessary.

int(in.NumberOfPaths),
1*time.Second,
)
rpcsLog.Info("[FindPath] after FindKSP dest=", hex.EncodeToString([]byte(in.TargetID)))
Copy link
Member

@Roasbeef Roasbeef Sep 22, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Converting to a byte slice, then using EncodeToString seems like it'll lead to an erroneous string being produced. Why not just encode as hex directly? Or if it's already a hex string, then that can be printed as is.

}
validationStatuses := make([]lnwire.AllowHTLCStatus, len(paths))
if in.Validate {
validationStatuses = r.server.routingMgr.ValidatePathMult(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does ValidatePathMult do?

@@ -316,6 +330,27 @@ out:
} else {
srvrLog.Errorf("Can't find peer to send message %v", receiverID)
}
case msg := <- s.paymentManager.chPaymentOut:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similarly, I think this fragment can be removed all together from the PoV of the latest state in master.

@Roasbeef
Copy link
Member

Also this needs to be rebased on-top of the latest master branch as it diverges significantly.

@Roasbeef
Copy link
Member

Closing this PR now as #70 and the state of the current codebase supersedes it. I'll make some issues to salvage certain parts of this PR such as the path querying, since the code has already been written.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants