This commit slightly modifies the channel reservation workflow to
expose the new information conerning the exact confirmation location of
the channel provided by the ChainNotifier. The DispatchChan() method of
the ChannelReservation now also returns the blockHeight and txIndex
where the transaction was ultimately confirmed. This information will
be needed by the fundingManager so it can properly generate the
authenticated channel announcement proofs.
Within the inner loop of the utxoNursery when waiting for a new
sweepable transaction to be confirmed, we now use the new ChainNotifier
API for ConfirmationEvent’s which exposes additional details as to
exactly where in the chain the transaction was ultimately confirmed.
This commit updates the BtcdNotifier implementation of the
ChainNotifier by including the details of a transaction’s confirmation
within the ConfirmationEvent struct sent once a registered txid has
reached a sufficient number of confirmation.
This commit modifies the ChainNotifier interface, specifically the
ConfirmationEvent struct to now return additional details concerning
the exact location in the chain that the transaction was confirmed at.
This information will be very useful within the new routing package, as
within the network, channels are identified via their channel-ID which
is a compact encoding of: blockHeight | txIndex | outputIndex
This commit fixes a minor bug in the ForEachChannel method of the
ChannelGraph struct. Rather than ErrGraphNoEdgesFound being returned if
either of the edge related buckets hadn’t been created yet,
ErrGraphNodesNotFound was being returned.
To fix this bug, we now properly return ErrGraphNoEdgesFound.
Additionally a mental note to roasbeef has been left as the current
code currently assumes that eventually both directions of the channel
edge will be advertised. However, this may not necessarily be the case
in a live network, since a side chooses to preferentially advertise a
channel or not.
This commit fixes a bug within the btcwallet implementation of the
BlockChainIO interface. The exact nature of the bug was a rounding
error that would only manifest if the value of the UTXO was below 1
BTC.
The tests within this package currently test channels with mostly whole
values of BTC, as a result the bug went unnoticed until now.
The fix itself is trivial: convert to an int64 AFTER performing the
multiplication to convert to satoshis from Bitcoin.
This commit removes the previous test cases which excised the proper
validation of graph announcements on the network. As full generation of
the authenticated messages has not yet been implemented, these tests
aren’t currently applicable.
In a future commit, these tests will be replicated on the new discovery
package which will handle producing the channel proofs and also fully
validating them.
This commit modifies the Alias type to only hold the non-zero portion
of the alias as encoded on the wire. Previously the entire 32-bytes
would be read and stored, including the zeroes at the end used as
padding. Within the constructor, we now parse the alias properly,
discarding the trailing zeroes within the passed byte slice.
Additionally, the .String() method of Alias will now also only print
the non-zero prefix of the decoded alias.
This commit temporarily disables the signature validation for all
announcement related messages which should be authenticated by one or
many parties. This feature is being disabled as we don’t yet generate
valid signatures for our advertisements and the validation of the
messages should be placed in the layer 3 discovery service rather than
within within the message parsing layer.
This commit modifies the attributes of the LightningChannel struct to
publicly expose the funding keys used within the channel for the local
and remote party. Exposing these keys publicly will allow callers to
use the keys involved to generate authenticated channel advertisements
for the routing layer.
This commit adds to new functions to the ChannelGraph struct which
allow the callers to query for the existence or non-existence of a
vertex (node) or edge (channel) within the graph. In addition to
returning whether the edge exists, the functions will also return the
last time the state has been modified for the edge or vertex. This will
allow callers to ensure that only the most up to date state is
committed to disk.
This commit expands the data returned by the current GetCurrentHeight
to also return the current best block hash, expanding the method into
GetBestBlock. Additionally, the current best BlockHash is also now
displayed within the GetInfo RPC call.
This commit separates out the ChannelID into a new file, with
additional helper methods for conversion and formatting. With this
commit, the struct is now more general purpose and can be used in the
new routing package, database, and other related sub-systems.
This commit adds some additional measures to ensure that a call to
queueMsg while the peer is shutting down won’t result in a potential
deadlock.
Currently, during shutdown the outgoingQueue channel is attempted to be
cleared by he writeHandler, however adding an additional select
statement serves as a mother layer of defense from nasty dead locks.
This commit adds support for channel graph pruning, which is the method
used to keep the channel graph in sync with the current UTXO state. As
the channel graph is essentially simply a subset of the UTXO set, by
evaluating the channel graph with the set of outfits spent within a
block, then we’re able to prune channels that’ve been closed by
spending their funding outpoint. A new method `PruneGraph` has been
provided which implements the described functionality.
Upon start up any upper routing layers should sync forward in the chain
pruning the channel graph with each newly found block. In order to
facilitate such channel graph reconciliation a new method `PruneTip`
has been added which allows callers to query current pruning state of
the channel graph.
This commit adds an additional check within CloseChannel to ensure that
sub-systems attempting to delete the channel one after the other (in
the event of any sort of closure) doesn’t result in an extraneous
error.
To fix this, we now check if the channel exists before attempting a
deletion. If the channel doesn’t exist, then we simply exit early with
a nil error.
This commit modifies the LightningNode.ForEachChannel method to give
the caller the option of re-using an existing database transaction
instead of always creating a new db transaction with each invocation.
Internally boltdb will run into an error/dead-lock if a nested
transaction is attempted.
Such an action might be attempted if one were to use the traversal
functions in a path finding algorithm. Therefore in order to avoid
that after, we now allow the re-use of transactions to facilitate
nested calls to ForEachChannel.
Go-fmt files. Refactored code according to the guidelines.
Enhanced payment test: add error checking
and individual context for each API call.
Add Timestamp field to payment struct.
Within the utoxNursery we now use a two value read fro the block epoch
channel in order to exit early if/when the ChainNotifier begins the
shutdown process before the signal reaches the utxoNursery.
This commit modifies the Stop method of the default ChainNotifier
client, the BtcdNotifier. We now close the notificaiton channel for all
the currently active block epoch clients in order to give clients a
signal that the entire daemon and possibly the ChainNotifier is
shutting down. This gives clients an extra signal to more thoroughly
implement a graceful shutdown across the daemon.
This commit revamps the way in bound and outbound connections are
handled within lnd. Instead of manually managing listening goroutines
and also outbound connections, all the duty is now assigned to the
connmgr, a new btcsuite package.
The connmgr now handles accepting inbound (brontide) connections and
communicates with the server to hand off new connections via a
callback. Additionally, any outbound connection attempt is now made
persistent by default, with the assumption that (for right now),
connections are only to be made to peers we wish to make connections
to. Finally, on start-up we now attempt to connection to all/any of our
direct channel counter parties in order to promote the availability of
our channels to the daemon itself and any RPC users.
This commit fixes a htlcSwitch bandwidth update bug that would manifest
when two sending daemons were started with the —debughtlc flag. The
invoice created for the debug HTLC has a value of 1000BTC. As a result
regardless of the amount sent, the switch’s state which be updated to
reflect that the daemon had just received a 1000BTC transfer.
To fix this bug, we now use the value of the HTLC itself for the
update, rather than the value if the invoice as they should match.
This commit fixes a lingering bug within the channel funding
reservation workflow that caused the address of a channel counter-party
to not be written to disk, resulting in an error on start up. To fix
this, we now properly populate the node’s TCP address when initiating
the reservation.
This commit fixes a bug in our key derivation for the final step of the
key exchange. In our code we were swapping the order of the salt and
input keyeing material to the HKDF function. This was triggered by the
argument order of the golang implementation we’re currently using has
the “secret” of IKM argument first, instead of second as defined within
rfc5869.
To fix this, we simply need to swap function arguments in two places:
within the split() function and during key rotation.
This bug was discovered by Rusty Russell, thanks!
