Commit Graph

11487 Commits

Author SHA1 Message Date
Conner Fromknecht
d771ed7616
Merge pull request #5159 from halseth/amp-sendpayment
AMP support for SendPaymentV2
2021-04-27 11:23:39 -07:00
Joost Jager
cdddaaca75 routing: no backend call to fetch best block 2021-04-27 19:05:55 +02:00
Johan T. Halseth
13c00127da
itest: add SendPayment AMP itest 2021-04-27 09:47:24 +02:00
Johan T. Halseth
a2a61a104f
itest: make sendAndAssertSuccess take context 2021-04-27 09:47:23 +02:00
Johan T. Halseth
c4fc72d573
routerrpc+routing: set AMP options for payments specified as AMP in SendPayment 2021-04-27 09:47:23 +02:00
Johan T. Halseth
8f57dcf28f
routerrpc: validate DestFeatures from RPC 2021-04-27 09:47:23 +02:00
Johan T. Halseth
0b9137cdac
lnrpc: add AMP feature bits 2021-04-27 09:47:23 +02:00
Johan T. Halseth
56a2c65477
router: use SetID as identifier for SendToRoute AMP-payments 2021-04-27 09:47:23 +02:00
Johan T. Halseth
f07c9d002c
routing: use Identifier in place of PaymentHash
Since we want to support AMP payment using a different unique payment
identifier (AMP payments don't go to one specific hash), we change the
nomenclature to be Identifier instead of PaymentHash.
2021-04-27 09:47:23 +02:00
Johan T. Halseth
6104d12cf8
routerrpc: add amp bool to SendPayment
For now this is how you indicate you want to perform an AMP payment to
the destination.
2021-04-27 09:47:23 +02:00
Johan T. Halseth
5531b812e3
routing: use AMP shard tracker
We'll use the AMP-specific ShardTracker for payments having non-nil
AMPOptions.
2021-04-27 09:47:23 +02:00
Johan T. Halseth
2d397b12b1
amp: create amp.ShardTracker
We'll use this AMP-specific ShardTracker for AMP payments.  It will be
used to derive hashes for each HTLC attempt using the underlying AMP
derivation scheme.
2021-04-27 09:47:23 +02:00
Johan T. Halseth
c1e82e534d
amp: add Merge and Zero to Sharer interface 2021-04-27 09:45:14 +02:00
Johan T. Halseth
e1399fb1ec
routing/router: use attempt's unique hash if set on restart 2021-04-27 09:45:13 +02:00
Johan T. Halseth
06f045fca3
channedb/mp_payment: add Hash to individual HTLCs
For AMP payments the hash used for each HTLC will differ, and we will
need to retrive it after a restart. We therefore persist it with each
attempt.
2021-04-27 09:44:19 +02:00
Johan T. Halseth
41ae3530a3
routing/payment_lifecycle: use ShardTracker to track shards
We'll let the payment's lifecycle register each shard it's sending with
the ShardTracker, canceling failed shards. This will be the foundation
for correct AMP derivation for each shard we'll send.
2021-04-27 09:43:40 +02:00
Johan T. Halseth
6474b253d6
routing/shards: add ShardTracker interface
We'll use this to keep track of the outstanding shards and which
preimages we are using for each. For now this is a simple map from
attempt ID to hash, but later we'll hide the AMP child derivation behind
this interface.
2021-04-27 08:27:33 +02:00
Johan T. Halseth
a9f19b100b
router+switch: rename paymentID->attemptID
To distinguish the attempt's unique ID from the overall payment
identifier, we name it attemptID everywhere, and note that the
paymentHash argument won't be the actual payment hash for AMP payments.
2021-04-27 08:27:33 +02:00
Johan T. Halseth
7795353e9f
channeldb: return full payment for inflight payments
We might as well return all info, and we'll need the individual HTLCs
in later commits.
2021-04-27 08:27:32 +02:00
Olaoluwa Osuntokun
8af00ab0cf
Merge pull request #5205 from carlaKC/4987-refactorprep
invoices: add test to demonstrate hodl invoice bug and refactor
2021-04-26 15:48:56 -07:00
Olaoluwa Osuntokun
bfcaf02f04
Merge pull request #4905 from LN-Zap/feat/spend-unconfirmed-estimate
Support spend_unconfirmed in EstimateFee and FundPsbt
2021-04-26 15:48:11 -07:00
Olaoluwa Osuntokun
9ef00d98a7
Merge pull request #5230 from carlaKC/5059-interceptorchanupdate
multi: send channel update for failed interceptor packets
2021-04-26 15:45:43 -07:00
Johan T. Halseth
c207a1528b
Merge pull request #5238 from guggero/windows-dep-fix
mod+tools: pin down build flag dependent go.sum entry
2021-04-26 14:57:21 +02:00
Olaoluwa Osuntokun
260ea9b842
Merge pull request #5165 from Crypt-iQ/psbt_funding_04022021
lnwallet/chanfunding: check all PSBT inputs have witness stack
2021-04-23 12:04:27 -07:00
Olaoluwa Osuntokun
4d358a84e4
Merge pull request #5214 from carlaKC/4788-terminalshard
routing: handle failure to launch shard after permanent failure
2021-04-23 09:50:15 -07:00
Oliver Gugger
364421dced
mod+tools: pin down build flag dependent go.sum entry
This is a workaround to fix the windows build. Apparently there was a
change in go 1.16 in how the go.sum entries are calculated. Dependencies
that aren't directly depended on are stripped. Because we need this
indirect windows dependency for the integration tests, we add a
workaround that makes sure the entry is kept in go.sum.
2021-04-23 14:15:33 +02:00
Oliver Gugger
585a78dbc7
Merge pull request #5022 from bjarnemagnussen/fix-docker-ltc
docker: fix chain for lnd_ltc
2021-04-23 10:13:53 +02:00
carla
b43ddfdb11
routing: label payment lifecycle loop 2021-04-23 08:51:07 +02:00
carla
a63640c488
routing: account for payment terminal errors
If we have processed a terminal state while we're pathfinding
for another shard, the payment loop should not error out on
ErrPaymentTerminal. Instead, it would wait for our shards to
complete then cleanly exit.
2021-04-23 08:46:22 +02:00
Oliver Gugger
2e9e4567ee
Merge pull request #5135 from GameXG/master
lnd: fix #1990 LND can't read .cookie file in Bitcoin datadir (Windows 10)
2021-04-23 08:41:26 +02:00
carla
58d95be4dd
multi: change RegisterAttempt error checking order
Move our more generic terminal check forward so that we only
need to handle a single class of expected errors. This change
is mirrored in our mock, and our reproducing tests are updated
to assert that this move catches both classes of errors we get.
2021-04-23 08:39:45 +02:00
carla
12136a97a9
routing/test: add test for stuck payment with in-flight htlcs
Add an additional stuck-payment case, where our payment gets
a terminal error while it has other htlcs in-flight, and a
shard fails with ErrTerminalPayment. This payment also falls in
our class of expected errors, but is not currently handled. The
mock is updated accordingly, using the same ordering as in our
real RegisterAttempt implementation.
2021-04-23 08:39:45 +02:00
carla
80451afe48
routing/test: add test to demonstrate stuck payment, single shard
This commit adds a test which demonstrates that payments can
get stuck if we receive a payment failure while we're pathfinding
for another shard, then try to dispatch a shard after we've
recorded a permanent failure. It also updates our mock to
only consider payments with no in-flight htlcs as in-flight,
to more closely represent our actual RegisterAttempt.
2021-04-23 08:39:44 +02:00
carla
125980afb7
routing/test: block on pathfinding in tests
This commit adds a step to our payment lifecycle test to add
control over when we find a path for our payment, This is
required for testing race conditions around pathfinding
completing and payment failures being reported.
2021-04-23 08:39:43 +02:00
carla
a68155545c
routing/test: use half shard for single success case
Update our single shard success case to use a route which
splits the payment amount in half. This change still tests
the case where reveal of the preimage counts as a success,
even if we don't have the full amount. This change is made
to cut down on potential races in this test case. While we
are waiting for collectResultAsync to report a success, the
payment lifecycle will continue trying to dispatch shards.
In the case where we send 1/4 of the payment amount, we
send 1 or 2 more shards, depending on how long collectAsync
takes. Reducing this test to send 1/2 of the payment amount
means that we will always only try one more shard before
waiting for our shard.
2021-04-23 08:39:42 +02:00
carla
198d567cb2
routing/test: assert error value for payment failures 2021-04-23 08:39:41 +02:00
carla
e0c52e4473
routing/test: close payment result channel on shutdown, mimicking switch
This commit updates our mock to more closely follow the behavior of the
switch for mocked calls to GetPaymentResult. As it stands, our tests
send a test-created error from the switch when we want to mock shutdown.
In reality, the switch will close its result channel, so we update this
test to follow that behavior. This matters for the commit that follows,
because we start checking the error our payments return. If we have an
error from the switch, our tests will fail with an error that we do
not encounter in practice.
2021-04-23 08:39:40 +02:00
carla
9a78e9da73
routing/tests: move lock acquisition after state driving channels
In our payment lifecycle tests, we have two goroutines that
compete for the lock in our mock control tower: the resumePayment
loop which tries to call RegisterAttempt, and the collectResult
handler which is launched in a goroutine by collectResultAsync
and is responsible for various settle/fail calls.

The order that the lock is acquired by these goroutines is
arbitrary, and can lead to flakes in our tests if the step
that we do not intend to execute first gets the lock (eg,
we want to fail a payment in collectResult, but RegisterAttempt
gets there first). This commit moves contention for this lock
after our mock's various "state driving" channels, so that the
lock will be acquired in the order that the test intends it.
2021-04-23 08:39:39 +02:00
carla
b2d941ebfb
routing/test: remove test channel buffers
Now that we run each test individually, we don't need to buffer
our mock's channels anymore. This helps to tighten our test loop,
which currently can move on from a step before it's actually
been processed by the mock. This removal ensures that our payment
loop processes each of the test's steps before moving on to the
next once.
2021-04-23 08:39:38 +02:00
carla
806c4cbd57
routing/test: run each test case individually, add names
Update our payment lifecycle test to run each test case with
a fresh router. This prevents test cases from interacting with
each other. Names are also added for easy debugging.
2021-04-23 08:39:37 +02:00
carla
cb927e89b0
routing/test: add check that sendpayment completes
As is, we don't check that our SendPayment call in
TestRouterPaymentStateMachine completes. This makes it easier
to create malformed tests that just run through steps but leave
the SendPayment call hanging. This commit adds a check that we
have completed our payment to help catch tests like this. We
also remove an unused quit channel.
2021-04-23 08:39:36 +02:00
carla
d0d0d21573
itest/test: remove hold force close dependency
Our aggregate htlc test depends on our previous behavior
where recipients would allow channels with pending hold
invoice htlcs to force close. Now that we have an expiry
watcher to prevent these force closes, we can't rely on
this for tests because the recipient will cancel the htlcs
back before they expire.
2021-04-23 08:19:58 +02:00
carla
7536dd8179
invoices: refactor - add method to handle expected cancelation errors 2021-04-23 08:19:57 +02:00
carla
039e9f439c
invoices: refactor - update timestamp expiry to use specific names 2021-04-23 08:19:56 +02:00
carla
d29f2fe4f9
invoices: refactor - move cancel check into separate function
Useful for tests which need to mock cancelInvoiceImpl
2021-04-23 08:19:55 +02:00
carla
4cd48c52ea
invoices: refactor - add interface for expiry items
In preparation for having more than one expiry type, we
alias the queue.PrioirtyQueueItem interface for readability.
2021-04-23 08:19:54 +02:00
carla
9c6e83b15f
invoices: refactor - rename expiry queue to be timestamp specific 2021-04-23 08:19:53 +02:00
carla
f5f1e9e6c7
invoices: refactor - rename invoiceExpiry to invoiceExpiryTs
We're going to add block based expiry, so we clarify now.
2021-04-23 08:19:52 +02:00
carla
2e39edd6bd
itest/test: add test for expired hold invoices
This commit adds a test for a hold invoice which is accepted
off-chain, and held by the recipient until it expired and
the payer force-closes the channel. With this test we
demonstrate two bugs in our handling of hold invoice state
in the invoice registry when we expire on chain:
- Htlcs not updated: even when we've timed out, we don't
  update the htlc state accordingly.
- Invoice can be settled: the invoice can be settled even
  though it's expired on chain.
2021-04-23 08:19:51 +02:00
carla
16373d3879
itest/test: add test to reproduce settling timed out invoice
Reproduce the case where we allow settling of invoices that have
htlcs that have actually timed out on chain. This bug can rarely
occur if a hodl invoice goes to chain and is manually settled
after it has timed out. Funds are SAFU, but this could be a
headache because the invoice says it's settled when no funds
were claimed.
2021-04-23 08:19:50 +02:00