In this commit, we fix an existing bug in the funding manager, that can
be triggered if the user is connecting to a node over Tor, and then
attempts to open a channel. An existing fix was added for the case that
the receiving node established the channel, but this now makes that case
symmetric.
This commit changes the failFundingFlow to accept an error, which will
only be sent to the remote the peer if it is among the
ReservationErrors or ErrorCode. This is done to ensure we don't send
errors that contain information we don't want to leak.
This commit adds wallet_best_block_timestamp to the gRPC interface.
This is done in order to allow clients to calculate progress while
lnd syncs to the blockchain. wallet_best_block_timestamp is exposed
via the GetInfo() rpc call. Additionally, IsSynced() returns the
WalletBestBlockTimestamp as the second value in the tuple
that is returned, providing additional detail when querying about the
status of the sync. The BtcWallet interface has also been updated
accordingly.
This commit was created to support the issue to
[Add progress bar for chain sync] (lightninglabs/lightning-app#10) in
lightning-app
This commit makes more channel constraints available
via closures part of the fundingConfig, moving them
from the reservation.RemoteChanConstraints method.
This commit adds the `lnnet` package which contains an
implementation of the newly created LightningNet interface which
multiplexes the Dial and DNS-related functions to use net
by default and torsvc if a flag is specified. This modularization
makes for cleaner code.
In this commit, we fix an existing bug that would result in some
payments getting “stuck”. This would happen if one side restarted
before the channel was fully locked in. In this case, since upon
re-connection, the link will get added to the switch with a *short
channel ID of zero*. If A then tries to make a multi-hop payment
through B, B will fail to forward the payment, as it’ll mistakenly
think that the payment originated from a local-subsystem as the channel
ID is zero. A short channel ID of zero is used to map local payments
back to their caller.
With fix this by allowing the funding manager to dynamically update the
short channel ID of a link after it discovers the short channel ID.
In this commit, we fix a second instance of reported “stuck” payments
by users.
In this commit, we fix an existing bug within the funding manager. A
channel barrier only needs to be create if upon startup the channel is
still pending. Otherwise, we’ll re-create the funding barrier
unnecessarily. This can lead to bugs when initiating payments between a
channels’ lock in and when it’s announced to the together network. If
during this period, a user attempts a payment, then the response won’t
be archived, as the grouting will be blocked waiting on the channel
barrier to close.
To fix this, we only re-create the barrier if the channel hasn’t been
confirmed.
This eliminates one source of reported “stuck payments”.
In this commit, we modify the logic executed when we decide that we
need to fail a funding flow. Before this commit, if the remote party
disconnected while we were attempting to fail the funding flow with an
error. Then we'd never actually cancel the reservation. This meant that
any inputs selected for that transaction would be locked until a
restart.
We fix this issue by always cancelling the reservation first, and
ensuring that failure to cancel the reservation doesn't prevent us from
sending the error.
Partially addresses #710.
Since a ChannelPoint's funding txid can now be get/set as raw bytes or
a string, we first need to check what type it's currently set to before
accessing it.
We no longer need to hand off new channels that come online as the
chainWatcher will be persistent, and always have an active signal for
the entire lifetime of the channel.
This commit defines minRemoteDelay and maxRemoteDelay,
which is the extremes of the CSV delay we will require
the remote to use for its commitment transaction. The
actual delay we will require will be somewhere between
these values, depending on channel size.
This commit makes the fundingmanager read the minHtlc
field of the initFundingMsg, and add it to the reservation
as this node's htlc_minimum_msat for the open_channel
message. If the field is not specified in the initFundingMsg,
the default value found in the DefaultRoutingPolicy will
be used.
This commits slightly rewrites the newly introduced
logic for private channels. Instead of keeping the
channel announce preference in a database within
fundingManager, it is stored as part of the
OpenChannel struct.
In addition, the ChanOpenStatus_Open update is now
sent after the channel is added to the router, instead
of waiting until the 6 blocks confirmation has passed.
This commit introduces some new interdependent functionality. As
soon as the fundingLocked message is sent, the channel is
immediately added to the ChannelRouter's internal topology.
Finally, channels are now only broadcasted to the greater
network after six confirmations on the funding transaction
has been reached.
In this commit, we ensure that we actually advertise our desired value
for the smallest HTLC we’ll accept as incoming. Before this commit, the
value advertised was always zero.
In this commit, we implement a recent spec change that require nodes to
advertise the minHTLC of the remote node within their ChannelUpdate. We
do this as it will be the remote node which carries the HTLC towards
us, therefore we should advertise *their* minHTLC value.
In this commit, we fix an existing issue that could at times cause an
inconsistent view between the set of total coins, and the set of segwit
coins in the wallet of the node. This could be caused by initiating a
funding flow, but then the funding negotiation breaking down somewhere
along the lines. In this case, us or the other peer will disconnect.
When we initiate funding flows, we lock coins exclusively, to ensure
that concurrent funding flows don’t end up double spending the same
coin. Before this commit, we wouldn’t ever unlock those coins. As a
result, our view of available coins would be skewed.
The walletbalance call would show all the coins, but when adding the
—witness_only flag, some coins would be missing, or gone all together.
This is because the former call actually scans the txstore and manually
tallies the amount of available coins, while the latter looks at the
sent of available outputs, which is filtered based on which coins are
locked.
To remedy this, we now ensure that when a peer disconnects, we wipe all
existing reservations which will return any locked outputs to the set
of available outputs for funding flows.
There is a sleep after channels are opened to ensure the channel is
removed from the set of pending reservations. We can avoid this sleep
and get better guarantees of the channel being opened by deleting the
reservation just before updating channel state to active instead of
after.
This commit decouples the wait for funding transaction confirmations
in the waitForFundingConfirmation function from the announcement of
the channel in the sendFundingLockedAndAnnounceChannel function.
Additionally, the sendFundingLockedAndAnnounceChannel function is
now decoupled into the sendFundingLocked and sendChannelAnnouncement
functions. There is also now a helper function that houses creation
of a lnwire.LightningChannel object, calls to both sendFundingLocked
and sendChannelAnnouncement.
This commit adds a select statement for sending on the fundingManager's
arbiterChan and the peer's newChannels channel. This makes sure we won't
be blocked sending on these channels in case of a shutdown.
The fundingManager will register with the server to get notified
when the targetted peer comes online, in case of a failed send
of the fundingLocked message. This is necessary because if the
peer is not connected yet (or was disconnected while we were
waiting for the funding tx to confirm), we cannot continue the
the opening process before the peer successfully has received
the fundingLocked.
This commit adds a channel barrier on fundingManager startup for
channels where the opening process is not finished. This fixes
a bug where we after restarting the fundingManager would receive
the fundingLocked message, and crash when trying to close the
non-existing barrier.
In case we received a fundingLocked message after our own opening
process was finished, we would crash with the same error. We
therefore check if the channel barrier exists before we try to
close it.
It also adds functionality to fundingManager that makes it
ignore a fundingLocked message it receives for a channel where
this is already received. This is necessary when we in case of
a reconnection resend the fundingLocked since we cannot be sure
the remote has received it.
The fundingmanager tests are also updated to check that the
fundingLocked messages are sent and handled correcly, and also
exercise the scanarios described above.
This commit adds a conditional send on quit to all methods used by
outside sub-systems to the funding manager. This ensures, that in the
case the funding manager is exiting, the caller won’t block
indefinitely.
This commit corrects a minor formatting error when logging the pending
channel ID within the logs. Previously, the logging directives and
parameter could cause the pending chan ID to display in a double-hex
encoded format. We fix this by ensuring that we properly slice the chan
ID before printing it, and also ensure that we use the %x formatting
(which will hex encode the bytes) everywhere.
Fixes#331.
This commit implements some missing functionality as we’ll now properly
validate and generate the various channel flow control constraints
during initial channel funding.
With this commit, we take an additional step towards full spec
compliance as we’ll now properly send over the required channel
reservation, max HTLC’s, and other parameters during the funding flow.
When processing the desired parameters by the remote party, if we think
they’re unreasonable, then we’ll send an Error message and end the
funding flow.
Previously, our old lnwire.Error message used a special code to
indicate different types of errors. With the recent push for spec
compatibility, we removed this field and instead stuffed the error into
the first byte of the error data. This works between lnd nodes, but
with other implementations they may send different errors which use a
different error scheme.
To fix this, we’ll now unconditionally return the error to the end
caller (if one exists).
This commit fixes a prior goroutine leak that could result in a node
having thousands of goroutines, particularly due to many concurrent
channel fundings. We now ensure that for each BlockEpoch client
created, we ensure that the client is cancelled once the creating
grouting exits.
This commit updates the tail end of the funding workflow to properly
include the ChainHash field when crafting ChannelAnnouncements and the
initial ChannelUpdate messages. Additionally, we now properly generate
the proper signatures to match the changes to BOLT0007.
This commit modifies the generation and parsing of errors to abandon
usage of the Code field, and instead use the first byte of the Data
field to store the error codes that we currently use. With this change,
we ensure that our error messages properly match BOLT-0002.
Persists the state of a channel opening process after funding
transaction is confirmed. This tracks the messages sent to
the peer such that the process can be continued in case of a
restart. Also introduces that the receiver side forgets about
channel if funding transaction is not confirmed in 48hrs.
Make the fundingmanager send an updated node announcement
each time it opens a new channel. This is to make sure
our node announcement is propagated in the network, since
peers will ignore our node announcements if we haven't
opened any channels yet.
This commit ensures that we always clean up the resources that are
created when a new instance of a lnwallet.LightningChannel is
instantiated. The is necessary due to the sigPool that’s now present as
an internal goroutine.
This commit updates the main single-funder funding workflow within the
fundingManager (initiated via the rpcserver or by a message from a
connected peer) to fully adhere to the funding protocol outlined in
BOLT-0002.
The major changes are as follows:
* All messages modified to use the new funding messages in BOLT-0002.
* The initiator of a funding workflow no longer decides how many
confirmations must elapse before the channel can be considered open.
* Rather than each side specifying their desired CSV delay, both
sides now specify the CSV delay for the _other_ party.
This commit fixes a possible panic within the funding manger’s workflow
for pending channels. We now ensure that the local discovery signal
retrieved from the localDiscoverySignals map is always non-nil.
Otherwise, we risk a server panic in the case that a node retransmits
the FundingLocked message after a channel has been fully processed, or
even just sends a FundingLocked message for a non-existent channel.
This commit adds a new bit of synchronization to the funding manager to
ensure that we only process the funding locked message directly _after_
the short channel ID has become available within the channel. This
fixes a possible bug wherein we would receive the funding locked
message, and register the channel with the switch without yet knowing
the short chan ID. This would then cause any HTLC’s routed to the new
channel to fail, as it would be using the incorrect short channel ID.
This commit modifies the funding process to use the short channel ID,
rather than only the opening block height to mark a channel as open
once it has been confirmed. With this change, the short channel ID
information will now be available immediately after the channel has
been confirmed in the chain.
This commit modifies the funding workflow slightly to move the querying
to the fee estimator (for the new channel) into the fundingManager
rather than within the LightningWallet layer. When querying to
FeePerWeight, we now multiply by 1000 to arrive at fee-per-kw.
Additionally, we now also properly thread through the fee-per-kw
offered by the initiator the to the responder of the channel workflow.
This commit adds the FeeEstimator interface, which can be used for
future fee calculation implementations. Currently, there is only the
StaticFeeEstimator implementation, which returns the same fee rate for
any transaction.
In order to make the node's dust limit available to the wallet during
the initial stages of the funding process, add and set a
DustLimit field in the Contribution.
This commit modifies the OpenChannel structure on-disk to also track
that opening height of a channel. This change is being made in order to
make and more light client friendly. A follow up commit will modify
several areas of the codebase to use this new functionality.
This commit fixes a bug that double counts the number of pending
channels in GetInfo. Previously we weren’t yet storing the pending
channels on disk, we are now but comparing both the disk channel and
the channels within memory leads us to double count channels. To fix
this, we now only count the database channels.
Note that this NumPendingChannels method can now be removed as it’s no
longer needed.
This commit modifies the order of operations after a channel has been
detected as fully opened. Rather than waiting until we receive the
FundingLocked message to announce the channel, we now do so immediately
after we detect the channel has been opened.
Additionally, we also patch a possible dead-lock bug by ensuring that
the RevokeAndAck message is always sent _after_ the FundingLocked
message. We do this by only passing the newly created channel too the
relevant sub-systems _after_ we receive the FundingLocked message. This
movement also serves to pave the way for our switch to the spec’s
funding workflow, as once we remove the initial revocation window,
there’ll be no way for us to initiate a state transition until we
receive the FundingLocked message from the remote party.
This commit modifies the way the fundingManager tracks pending funding
workflows internally. Rather than using the old auto-incrementing
64-bit pending channel ID’s, we now use a 32-byte pending channel ID
which is generated using a CSPRG. Additionally, once the final funding
message has been sent, we now de-multiplex the FundingLocked message
according to the new Channel ID’s which replace the old ChannelPoint’s
and are exactly 32-bytes long.
This commit modifies the fundingManager config to use the a SignMesage
function rather than two distinct functions for singing one half the
channel announcement proofs. This change unifies the signing of
messages under a single abstraction: the MessageSigner interface.
This commit implements some minor coding style, commenting and naming
clean up after the recent major discovery service was merged into the
codebase.
Highlights of the naming changes:
* fundingManager.SendToDiscovery -> SendAnnouncement
* discovery.Discovery -> discovery.AuthenticatedGossiper
The rest of the changes consist primary of grammar fixes and proper
column wrapping.
Change the name of fields of messages which are belong to the discovery
subsystem in a such way so they were the same with the names that are
defined in the specification.
Add usage of the 'discovery' package in the lnd, now discovery service
will be handle all lnwire announcement messages and send them to the
remote party.
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.
