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.
This commit slightly modifies the handling of the Connect RPC to allow
users to omit the port when specifying the target node to connect to.
If the port isn’t specified, then the default p2p port will be used in
place.
Added the signer which will be needed in the funding manager to sign
the lnwaire announcement message before sending them to discovery
package. Also in the future the message signer will be used to sign
the users data.
Originally we adding the edge without proof in order to able to use it
for payments path constrcution. This method will allow us to populate
the announcement proof after the exchange of the half proofs and
constrcutrion of full proof finished.
In case if the channel shouldn't be announced to the rest of the network
the proof, which is needed to announce the channel, will not be
populated, fot that reason the ability to store the empty proof has
been added.
Change the name of fields of messages which are belong to the discovery
subsystem in a such way so they were the same with the names that are
defined in the specification.
In this commit announcement signature message has been added which is
needed when peers want to announce their channel to the rest of the
network. This message acts as half proof carrier, nodes exchanges
their half proofs with each other and after that they are able to
construct the full proof.
Add usage of the 'discovery' package in the lnd, now discovery service
will be handle all lnwire announcement messages and send them to the
remote party.
In this commit the routing package was divided on two separete one,
this was done because 'routing' package start take too much responsibily
on themself, so with following commit:
Routing pacakge:
Enitites:
* channeldb.ChannelEdge
* channeldb.ChannelPolicy
* channeldb.NodeLightning
Responsibilities:
* send topology notification
* find payment paths
* send payment
* apply topology changes to the graph
* prune graph
* validate that funding point exist and corresponds to given one
* to be the source of topology data
Discovery package:
Entities:
* lnwire.AnnounceSignature
* lnwire.ChannelAnnouncement
* lnwire.NodeAnnouncement
* lnwire.ChannelUpdateAnnouncement
Responsibilities:
* validate announcement signatures
* sync topology with newly connected peers
* handle the premature annoucement
* redirect topology changes to the router susbsystem
* broadcast announcement to the rest of the network
* exchange channel announcement proofs
Before that moment all that was in the 'routing' which is quite big for
one subsystem.
split
