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

routerrpc: new payment rpc [wip] #2973

Open
wants to merge 49 commits into
base: master
from

Conversation

Projects
None yet
4 participants
@joostjager
Copy link
Collaborator

commented Apr 18, 2019

Based on top of #2761

@joostjager joostjager force-pushed the joostjager:newer-payment-rpc branch 3 times, most recently from 3aee088 to 25bc701 Apr 18, 2019

@Roasbeef Roasbeef added this to the 0.7 milestone Apr 18, 2019

@Roasbeef Roasbeef requested a review from halseth Apr 18, 2019

@Roasbeef

This comment has been minimized.

Copy link
Member

commented Apr 30, 2019

Shouldn't this be branched off of #2761?

@@ -29,7 +29,7 @@ type RouterBackend struct {
// routes.
FindRoutes func(source, target routing.Vertex,
amt lnwire.MilliSatoshi, restrictions *routing.RestrictParams,
numPaths uint32, finalExpiry ...uint16) (
numPaths uint32, finalExpiry ...int32) (

This comment has been minimized.

Copy link
@Roasbeef

Roasbeef Apr 30, 2019

Member

Any strong reason to move to signed integers here? Virtually none of these fields are permitted to be negative. Historically, we've also used uint16 for time lock deltas as we typically don't need anything more than a few weeks into the future.

This comment has been minimized.

Copy link
@joostjager

joostjager Apr 30, 2019

Author Collaborator

Got bitten a few times now with negative numbers after subtraction (deltas can be negative) and want to prevent it from happening again to me or a future dev working with heights.

This comment has been minimized.

Copy link
@joostjager

joostjager Apr 30, 2019

Author Collaborator

In general, I think it is good to consistently use int32 for heights and block deltas everywhere throughout the code base. With conversion from/to wire format as the only exception.

Show resolved Hide resolved routing/router.go
Show resolved Hide resolved lnrpc/routerrpc/router.proto
Show resolved Hide resolved lnrpc/routerrpc/router_backend.go Outdated
Show resolved Hide resolved cmd/lncli/commands.go
return err
}

resp, err := paymentStream.Recv()
fmt.Printf("Payment in flight, track status by running:\n")

This comment has been minimized.

Copy link
@Roasbeef

Roasbeef Apr 30, 2019

Member

I'm not sure we want to change the behavior of the CLI command over night like this. Instead we should add the RPC level change first, then follow up with the CLI changes. Otherwise, we may break many bash scripts that rely on payinvoice or sendpayment returning as soon as the payment is complete.

This comment has been minimized.

Copy link
@joostjager

joostjager Apr 30, 2019

Author Collaborator

If we don't want to break bash scripts, we'd better not change lncli at all. We are changing the payment result data as well. The string based "last error" isn't there anymore. No more reporting on payment attempt level outcomes.

This comment has been minimized.

Copy link
@juscamarena

juscamarena May 1, 2019

Contributor

We're in beta, scripts will be updated. Most should probably be using the up to date payment rpc anyway.

Show resolved Hide resolved cmd/lncli/commands.go
Show resolved Hide resolved lnrpc/routerrpc/router_server.go Outdated
@joostjager

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 30, 2019

Shouldn't this be branched off of #2761?

Yes, this is still wip. Should have added [wip] to the title.

@joostjager joostjager changed the title routerrpc: new payment rpc routerrpc: new payment rpc [wip] Apr 30, 2019

@joostjager joostjager force-pushed the joostjager:newer-payment-rpc branch 2 times, most recently from 67cedaa to 54f8506 Apr 30, 2019

halseth and others added some commits May 1, 2019

channeldb: add Route (de)serialization + test
We will store the routes used during payment attempts, so we need
serialization code.
htlcswitch+router: define PaymentResult, GetPaymentResult
This lets us distinguish an critical error from a actual payment result
(success or failure). This is important since we know that we can only
attempt another payment when a final result from the previous payment
attempt is received.
switch+router+server: move NextPaymentID to router
This commit moves the responsibility of generating a unique payment ID
from the switch to the router. This will make it easier for the router
to keep track of which HTLCs were successfully forwarded onto the
network, as it can query the switch for existing HTLCs as long as the
paymentIDs are kept.

The router is expected to maintain a map from paymentHash->paymentID,
such that they can be replayed on restart. This also lets the router
check the status of a sent payment after a restart, by querying the
switch for the paymentID in question.
channeldb: put payment status in new bucket
We move the payment status to a new bucket hierarchy. Old buckets and
fetch methods are kept around for migration purposes.
channeldb/migration: add migration for new payment bucket structure
migrateOutgoingPayments moves the OutgoingPayments into a new bucket format
where they all reside in a top-level bucket indexed by the payment hash. In
this sub-bucket we store information relevant to this payment, such as the
payment status.

To avoid that the router resend payments that have the status InFlight (we
cannot resume these payments for pre-migration payments) we delete those
statuses, so only Completed payments remain in the new bucket structure.
channeldb/payments+control_tower: split OutgoingPayments
This commit changes the format used to store payments within the
DB. Previously this was serialized as one continuous struct
OutgoingPayment, which also contained an Invoice struct we where only
using a few fields of. We now split it up into two simpler sub-structs
CreationInfo, AttemptInfo and PaymentPreimage.

We also want to associate the payments more closely with payment
statuses, so we move to this hierarchy:

There's one top-level bucket "sentPaymentsBucket" which contains a set
of sub-buckets indexed by a payment's payment hash. Each such sub-bucket
contains several fields:
paymentStatusKey -> the payment's status
paymentCreationInfoKey -> the payment's CreationInfo.
paymentAttemptInfoKey -> the payment's AttemptInfo.
paymentSettleInfoKey -> the payment's preimage (or zeroes for
non-settled payments)

The CreationInfo is information that is static during the whole payment
lifcycle. The attempt info is set each time a new payment attempt
(route+paymentID) is sent on the network. The preimage is information
only known when a payment succeeds.  It therefore makes sense to split
them.

We keep legacy serialization code for migration puproses.

halseth and others added some commits May 1, 2019

routing/router: resume payment state machine at startup
On startup the router will fetch the in-flight payments from the control
tower, and resume their execution.

sq resume payments
routing/router_test: add TestRouterPaymentStateMachine
TestRouterPaymentStateMachine tests that the router interacts as
expected with the ControlTower during a payment lifecycle, such that it
payment attempts are not sent twice to the switch, and results are
handled after a restart.

@joostjager joostjager force-pushed the joostjager:newer-payment-rpc branch 4 times, most recently from c2d0cc8 to d218a62 May 1, 2019

@joostjager joostjager force-pushed the joostjager:newer-payment-rpc branch from d218a62 to ecfdf21 May 2, 2019

joostjager added some commits Apr 30, 2019

@joostjager joostjager force-pushed the joostjager:newer-payment-rpc branch from ecfdf21 to 17a98d4 May 3, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.