Building current lnd `0.18` fails with older go (`1.19.7`).
* Updated go download path to 1.22.4
* Updated hashes
* Added `rm -rf` instructions as per [go.dev instructions](https://go.dev/doc/install)
`NewResult` makes it easy to wrap a normal function call in a result
value.
`Err` can be used to check the error case of the result without
unpacking the entire thing.
`AndThen2` allows a caller to compose a function on two results values,
with the closure only executing if both values are non-error.
This removes duplication of in-memory data during the periodic flushing
stage of the mission control store.
The existing code entirely duplicates the in-memory cache of the store,
which is very wasteful when only a few additional results are being
rotated into the store.
This has a significant performance penalty specially for wallets that
remain online for a long time with a low volume of payments. The worst
case scenario are wallets that see at most 1 new payment a second, where
the entire in-memory cache is recreated every second.
This commit improves the situation by determining what will be the
actual changes that need to be committed before initiating the db
transaction and only keeping track of these to update the in-memory
cache if the db tx is successful.
This modifies the mission control store to avoid running the one second
ticker for flushing data when there is no work to be done.
This improves performance of a quiscent LN node by avoiding a one second
interval busy loop that does nothing when there are no payments flowing
through the node.
This modifies the mission control store to avoid doing any work when no
new payment result entries are in the queue to be processed.
The mission control store maintains keeps the latest N (in production:
1000) entries in its DB, evicting older entries when new ones are added.
Currently, its implementation is somewhat less performant than it could
be.
This commit adds an early return to the storeResults function to avoid
doing any DB or memory operations when its outstanding queue is empty,
improving the performance during quiescent periods of the LN node's
execution.
In this commit we set up the payment loop context
according to user-provided parameters. The
`cancelable` parameter indicates whether the user
is able to interrupt the payment loop by cancelling
the server stream context. We'll additionally wrap
the context in a deadline if the user provided a
payment timeout.
We remove the timeout channel of the payment_lifecycle.go
and in favor of the deadline context.
index
When abandoning a channel, we remove it from the graph and then add it
to the zombie channel index. However, if we then process a ChannelUpdate
for this channel it will result in us calling `processZombieUpdate`
which will delete the edge from the zombie index. The abandon channel
itest currently asserts that a channel is no longer in the graph by
asserting that when querying for the channel we get a "marked as zombie"
error but to account for the above series of operations, we now also
allow it to just not be found at all ("edge not found").
We may get a flake like the following,
```
lnd_route_blinding_test.go:468:
Error Trace: /Users/runner/work/lnd/lnd/itest/lnd_route_blinding_test.go:468
/Users/runner/hostedtoolcache/go/1.22.3/arm64/src/runtime/asm_arm64.s:1222
Error: Received unexpected error:
rpc error: code = Canceled desc = context canceled
Test: TestLightningNetworkDaemon/tranche15/144-of-156/bitcoind/disable_introduction_node
```
This happens when the test successfully finishes, the parent context is
canceled, causing the child context to return an error. We fix it by
ignoring it in the goroutine.
This commit fixes#8535 by changing how we assess toSelfAmount inside
the chainWatcher.
In certain cases users may wish to close out channel funds to external
delivery addresses set either during open or close.
Prior to this change we only consider addresses that our wallet is
aware of.
This change now identifies outputs as to_self outputs if the delivery
script matches OR if our wallet is aware of the address. In certain
edge cases it can be possible for there to be more than one output
that matches these criteria and in that case we will return the sum
of those values.
