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.
This commit modifies the way we go about unlocking the wallet. With the
latest changes to the API of btcwallet, we can on longer directly
access the waddrmgr struct. As a result, we’re now forced to go
_directly_ via the wallet to unlock the waddrmgr. The root
LightingWallet has been modified to not request the root key until we
finish starting the underlying wallet, so we can unlock the wallet in
the Start() method.
This commit modifies the initialization logic of the LightningWallet to
fetch the root key during startup rather than during creation. We make
this change in order to give enough time for the underlying
WalletController to properly boot up before we ask it to do any work.
We now pin gRPC against a particular commit version as it seems that
glide has some trouble properly resolving the semantic versioning
constraints for the latest version of gRPC.
This commit updates the version of btcwallet to the newest version
available in roasbeef’s fork. This new version includes the following
changes:
* a fix for the ping/pong deadlock issue with an expiring session
* and a preliminary merging of r btcsuite/btcwallet#469 into
roasbeef’s fork
The first change should solve an issue of lnd’s internal wallet
(btcwallet) being disconnected from the local btcd node. And the second
change should improve the reliability/correctness of the wallet as the
wtxmgr (tx/utxo store) and the waddrmgr (key store) are now updated
under a _single_ database transaction.
This commit modifies both readMessage and writeMessage to be further
message oriented. This means that message will be read and written _as
a whole_ rather than piece wise. This also fixes two bugs: the
readHandler could be blocked due to an sync read, and the writeHandler
would unnecessarily chunk up wire messages into distinct crypto
messages rather than writing it in one swoop.
Also with these series of changes, we’re now able to properly parse
messages that have been padded out with additional data as is allowed
by the current specification draft.
This commit modifies ReadMessage to no longer return the total bytes
read as this value will now be calculated at a higher level. The
io.Reader that’s passed to ReadMessage is expected to contain the
_entire_ message rather than be a pointer into a stream that contains
the message itself.
This commit adds a new message to the brontide.Conn struct which allows
callers to read an _entire_ message from the stream. As defined now,
brontide is a message crypto messaging protocol. Previously the only
method that allowed callers to read attempted to hide this feature with
a stream-like abstraction. However, having this as the sole interface
is at odds with the message oriented Lightning wire protocol, and isn’t
sufficient to allow parsing messages that have been padded as is
allowed by the protocol.
This new ReadNextMessage is intended to be used by higher level systems
which implement the Lightning p2p protocol.
