Commit Graph

10771 Commits

Author SHA1 Message Date
Johan T. Halseth
7cb25a5afb
channeldb/control_tower test: add TestPaymentControlDeleteNonInFlight
TestPaymentControlDeleteNonInFlight checks that calling DeletaPayments
only deletes payments from the database that are not in-flight.
2019-05-27 20:19:00 +02:00
Johan T. Halseth
649ee875fd
routing/router_test: add test case for ForwardingError on SendHTLC 2019-05-27 20:19:00 +02:00
Johan T. Halseth
589f0fcc5d
control_tower: make initial bucket bucket creation stricter 2019-05-27 20:18:59 +02:00
Johan T. Halseth
95b4828780
channeldb: derive PaymentStatus implicitly from stored info 2019-05-27 20:18:59 +02:00
Johan T. Halseth
d705b8a013
channeldb+multi: rename Grounded->Unknown, Completed->Succeeded 2019-05-27 20:18:59 +02:00
Johan T. Halseth
d78d3f50b9
channeldb: move deprecated code to migration_09_legacy_serialization.go
And unexport deprecated code.
2019-05-27 20:18:59 +02:00
Johan T. Halseth
1b788904f0
channeldb+router: record payment failure reason in db 2019-05-27 20:18:59 +02:00
Johan T. Halseth
60e2367973
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.
2019-05-27 20:18:59 +02:00
Johan T. Halseth
3f76bc0629
routing+server: define PaymentSessionSource 2019-05-27 20:18:59 +02:00
Johan T. Halseth
f4306b1178
routing/payment_session+router: make PaymentSession interface 2019-05-27 20:18:58 +02:00
Johan T. Halseth
adc4640f4f
routing: export MissionControl 2019-05-27 20:18:58 +02:00
Johan T. Halseth
3323800e02
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.
2019-05-27 20:18:58 +02:00
Johan T. Halseth
677cb018c9
routing/control_tower: add FetchInFlightPayments 2019-05-27 20:18:58 +02:00
Johan T. Halseth
de1bf8a518
routing/router: persist payment state machine
This commit makes the router use the ControlTower to drive the payment
life cycle state machine, to keep track of active payments across
restarts.  This lets the router resume payments on startup, such that
their final results can be handled and stored when ready.
2019-05-27 20:18:58 +02:00
Johan T. Halseth
dd73c51a34
routing/payment_lifecycle: extract create attempt into method 2019-05-27 20:18:58 +02:00
Johan T. Halseth
e9b2182cdc
routing/payment_lifecycle: extract error handling into method 2019-05-27 20:18:58 +02:00
Johan T. Halseth
83bfaa4fb4
routing: extract payment flow into method on paymentLifecycle
This encapsulates all state needed to resume a payment from any point of
the payment flow, and that must be shared between the different stages
of the execution. This is done to prepare for breaking the send loop
into smaller parts, and being able to resume the payment from any point
from persistent state.
2019-05-27 20:18:57 +02:00
Johan T. Halseth
ae7bf2cb7b
routing/router: move sending and receiving payment result into loop 2019-05-27 20:18:57 +02:00
Johan T. Halseth
59c2557cc9
channeldb/control_tower test: test new payment behavior 2019-05-27 20:18:57 +02:00
Johan T. Halseth
1af1832ff7
channeldb/control_tower: add payment information during state changes
This commit gives a new responsibility to the control tower, letting it
populate the payment bucket structure as the payment goes through
its different stages.

The payment will transition states Grounded->InFlight->Success/Failed,
where the CreationInfo/AttemptInfo/Preimage must be set accordingly.

This will be the main driver for the router state machine.
2019-05-27 20:18:57 +02:00
Johan T. Halseth
6d80661bbb
channeldb/payments: add StatusFailed 2019-05-27 20:18:57 +02:00
Johan T. Halseth
bb4aadd16c
channeldb/control_tower: remove non-strict option
Since we have performed a migration, the db should be in a consistent
state, and we can remove the non-strict option.
2019-05-27 20:18:57 +02:00
Johan T. Halseth
b7189ba028
channeldb test: add TestOutgoingPaymentsMigration 2019-05-27 20:18:57 +02:00
Johan T. Halseth
693807cf6e
channeldb/control_tower: add FetchSentPayments 2019-05-27 20:18:56 +02:00
Johan T. Halseth
801521ed2d
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.
2019-05-27 20:18:56 +02:00
Johan T. Halseth
178996f0d3
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.
2019-05-27 20:18:56 +02:00
Johan T. Halseth
f022810f8b
channeldb/codec: add privateKey serialization 2019-05-27 20:18:56 +02:00
Johan T. Halseth
2417f40532
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.
2019-05-27 20:18:56 +02:00
Johan T. Halseth
d027e10201
htlcswitch+channeldb: move control tower to channeldb 2019-05-27 20:18:56 +02:00
Johan T. Halseth
6e102d64b9
Merge pull request #3101 from AdamISZ/make-unit-cover-pkg
Allow unit-cover target for make to filter by package
2019-05-27 13:18:45 +02:00
Johan T. Halseth
1df148d8ef
routerrpc test: run make fmt 2019-05-27 12:33:43 +02:00
Johan T. Halseth
34032eff0b
make: increase itest timeout to 40 min
Needed for neutrino itest on darwin.
2019-05-27 09:29:03 +02:00
Johan T. Halseth
991b4174fd
lnd_test: fix spelling 2019-05-27 09:29:03 +02:00
Johan T. Halseth
ca1e9dcecb
lntest: skip zeroConf ListUnspent for neutrino 2019-05-27 09:29:03 +02:00
Johan T. Halseth
19d6cc00e5
travis: enable neutrino itest 2019-05-27 09:29:03 +02:00
Johan T. Halseth
fe9ff3828e
lnd_test: skip reorg test for neutrino backend 2019-05-27 09:29:03 +02:00
Johan T. Halseth
39d3aa6eca
lnd_test: add t.Skip to *harnessTest 2019-05-27 09:29:03 +02:00
Johan T. Halseth
2d49ee56e2
lntest: add Name() to BackendCfg 2019-05-27 09:29:03 +02:00
Johan T. Halseth
8f5a4beaad
lntest: add NeutrinoCfg 2019-05-27 09:29:02 +02:00
Johan T. Halseth
335a039ba2
lnd_test: alter testUnconfirmedChannelFunding to work with Neutrino
We slightly alter testUnconfirmedChannelFunding to instead of using an
external deposit to test unconfirmed channel funding, we use one of our
own unconfirmed change outputs.

This is done since Neutrino currently has now way of knowing about
incoming unconfirmed outputs.
2019-05-27 09:29:02 +02:00
Johan T. Halseth
3df0821aa3
make: add backend tag for itests
Defaults to running itests with btcd.
2019-05-27 09:29:02 +02:00
Johan T. Halseth
8e8bb9ff09
lntest+lnd_test: build flag btcd for BtcdBackendCfg 2019-05-27 09:29:02 +02:00
Johan T. Halseth
aec00b1277
lntest+lnd_test: add Connect and Disconnect miner for BackendCfgs
This commit gives the current chainbackend the ability to connect and
disconnect the chain backend at will. We do this to let the chain
backend initiate the connection to the miner, not the other way around.

This is a preparation for using Neutrino as a backend, as it only allows
making outbound connections.

We must also move the setup of the chainbackend to after to miner, to
know the address to connect to.
2019-05-27 09:29:02 +02:00
Johan T. Halseth
1788fa1566
rpcserver: print unconfirmed balance, add TODO for racy balance 2019-05-27 09:29:02 +02:00
Olaoluwa Osuntokun
6e3b92b55f
Merge pull request #3106 from cfromknecht/wtclient-db
watchtower/wtdb: add bbolt-backed ClientDB
2019-05-24 18:53:00 -07:00
Conner Fromknecht
28bf49807e
watchtower/wtdb: add CSessionStatus field to ClientSession
This commit adds persisted status bit-field to ClientSessions, that can
be used to modify behavior of their handling in the client. Currently,
only a default CSessionActive status is defined. However, the intention
is that this could later be used to signal that a session is abandoned
without needing to perform a db migration to add the field. As we move
forward with testing, this will likely be useful if a session gets
borked and we need a simple method of the client to temporarily ignore
certain sessions.

The field may be useful in signaling other types of status changes,
though this was the primary motivation that warranted the addition.
2019-05-24 18:24:41 -07:00
Conner Fromknecht
9157c88f93
watchtower/wtclient: dedup backups across restarts
Now that the committed and acked updates are persisted across restarts,
we will use them to filter out duplicate commit heights presented by the
client.
2019-05-24 18:24:41 -07:00
Conner Fromknecht
3be651b0b3
watchtower/wtdb: add ClientDB
This commit adds the full bbolt-backed client database as well as a set
of unit tests to assert that it exactly implements the same behavior as
the mock ClientDB.
2019-05-24 18:24:41 -07:00
Wilmer Paulino
682aebdd53
sweep: broadcast sweep transactions in descending fee rate order
In this commit, we address another issue that arose with the
introduction of the fee rate buckets. We'll use an example to explain
the problem space:

Let's say we have inputs A, B, and C within the same fee rate bucket. If
A's fee rate is bumped to a higher bucket, then it's currently possible
for the lower fee rate bucket to be swept first, which would produce an
invalid RBF transaction since we're removing an input from the original
without providing a higher fee. By the time we get to the higher fee
rate bucket, we broadcast a valid RBF transaction _only_ sweeping input
A, which would evict the transaction sweeping inputs B and C from the
mempool.

To prevent this eviction, we can simply broadcast the higher fee rate
sweep transactions first, to ensure we have valid RBF transactions.
2019-05-24 15:30:39 -07:00
Wilmer Paulino
5172a5e255
multi: support arbitrary client fee preferences to UtxoSweeper
In this commit, we introduce support for arbitrary client fee
preferences when accepting input sweep requests. This is possible with
the addition of fee rate buckets. Fee rate buckets are buckets that
contain inputs with similar fee rates within a specific range, e.g.,
1-10 sat/vbyte, 11-20 sat/vbyte, etc. Having these buckets allows us to
batch and sweep inputs from different clients with similar fee rates
within a single transaction, allowing us to save on chain fees.

With this addition, we can now get rid of the UtxoSweeper's default fee
preference. As of this commit, any clients using the it to sweep inputs
specify the same fee preference to not change their behavior. Each of
these can be fine-tuned later on given their use cases.
2019-05-24 15:30:38 -07:00