This commit modifies the breachArbiter to properly mark a channel as
_fully_ closed once the transaction which force closed the channel has
been confirmed within the chain.
Within this commit the peer will now properly manage the channel close
life cycle within the database. This entails marking the channel as
pending closed either once the closing transaction has been broadcast
or the close request message has been sent to the other side.
Once the closing transaction has been confirmed, the transaction will
be marked as fully closed within the database. A helper function has
been added to factor out “waiting for a transaction to confirm” when
handling moth local and remote cooperative closure flows.
Finally, we no longer delete the channel state within wipeChannel as
this will now be managed distinctly by callers.
This commit fixes a bug that double counts the number of pending
channels in GetInfo. Previously we weren’t yet storing the pending
channels on disk, we are now but comparing both the disk channel and
the channels within memory leads us to double count channels. To fix
this, we now only count the database channels.
Note that this NumPendingChannels method can now be removed as it’s no
longer needed.
This commit adds a new public facing method to the utxoNursery:
NurseryReport. This method is intended to be used by callers to
introspect into the current state of the utxo nursery. With this
information, callers will be able to ascertain: the number of immature
outputs, the total number of funds in limbo, and when funds can be
fully swept.
This commit adds to new index buckets to the undo nursery: one that
allows searching the preschool bucket by origin chan point, and another
that allows querying the kindergarten bucket using an identical key.
These index buckets are updated in tandem with their regular buckets.
A note has been named in this commit to re-work the bucket structure
for a time in the near future in which we have implemented full
on-chain HTLC handling.
This commit adds an additional field to the kidOutput struct: the
outpoint of the channel that originally created the output. This field
is now needed in order to add some additional indexes that are required
to enable callers to query the internal state of the utxoNursery.
This commit modifies the actions of the closeObserver goroutine to
utilize a _new_ channel to send channel close details over. The
original close signal channel is still used to notify observers that a
channel _has_ been closed, but this new channel will provide a single
observer with details w.r.t _how_ a channel was closed.
This commit adds an additional field to the ForceCloseSummary that
allows observers of the channel that sends this struct to track _which_
channel the force close came from.
This commit adds some additional fields to the PendingChannels RPC s.t
users will be able to use the RPC to gain a complete view w.r.t where
all the funds within the daemon are, and how soon they can be
retrieved.
The following information is now returned:
* all channels pending open
* all channels pending cooperative close
* all channels pending force close
This commit fixes a bug that would possibly result in tens of goroutine
beaching launched in an attempt to persistently connect to a peer. This
bug has been fixed by ensuring that we’ll only launch a new pending
connection attempt if we don’t already have one pending.
This commit adds a new method to the database which allows callers to
mark a channel as fully closed once certain conditions have been
reached. If a channel was cooperatively closed, then it can be marked
as fully closed as soon as the channel has been confirmed. If the
channel was marked as force closed, then it should be marked as closed
as soon as _all_ the funds in limbo have been swept.
This commit builds upon the prior commit by adding a new method to
allows callers to query the state of all closed (fully) and pending
closed channel within the database.
This commit expands the close summaries within the database to include
additional information such as: how the channel was closed, if the
channel if fully closed, and other balance information. This new
information will be used in an upcoming expansion of the
pendingChannels RPC to display more comprehensive data w.r.t where the
node’s funds are and how soon they’ll be fully available.
The data stored in the closeChannel bucket has been expanded to include
the above. Additionally the CloseChannel method on the OpenChannel
struct now takes in the additional information that details how and who
it was closed by.
This commit borrows heavily from the initial work in #179 by @halseth.
The recent multi-chain features resulted in a new directory structure
that wasn’t properly observed by the integration tests. This commit
fixes a prior bug that wouldn’t allow the test to copy the prior
revoked channels to the current state.
This commit fixes a bug introduced by the new multi-chain features of
and which disallowed multiple nodes from beings started locally.
Previously if two local nodes were set to, the _same_ chain, then
they’d both share the same chain data directory which would prevent one
of the nodes from being able to start up properly.
This commit modifies the initialization logic within lnd.go to
recognize which chain was selected by the user and to set the
parameters accordingly. With this commit, lnd is now able to switch
between chains within nothing more than a toggle of config paramters!
This commit updates the command line arguments used when launching a
node within the integration testing framework to be aware of the new
chain-specific namespace groups in the configuration options.
This commit adds the new litecoin testnet4 parameters to the set of
currently supported RPC parameters. Due to the way golfing handles
namespacing we had to implement a bit of a hack in order to allow both
litecoin and bitcoin parameters to be used within the codebase. In the
future, we may create a structure similar to chaincfg.Params _directly_
within lnd so the implementation can be a bit cleaner.
This commit modifies the existing configuration to create instances
that are capable of housing configuration options for a particular
chain such as the rpcuser or rpcpass to distinct structures within
greater configuration. With this new change, it will now be possible
for lnd to be resident on either the litecoin testnets, with simple a
toggle in the main configuration.
The new configuration file will look like the following:
[Bitcoin]
bitcoin.active
bitcoin.testnet=1
bitcoin.rpcuser=kek
bitcoin.rpcuass=kek
Similarly, one would mirror a similar set up in order to be active on
the latest litecoin testnet.
This commit adds a new agent to the codebase: the chainRegistry. In a
multi-chain future, the chainRegistry will be the dispatch point
capable of mapping cross-chain parameters, and a particular chain to
the chainControl for that chain. The chainControl struct encompasses
the 3 primary interfaces used within the daemon to register for events,
and drive other workflows.
In case of the situation when we receive remote announcement with
channel id which pointing out to unknown channel the announcement have
been silently rejected. Now such announcement will be added to the
waiting proof map.
Such solution has a serious drawback - by adding the announcement proof
without information about channel itself (that this announcement have
been received from the node eligible to sending it), we allow
overwriting the waiting proof map by `Eve` node.
Previously, if an error was returned during handleSingleFunderSigs or
handleFundingCounterPartySigs, the wallet would hang waiting for
the completeChan channel to be populated. This commit adds nil returns for
the completeChan when errors are propagated.
This commit is meant to fix an occasional flake in the interrogation
tests cause by the async nature of the cancellation of block epoch
notifications. This commit modifies the cancellation to now be fully
synchronous which should eliminate this flake.
This commit updates the version of btcwallet that and is pinned against
to point to a version that includes a bug fix that was noticed in the
latest upstream PR’s we’ve included. The culprit bug would attempt to
create a write transaction inside of a greater read transaction which
would cause boltdb to block indefinitely internally. roasbeef’s fork of
btcwallet has been updated to include this fix.
The prior methods we employed to handle persistent connections could
result in the following situation: both peers come up, and
_concurrently_ establish connection to each other. With the prior
logic, at this point, both connections would be terminated as each peer
would go to kill the connection of the other peer. In order to resolve
this issue in this commit, we’ve re-written the way we handle
persistent connections.
The eliminate the issue described above, in the case of concurrent peer
connection, we now use a deterministic method to decide _which_
connection should be closed. The following rule governs which
connection should be closed: the connection of the peer with the
“smaller” public key should be closed. With this rule we now avoid the
issue described above.
Additionally, each peer now gains a peerTerminationWatcher which waits
until a peer has been disconnected, and then cleans up all resources
allocated to the peer, notifies relevant sub-systems of its demise, and
finally handles re-connecting to the peer if it's persistent. This
replaces the goroutine that was spawned in the old version of
peer.Disconnect().
This commit adds a new method to the peer struct: WaitForDisconnect().
This method is put in place to be used by wallers to synchronize the
ending of a peer’s lifetime. A follow up commit will utilize this new
method to re-write the way we handle persistent peer connections.
