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.
This commit adds a ticker which attempts to print the total volume
sent/recv over the last 10 seconds if any updates took place during
that interval.
Additionally, when selecting a link to forward an htlcPacket insert a
break after selection in order to properly terminate the loop.
We now close the send payment stream after receiving a response.
Otherwise if the RPC server is asynchronously handling requests then,
closing the stream would result in the server returning an EOF error,
terminating the request.
This commit changes the current behavior around channeldb.Wipe().
Previously if a channel had never been closed, and a wipe was
attempted, then wipe operation would fail and the transaction would be
rolled back.
This commit fixes this behavior by checking for bolt.ErrBucketNotFound
error, and handling the specific error as a noop.
With this commit, calls to htlcSwitch.SendHTLC() are now synchronous,
only returning after the payment has been fully settled. This will
allow one to accurately measure the commitment update speed with the
current state machine implementation which is missing a number of
low-hanging optimizations.
The htlcManager for each channel now keeps a map of cleared HTLC’s
keyed by the index number of the add entry within the state machine’s
HTLC log. This map of HTLC’s will later be used to properly implement
time outs
Additionally, a slight refactoring has been executed w.r.t handling
upstream/downstream messages. This cleans up the main htlcManager loop,
freeing it up for the addition of future logic to properly observe
timeouts as well as, proper batching+trickling of HTLC updates, and a
commitment signature ticker.
This commit fixes a slight bug in the channel state machine’s code
executed when processing a revocation messages. With this commit after
processing a revocation, log entries which we should forward to the
downstream or upstream peer for settling/adding HTLC’s are now properly
returned.
The testa have also been updated to ensure to correct htlc’s are
returned “for forwarding”.
This commit adds two Dockerfiles, along with a docker-compose file
which links the two docker files together allowing for single-command
deployment.
Using the docker-compose file, two containers are deployed. One running
btcd, and the other running lnd. Both containers share the same shared
volume mounted to the file system in order to allow land to read btcd’s
certificates for the TLS RPC connections.
Additionally, the btcd instance comes will an automatic RPC
configuration generated allowing one to use btcctl out of the box via
calls to “docker-compose exec btcctl …”.
With this commit, support for changing the target network (testnet,
simnet, etc) has been finalized. Previously a command line option was
present to swap networks, but the RPC port wouldn’t automatically be
updated to reflect the network.
With this commitment, the daemon is now able to properly send+redeem
single-hop HTLC’s with another daemon running on the same network.
The htlcManager gains an additional channel which is reads from
receiving updates from either downstream peers, or the rpc server. An
htlcManager is spawned for each active channel with the remote peer. As
a result, the readHandler must now de-multiplex any messages which
update a known channel to the proper htlcManager.
Batching HTLC add updates with a trickle timer has not yet been
implemented, but will be in the near future along with several other
optimizations.
