This commit fixes an unnoticed bug within btcwallet’s implementation of
the BlockChainIO interface, specifically the GetUtxo method. In order
to maintain compatibility with Bitcoin Core’s gettxout method, btcd
doesn’t return an error if the targeted output is actually spent.
We weren’t properly detecting this, but we do now by creating a new
error which is returned in the case of a nil error but a nil return
value.
This commit modifies the SingleFundingOpen message to include the
compact channel ID of the finalized transaction rather than a “fake”
SPV proof. This change is a stop-gap which allows us to implement
portions of BOLT07 without yet fully implementing all parts of BOLT[02,
03].
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
This commit removes the older routing/discovery messages from the
unwire package, as we’ll be converging towards BOLT07 in the near-term.
In the mid to far term we’ll be revisiting integrating Flare into the
newer scheme in order to take advantage of its scaling characteristics.
This commit modifies the FetchChannelEdgesByID slightly to use a
read-only transaction rather than a write-only transaction. As a result
we’ll no longer extraneously consume a writer’s slot when we’re only
reading data from the database.
This commit modifies the HasChannelEdge function to _always_ return
true if we know of the channel edge, meaning that it was previously
added on announce.
This change fixes a minor bug present in the code which would result in
extraneous re-transmissions of updates received by the new routing
package.
This commit adds a utility method whcih utilizes the edge index bucket
and allows caller to look up the channel ID of a channel by its funding
outpoint. This can be used to populate RPC’s with additional
information and also to provide users with an additional query
interface to build channel explorers, etc.
Previously, the edge index bucket which maps a channelPoint ->
channelID wasn’t properly created one start up during the initial
creation of the database. This caused some extraneous failure as
queries would unnecessarily fail with bucket non-existence errors.
To fix this we now properly create the bucket on start up if the
database doesn’t exist, and also properly delete the bucket within the
Wipe() function.
This commit modifies the historical dispatch workflow slightly to also
obtain the full block in which the transaction was confirmed we we can
fully populate the full TxConfirmations struct which was recently added
as part of the confirmation subscription API.
With this change, confirmation triggers that a reached while the demon
is down, will now be deliver exactly as if the trigger was reached
while the daemon was up.
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!
