This commit fixes a regression in how we allocate funds to attempted
channels. We would earlier stay within the channel size limits, but we
wouldn't account for funds consumed by other channels being opened in
parallel.
We fix this by introducing a loop which greadily tries to distribute the
funds among the channels to open, and reduces the number of channels to
open in case not enough funds are available to satisfy the channel size
limits.
In this commit, we address a lingering issue within some subsystems that
are responsible for broadcasting transactions. Previously,
ErrDoubleSpend indicated that a transaction was already included in the
mempool/chain. This error was then modified to actually be returned for
conflicting transactions, but its callers were not modified accordingly.
This would lead to conflicting transactions to be interpreted as valid,
when they shouldn't be.
The checks to determine whether the transaction broadcast failed due to
it already existing in the mempool/chain are no longer needed since the
underlying btcwallet PublishTransaction call will not return an error
when running into these cases.
In this commit, we fix an off-by-one error when handling force closes
from the remote party. Before this commit, if the remote party
broadcasts state 2, and we were on state 1, then we wouldn't act at all.
This is due to an extraneous +1 in the comparison, causing us to only
detect this DLP case if the remote party's state is two beyond what we
know atm. Before this commit, the test added in the prior commit failed.
In this commit, we add a new test case to exercise the way we handle the
DLP detection and dispatch within the chain watcher. Briefly, we use
the `testing/quick` package to ensure that the following invariant is
always held: "if we do N state updates, then state M is broadcast, iff M
> N, we'll execute the DLP protocol". We limit the number of iterations
to 10 for now, as the tests can take a bit of time to execute, since it
actually does proper state transitions.
In this commit, we abstract the call to `GetStateNumHint` within the
`closeObserver` method to a function closure in the primary config. This
allows us to feed in an arbitrary broadcast state number within unit
tests.
In this commit, we slightly refactor the startup of lnd when running
with a Neutrino light client backend. We'll now begin syncing our
backend as soon as lnd starts and passes all configuration checks. Since
this is all done before lnd's wallet setup, the light client will be
syncing in the background while the user notes/inputs their wallet seed.
This is done in order to provide a better UX from the point of the user,
such that most of the chain will already be synced by the time they get
to deposit funds into the wallet.
In this commit, we update the build to point to the latest version of
neutrino and btcwallet. The latest version of neutrino includes a number
of bug fixes, and new features like reliably transaction broadcast. The
latest version of btcwallet contains a number of bug fixes related to
properly remove invalid transactions from its database.
Modifies the netann.ChanStatusManager to remove outpoints
from the set of tracked channels when it encounters a
channeldb.ErrEdgeNotFound when passively disabling. It is
possible for this to occur if a channel is closed w/o first
being disabled, which may happen if the remote party force
closes.
This commit moves the query routes backend logic from the main
rpc server into the sub server. It is another step towards splitting up
the main rpc server code.
In addition to this, a unit test is added to verify rpc parameter
parsing.
In this commit, we update the `TestChanSyncFailure` method to pass given
the new behavior around updating borked channel states. In order to do
this, we add a new method to allow the test to clear an existing channel
state. This method may be of independent use in other areas in the
codebase in the future as well.
In this commit, we ensure that we mark the channel as borked before we
remove the link during the force close process. This ensures that if the
peer reconnects right after we remove the link, then it won't be loaded
into memory in `loadActiveChannels`. We'll now:
* mark the channel as borked
* remove the link
* read the channel state from disk
* force close
This ensures that the link (if it's active) is able to commit any
pending changes to disk before we read out the channel to force close.
In this commit, we add a new test: `TestForceCloseBorkedState`. This
ensures that it isn't possible to update the channel state once a
channel has been marked as borked. This assumes that all calls to
`ForceClose` will also mark the channel as borked. This isn't the case
yet, so this test fails as is.
When using the unit test flakehunter and specifying a package, after the
first successful run, all of the tests would be run, rather than just
the ones within the specified package.
Now that QueryRoutes gained the ability to route from any source node
and takes in edge and node black lists, all pieces are in place to have
users implemented their own k-shortests path algorithm. Or any other algorithm
they might wish to use and currently can't.
This commit marks the num_routes field as deprecated as a preparation
for removing k-shortest for lnd.
Currently public keys are represented either as a 33-byte array (Vertex) or as a
btcec.PublicKey struct. The latter isn't useable as index into maps and
cannot be used easily in compares. Therefore the 33-byte array
representation is used predominantly throughout the code base.
This commit converts the argument types of source and target nodes for
path finding to Vertex. Path finding executes no crypto operations and
using Vertex simplifies the code.
Additionally, it prepares for the path finding source parameter to be
exposed over rpc in a follow up commit without requiring conversion back
and forth between Vertex and btcec.PublicKey.
This commit allows the execution of QueryRoutes to be controlled using
lists of black-listed edges and nodes. Any path returned will not pass
through the edges and/or nodes on the list.
