Commit Graph

7659 Commits

Author SHA1 Message Date
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
Wilmer Paulino
138d9b68f0
lnwallet+sweep: add String method to FeePreference 2019-05-24 15:30:36 -07:00
Olaoluwa Osuntokun
eba989048c
Merge pull request #3117 from halseth/update-neutrino-dep
[dependency update]: update to latest neutrino dep
2019-05-24 13:02:06 -07:00
AdamISZ
9b3676fdd4
Allow unit-cover target for make to filter by package
Previous to this commit, running `make unit-cover pkg=xx`
would ignore the selected package and run unit tests and
coverage for all packages.
After this commit, the package selected with pkg= is the
only one that is tested and coverage output generated for.
If no pkg is selected, the default is as before, all pkgs.
2019-05-24 12:51:35 +02:00
Johan T. Halseth
ea50502a79
go mod: update to latest neutrino dep 2019-05-24 12:41:31 +02:00
Johan T. Halseth
af3b04e53f
Merge pull request #3103 from halseth/syncmanager-resync-historical
discovery/sync_manager: restart historical sync on first connected peer
2019-05-24 12:17:02 +02:00
Johan T. Halseth
6ba6982ae7
discovery/sync_manager_test: add TestSyncManagerHistoricalSyncOnReconnect
TestSyncManagerHistoricalSyncOnReconnect tests that the sync manager will
re-trigger a historical sync when a new peer connects after a historical
sync has completed, but we have lost all peers.
2019-05-24 11:05:30 +02:00
Johan T. Halseth
526486ae24
discovery/sync_manager: restart historical sync on first connected peer
To handle the case where we have been without peers, and get a new
connection, we reset the historical scan booleans when the first active
syncer is connected to trigger another historical sync.
2019-05-24 11:05:29 +02:00
Conner Fromknecht
b35a5b8892
watchtower/wtclient: integrate ClientChannelSummaries
In this commit, we utilize the more generic ClientChanSummary instead of
exposing methods that only allow us to set and fetch sweep pkscripts.
2019-05-23 20:48:50 -07:00
Conner Fromknecht
25fc464a6e
watchtower/wtdb/client_chan_summary: add ClientChanSummary
A ClientChanSummary will be inserted for each channel registered with
the client, which for now will just track the sweep pkscript to use. In
the future, this will be extended with additional information to enable
the client to efficiently compute which historical states need to be
backed up under a given policy.
2019-05-23 20:48:36 -07:00
Conner Fromknecht
440ae7818a
watchtower/wtmock/client_db: adjust mock clientdb behavior
In advance of the upcoming wtdb.ClientDB, we'll modify the behavior
of the mockdb to be more like the final bbolt backed one, and assert
that all or our tests are still passing.
2019-05-23 20:48:23 -07:00