This commit adds some new functionality to the channel router: the
ability to dispatch notification to registered clients upon either a
channel being closed, a new node appearing, or an exiting client being
updated or opened for the first time.
With this change, the integration tests will now be able to eliminate
most of the sleep as we gain a new syntonization point into the
propagation of information within the test network. Additionally, this
also paves the way for client side software to dynamically visualize
the channel graph in real-time as nodes+channels are updated.
This commit modifies the path finding routines to properly use the new
channel edge related API exposed by the database. Additionally, a new
type `ChannelHop` has been introduced which couples an edges routing
policy with the capacity and origin chain of the channel.
This commit modifies the ChannelUpdateAnnouncement to rename the Expiry
variable instead of TimeLockDelta as that is more descriptive of the
purpose of the attribute itself.
This commit updates all the RPC’s that deal with querying for data
stored within the graph to the latest version of the public API for the
graph itself.
This commit alters the return value of PrunedGraph to me a bit more
useful: the function now returns all the channels that were closed when
processing the block (slice of spent outpoints). With this information,
callers gain greater visibility into exactly which channels were
closed. This can be used in higher levels to present detailed summaries
of how blocks affect closed channels.
This commit splits the prior ChannelEdge struct into two distinct
structs: ChannelEdgeInfo and ChannelEdgePolicy. The info structs stores
the _full_ information that was used to advertise the channel, while
the policy struct contains the information that’s needed in order to
use the information for routing purposes.
With this split we can eliminate a number of hacks within the rest of
the codebase that were added as a result of data unavailability if one
or neither edge was present.
Finally a bit of field renaming has taken place (Exipiry ->
TimeLockDelta), etc.
This commit fixes a minor bug that was introduced with the latest PR
that made specifying the —push_amt flag when opening a channel
mandatory. The fix is simple, turn the switch statement into an
if/else, which makes the —push_amt flag optional once again.
This commit updates the command line help for several commands within
cmd/lncli to be more uniform, and also use the proper attributes within
the urfave/cli project. Additionally, in several areas cli.Int was using
used instead of cli.Int64 when parsing satoshis. This oversight has been
rectified by modifying all incorrect occurrences.
Finally, this commit, as its central contribution, adds the ability to mix
and match positional arguments with key-word arguments for several
commands! The following commands can now be used with either only
positional arguments, only key-word arguments, or a mix of both when
applicable:
* openchannel
* closechannel
* sendpayment
* getnodeinfo
* getchaninfo
* newaddress
* sendcoins
* sendmany
* connect
* addinvoice
* lookupinvoice
* queryroute
The set of changes outlined above should make command line tinkering with
`lnd` a bit more streamlined, yet still very flexible.
This commit adds a basic set of instructions for installing the necessary
gRPC dependencies to be able to drive `lnd` from node.js. In the future,
this section will be expanded with additional example
scripts/applications.
This commit adds a basic set of instructions for installing the necessary
gRPC dependencies to be able to drive `lnd` using Python. In the future,
this section will be expanded with additional example
scripts/applications.
This commit modifies the `ecdh` function within the `brontide` package
to refer directly to the global curve params object in the `bcec`
package rather than reference it from the target public key. This
changes fixes a class of panics that have been uncovered recently but
*doesn’t* yet fix the root cause.
This commit modifies the protobuf file and most of the auto-generated
files to be generated by protoc version v3.0.2. Additionally, this
fixes a minor cosmetic regression within the `lncli` command line tool
which caused the JSON responses to be rendered in `camelCase` rather
than `snake_case`. We fix this by specifying the `json_name` for each
relevant RPC response.
This commit fixes a class of bug that currently exists within the
cooperative closure methods for the channel state machine. As an
example, due to the current hard coded fees, if one of the outputs
generated within the generated closure transaction has a negative
output, then the initiating node would gladly forward this to the
remote node. The remote node would then reject the closure as the
transaction is invalid. However, the act of completing the closure
would cause the remote node’s state machine to shift into a “closed”
state. As a result, any further closure attempts by the first node
(force or regular) would go unnoticed by the remote node.
We fix this issue by ensuring the transaction is “sane” before
initiating of completing a cooperative channel closure.
At test case has been added exercising the particular erroneous case
reported by “moli” on IRC.
This commit avoids a class of bug wherein the state of the channel
would be marked as closing enough though an error occurred somewhere in
the function. The bug was due to the fact that the channel `status` was
shifted before any actual logic within the function(s) were executed.
We fix this bug by _only_ shifting the channel status once the function
has completed without any error.
This commit fixes a bug that resulted from properly failing to do a
2-value read from the confirmation notification channel. If the
ChainNotifier was shutting down, then a nil read could be generated
which may prematurely mark the channel as open, and also trigger a nil
pointer panic exception below when the confDetails are accessed.
We fix this issue, by ensuring that we check the second value to see if
the channel has been closed or not.
This commit modifies the peer struct’s loadActiveChannels method to
ensure that it skips over channels that aren’t actually active. This
fixes a bug that could possibly cause a peer to get stuck in a circular
wait loop and also de-sync a channel’s state machine.
This commit renames routing processing method in the funding mangers
config from ProcessRoutingMessage to SendToRouter and also modifies the
signature to only require the message itself and not the server’s
identity public key.
With the funding manager’s state gaining full durability, it only will
return channels that are currently “pending” as a response to the
PendingChannels RPC call. As a result, the prior edge case where a user
would issue a PendingChannels RPC call mid funding flow is no longer
possible and channels are read from disk rather then from the
fundingMgr’s limbo state.
With the concept of open/pending channels on disk, we now will no
longer show channels under ListChannels that are still pending. This
fixes a slight existing bug wherein channels that weren’t yet open
would be listed in this RPC call since we write to disk immediately
after broadcasting the funding transaction.
This commit adds a new method to the channel’s state machine:
NextRevocationKey. This method is being added in preparation for the
upcoming change to switch to the commitment transaction format outlined
in the spec. When this comes to pass, the ExtendRevocationWindow method
will be removed, as it will no longer be needed.
The NextRevocationKey method will be needed as to conform to the spec,
we’ll need to send the next revocation key within the `fundingLocked`
message.
This commit contains a series of post-merge fixes which include:
* ToBytes -> Encode
* As the former version doesn’t _require_ allocation of new slices *
* Store -> AddNextEntry
* To communicate to the caller that entries MUST be added
in order
* Several grammar, spacing, spelling and gofmt fixes.
This commit adds the FundingManagerPersistence test to ensure that the
funding process completes as expected when nodes shutdown after the the
funding transaction has been broadcast. Note that the final parts of
several wallet tests have been removed, as functionality has been moved
to the Funding Manager and should now be tested there.
When the funding transaction has been confirmed, the FundingLocked
message is sent by the peers to each other so that the existence of the
newly funded channel can be announced to the network.
This commit also removes the SingleFundingOpenProof message.
Once a channel funding process has advanced to the point of broadcasting
the funding transaction, the state of the channel should be persisted
so that the nodes can disconnect or go down without having to wait for the
funding transaction to be confirmed on the blockchain.
Previously, the finalization of the funding process was handled by a
combination of the funding manager, the peer and the wallet, but if
the remote peer is no longer online or no longer connected, this flow
will no longer work. This commit moves all funding steps following
the transaction broadcast into the funding manager, which is available
as long as the daemon is running.
Because we want to persist the state of the channel once the funding
transaction has been broadcast rather than once it has been fully
opened, we need to report the funding transaction ID to the UI or tests
when the transaction is pending, rather than after it has been
confirmed.
When a pending channel is persisted and then reloaded upon system startup
it's necessary to also persist the number of confirmations that will be required
before the pending channel can be opened.
In order to facilitate persistence during the funding process, added
the isPending flag to channels so that when the daemon restarts, we can
properly re-initialize the chain notifier and update the state of
channels that were going through the funding process.
In this commit the initial implementation of revocation hash
generation 'elkrem' was replaced with 'shachain' Rusty Russel
implementation which currently enshrined in the spec. This alghoritm has
the same asymptotic characteristics but has more complex scheme
to determine wish hash we can drop and what needs to be stored
in order to be able to achive full compression.
