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.
This commit does away with all the old manual message equality tests
and replace it with a single property-based test that uses the
testing/quick package. This test uses a single scenario which MUST hold
for all the messages type and all possible messages generated for those
types. As a result we are able to do away with all the prior manually
generated test data as the fuzzer to scan the input space looking for a
message that violates the scenario.
This commit abandons our old bitcoin inspired message header and
replaces it with the bare type-only message headers that’s currently
used within the draft specification. As a result the message header now
consists of only 2-bytes for the message type, then actual payload
itself. With this change, the daemon will now need to switch to a
purely message based wire protocol in order to be able to handle the
extra data that can be extended to arbitrary messages.
This commit fixes a bug lingering in the decoding of the feature
vectors which was masked by the prior method of reading the _entire_
message from the stream before parsing it. The issue was that
performing a zero-byte Read on an io.Reader that’s purely streaming
will result in an indefinite block. We fix this bug by properly using
io.ReadFull in this context.
This commit modifies the Message interface to convert the Command
method to a MsgType method that uses a new set of message type for all
the defined messages. These new messages types nearly exactly match the
message types used within the current draft of the BOLT specifications.
