This commit re-writes the GetNetworkInfo implenetaiton to use a single
database transaction. We’re now able to do this due to the recent
change in the API for the ChannelGraph struct and it’s related objects.
The recent change allows the passed callback to accept a db
transaction, with this, the callback is now able to issue another
traversal routine _within_ the prior one.
This commit modifies the ForEachNode on the ChannelGraph and
ForEachChannel on the LightningNode struct to accept a database
transaction as its first argument. With this change, it’ll now be
possible to implement graph traversals that typically required a nested
loop with all the vertex loaded into memory using the callback API
instead:
c.ForEachNode(nil, func(tx, node) {
node.ForEachChannel(tx, func(…) {
})
})
This commit modifies the fundingManager config to use the a SignMesage
function rather than two distinct functions for singing one half the
channel announcement proofs. This change unifies the signing of
messages under a single abstraction: the MessageSigner interface.
This commit modifies the SignAnnouncement helper function to instead
take a MessageSigner interface rather than the deprecated MessageSigner
struct. We also modify the function to explicitly take the identity
public key to use when signing.
This commit removes the now deprecated FundingSigner struct as part of
the btcwallet package, and instead replaces it within an implementation
of the MessageSigner interface.
This commit introduces the MessageSigner interface which is an abstract
object capable of signing arbitrary messages with a target public key.
This interface will be used within the daemon for: signing channel
authentication proofs, signing node/channel announcements, and also to
possibly sign arbitrary messages in the future.
This commit modifies the ConnectPeer method on the testing framework to
block (with a timeout) until the target peer is actually detected as
being connected. This was added as the peer connection logic was made
to be more asynchronous in a prior commit.
This commit fixes a pretty nasty unnoticed bug within the main
k-shortest paths algorithm loop. After a new candidate path is found,
the rootPath (the path up to the pivot node) and the spurPath (the
_new_ path after the pivot node) are to be combined into a new candiate
shortest path. The prior logic simply appended the spurPath onto the
end of the rootPath to create a slice. However, if the case that the
currnet rootPath is really a sub-path in a larger slice, then this will
mutate the underlying slice.
This bug would manifest when doing path finding and cause an infinite
loop as the slice kept growing with new spurPaths, causing the loop to
never terminate. We remedy this bug by properly create a new backing
slice, and adding the elements to them rather than incorrectly mutating
an underlying slice.
This commit fixes a bug within the k-shortest paths routine which could
result in a daemon panic when traversing a graph with particular
characteristics. Before referencing the path to create a sub-slice, we
we’re properly asserting that the length of the path was at least as
long as the current rootPath in question. We fix this by simply
ensuring the length of the slice is adequate before proceeding with the
operation.
This map was added very early on as a possible path to implement proper
retransmission. However, we now have a proper persistent retransmission
sub-system being proposed as a PR, therefore we no longer have any use
for this.
This commit patches a whole in our optimistic channel synchronization
logic by making the logCommitTimer a persistent ticker rather than one
that is activated after receiving a commitment, and disabled once we
send a new commitment ourself. In the setting of batched full-duplex
channel updates, the prior approach could at times result in a benign
state desync caused by one side being one commitment ahead of the other
because one of the nodes failed to, or was unable to provide the other
with a state update during the workflow.
This commit simplifies the channel state update handling by doing away
with the commitmentState.pendingUpdate method all together. The newly
added LightningChannel.FullySynced method replace the prior state and
also replaced all other uses of PendingUpdates.
By moving to using channel.FullySynced() we also eliminate class of
desynchronization error caused by a node failing to provide the other
side with the latest commitment state.
This commit improves the channel state machine by converting the
objective PendingUpdates method to a subjective FullySynced method
which is to be used in place of PendingUpdates. The new FullySynced
method is fully encompassing and replaces any upper state required by
the state machine which wraps this one.
The new FullySynced method is identical to PendingUpdates aside from
the fact that: it now also factors in the log message index of the
remote commitment chain, and also introduces a concept of an “owed
commitment”. A commitment chain owes a commitment if the height of the
local commitment chain is higher than that of the remote chain.
This commit removes the theirPrevPkScript field from the
LightningChannel struct all together. It’s no longer needed as the more
fundamental mutation bug has been fixed within the channel state
machine.
This commit fixes a class of bug that can arise in the channel state
machine when a very high throughput workflow is attempted. Since the
PaymentDescriptor’s within a commitment pointed directly into the log,
any changes to a payment descriptor would also be reflected in all
other ones. Due to this mutation possibility, at times, the
locateOutputIndex method would fail since the HTLC’s pkScript was
modified, causing the channel to fail.
We fix this class of bug by simply ensure that once an HTLC has been
associated with a particular commitment, then it becomes immutable.
This commit fixes a prior oversight in the implementation of
SendPayment that could result in tens of thousands of goroutines
OOM’ing an lnd daemon. Previously we didn’t limit the number of
outstanding payments that were allowed by a client. Users on machines
with a small amount of RAM were reporting crashes when sending a very
large number of payments in a consistent stream. This commit fixes this
issue by now using a semaphore to limit the number of outstanding
payments (and therefore) goroutines allowed in the SendPayment method.
This commit implements an easy optimization by using bolt db’s Batch
method when writing payment details to disk. The AddPaymnent method can
be concurrently called by thousands of grouting due to the way the
payment dispatch pipeline is architected. With this commit, we shave of
a significant amount of running time when users are sending thousands
of payments a second as what would’ve been thousands of writes can now
be coalesced into one or two writes!
This commit eliminates a possible deadlock (or repeated peer connection
failures) that can arise due to the [inbound|outbound]PeerConnected
methods holding the peer mutex too long. We now alleviate this
concurrency issue by calling s.peerConnected in an asynchronous manner.
This is safe as all operations within the method are themselves
goroutine-safe.
This commit fixes a build issue that appears when attempting to
cross-compile binaries to a 32-bit system from a 64-bit system. The
issue was that the defined max-state hint overflows a 32-bit integer. To
fix this issue, we now proeprly specify a type of a uint64 for the typed
constant.
Error `connection refused` was thrown when user tries to get "Alice" to
connect to "Bob" node due to port mismatch introduced in this change [1]
here.
This commit updates the port value to reflect the new change introduced in
[1].
Reference: [1]
72772ce4df
Chanes in this commit:
* Update references to old port value
* Omit specifying port during lncli connect
* Fix typo
This commit fixes a race condition that was introduced while fixing a
lingering bug in the logic to notify block epoch clients. The race
condition would happen as by removing the default case in the select
statement, it was now possible for the client’s block epoch client to
be closed while the routine was attempting a send on it.
We now eliminate this race condition possibility by adding a wait group
to all goroutines launched to dispatch a block epoch notification. With
this modification, the Stop() goroutine will now wait for all other
goroutine to exit before closing the block epoch channels of all
currently registered clients.
This commit removes all the prior temporary feature bits which were
only added in order to allow clients to gracefully continue functioning
in the midst of all the breaking changes that were landing in the
master branch of the project.
A common pitfall with new users setting up lnd on test net has been
observed to be the initial RPC credential set up between btcd and lnd.
As of a recent version of btcd now performs automatic RPC credential
set up by generating a random rpcuser and rpcpass on start up.
We now take advantage of this by reading the RPC credentials (if
possible and running in simmer mode). As a result, it is now possible
to simply run: `lnd—testnet` assuming a fresh installation of bcd (with
a set btcd.conf).
Fixes#68.
This commit bolsters the logging available within the lnwallet package
by include the logging from both web sockets connections, and the
wtxmgr as part of the exposed package level logging. With this, users
will gain additional avenues for obtaining debug logs from various
parts of the system.
This commit implements some minor coding style, commenting and naming
clean up after the recent major discovery service was merged into the
codebase.
Highlights of the naming changes:
* fundingManager.SendToDiscovery -> SendAnnouncement
* discovery.Discovery -> discovery.AuthenticatedGossiper
The rest of the changes consist primary of grammar fixes and proper
column wrapping.
This commit a bug introduced in the chain notifier while we were
limiting the usage of mutexes within the package. In a prior commit a
default case was introduced in the select statement in order to avoid
the possibility of the main goroutine blocking when dispatching block
epoch notification.
In order to avoid this potentially disastrous bug, we now instead
launch a new goroutine for each client to ensure that all notifications
are reliably dispatched.
