This commit refactors the existing chainntnfns package in order to
allow more easily allow integration into the main system, by allowing
one to gain access to a set of end-to-end tests for a particular
ChainNotifier implementation.
In order to achieve this, the existing set of tests for the only
concrete implementation (`BtcdNoitifer`) have been refactored to test
against all “registered” notifier interfaces registered. This is
achieved by creating the concept of a “driver” for each concrete
`ChainNotifer` implementation. Once a the package of a particular
driver is imported, solely for the side effects, the init() method
automatically registers the driver.
Additionally, the documentation in various areas of the package have
been cleaned up a bit.
This commit adds some new networkHarness helper methods which are
mean’t to reduce the verbosity of the previous basic tests, and also to
enable developers to right tests mote easily five a higher level
interface.
This commit increases the robustness of the current test and also
reduces it’s running time considerably as all “time.Sleep”s have now
been removed.
Rather than sleeping some random amount of time, the test now waits for
a particular async notification to be dispatched before proceeding.
This tightens up the execution of the tests quite a bit.
This commit adds a new feature to the network harness enabling callers
to receive async notifications once a particular transaction is seen on
the network. Such a feature is useful when due to the asynchronous
behavior of node communications.
With this new feature, tests can now wait for a particular transaction
to be seen within the network before proceeding.
This commit updates the response handling of the steaming RPC’s to
account for the fact that multiple messages from the server (state
updates) can now be sent over the stream instead of a single final
update.
Currently, all updates other than the “final” update are ignored by the
cli.
This commit modifies the internal workflow for opening or closing a
channel in order to create a path in which RPC clients can receive
updates. Updates are now communicated via channels from the goroutines
spawned by the RPC server to process the request, and the sub-system
within the daemon that actually executes the request.
With this change clients can now receive updates that the request is
pending (final message has been sent to the target client), or that the
request has been completed. Confirmation related updates have not yet
been implemented as that will require some changes to the ChainNotifier
interface.
This commit speeds up the integration test initialization by launching
the processes of the two seeder nodes concurrently rather than
serially.
Additionally, the harness will now block until the wallets of both the
seeder nodes are fully synced up.
This commit modifies the prior protos to make the open/close channel
RPC commands return the “union” status update rather than a concrete
item of that union directly. With this change, RPC clients can now
receive status updates of the current state of the opening or closing
channel.
This commit fixes the build for version 1.6.3 of golang. In go 1.7, the
“context” package was moved into the standard library, however go 1.6.3
doesn’t have that change, so we must refer to the prior WIP package
until a new version of Go is released.
This commit introduces a simple piece of infrastructure for integration
testing: the networkHarness.
The harness allows for the creation and orchestration of a small
testbed of lnd nodes. The harness includes an instance of btcd’s
rpctest.Harness which allows driving certain actions in a mock Bitcoin
network to exercise relevant lnd behavior(s). By default, the harness
creates two instances of lnd (Alice and Bob), then establishes a
peer-to-peer connection between them. Created lnd nodes within the test
network can be driven programmatically by gRPC connections to their
respective RPC severs.
Later on more features will be added such as adding additional nodes,
opening channels between nodes, creating scripting topologies, etc,
This commit adds an option to pass in a raw hex-encoded rpc cert via
lnd’s configuration file. Such a change allows for programmatically
creating lnd nodes which can connect to an existing btcd instance
without requiring a file for the rpc cert to be specified.
Additionally, this commit makes the creation of an integration testing
harness easier.
This commit revamps the existing docker configuration to allow for
developer’s to easily bring up/down a Lightning Network testbed
environment.
Configuration related bugs within the prior swarm set up have been
fixed. The launched lnd nodes are now able to properly communicate with
the primary btcd node over RPC. The auto-generated RPC script has been
scrapped in favor of hard-coding a developer-only set of RPC
credentials. With this change, it’s now possible to add/remove
additional lnd nodes in order to test more complex scenarios.
Additionally, the containers now build off of the latest Go version
(1.7).
This commit fixes an omission within the htlcSwitch. With this commit,
a channels bandwidth is now properly updated once an incoming HTLC is
settled.
This also fixes a bug where if a node received a payment, it wouldn’t
be able to then utilize the newly available bandwidth to send further
payments.
This commit fixes a bug in the lockTimeToSequence function when mapping
a block-based relative lock time to the proper sequence number.
Applying the mask isn’t necessary since the values are expected to be
blow 65K blocks.
This commit integrates BitFury's current routing functionality into lnd. The
primary ochestration point for the routing sub-system in the routingMgr. The
routingMgr manages all persistent and volatile state related to routing within
the network.
Newly opened channels, either when the initiator or responder are inserted into
the routing table once the channel is fully open. Once new links are inserted
the routingMgr can then perform path selection in order to locate an "optimal"
path to a target destination.
This commit optimizes the previous deadlock bug-fix within the peer’s
channelManager which handles driving the LCP state machine with
additional context-specific state.
Rather than forwarding to the HTLC switch within the primary loop which
handles fully locked-in HTLCs, we now launch a distinct goroutine which
is responsible for properly forwarding lock-in HTLC’s to the
htlcSwitch.
This commit adds a basic test for cooperative channel closure. The
current test ensures correctness of the cooperative closure procedure
initiated by either the channel initiator, or the channel responder.
The original project has been migrated to a new user. Currently git
redirects are served from the old repository to the newness. However
since development has witched to this new repository we update our
imports for clarity.
This commit updates the previous travis CI config to pin against the
two latest golang versions, and perform installation via Glide.
Additionally, this should allow lnwallet’s integration tests to build
properly as the btcd binary will be available in the build process’
PATH.
This commit fixes a concurrency bug between the server’s htlc switch,
and an instance of a peer’s active htlc manager goroutine.
The deadlock condition was triggered when the htlc manager’s downstream
`htlcPacket` channel was full, causing the htlcSwitch’s main loop to
block on a send while the htlcManager was attempting to send a packet
to the switch for forwarding. This scenario created a circular
dependency resting in a deadlock.
The fix for this bug is relatively straight forward, if the destination
interface is found when handling an outgoing payment, then a new
goroutine is spawned to complete the request.
This commit updates the build, installation, and upgrade instructions to use
Glide which allows for reproducible builds using Golang 1.5 or 1.6.
As a result, if one wishes to ensure they've properly installed lnd, the `go
get` command can no longer be used to install lnd.
This commit adds glide integration in order to make lnd builds fully
reproducible. Rather than using “go get” users should now manually pull down
the repo, use glide to fetch+install the dependancies, then manually install
all related binaries.
With this change we no longer have to chase dependancies making breaking API
changes under us. We can manually update the managed dependancies once a new
stable release of a defendant package is released.
Additionally, reproducible builds are a strong requirement in order to securely
distribute future major releases of lnd.
This commit *significantly increases* the payment throughput per-core,
per-channel of the daemon.
With this commit updates are properly pipelined respecting the current
revocation window, htlc updates are batched, a timer is checked to push
chain convergence, and htlc update below the batch size are
periodically flushed to the remote chain.
The current pending update timer, trickle timer, and batch size have
been arbitrarily chosen based on my local tests. In the future these
parameters should be chosen to optimize response-time and throughput
after measurements are gathered.
This commit adds a new method, “PendingUpdates” to the channel state
machine which is intended to be a source to give callers a hint as to
when an additional commitment signature should be sent independent of
any request/response book keeping.
This commit patrons the state update logs properly within the channel
state machine. This change fixes a number of bugs caused by treating a
central log as two logically distinct logs. Rather than having a bit
indicating if the entry is incoming/outgoing, an entry is added to a
remote or local log depending on which modification method is used.
As a result the code is much easier to follow due to separation of
concerts.
Finally, when attempting to sign a new update with an exhausted
renovation window a distinct error is returned in order to allow higher
level callers to properly back-off and handle the protocol event.
