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.
This commit fixes a bug that resulted from properly failing to do a
2-value read from the confirmation notification channel. If the
ChainNotifier was shutting down, then a nil read could be generated
which may prematurely mark the channel as open, and also trigger a nil
pointer panic exception below when the confDetails are accessed.
We fix this issue, by ensuring that we check the second value to see if
the channel has been closed or not.
This commit renames routing processing method in the funding mangers
config from ProcessRoutingMessage to SendToRouter and also modifies the
signature to only require the message itself and not the server’s
identity public key.
When the funding transaction has been confirmed, the FundingLocked
message is sent by the peers to each other so that the existence of the
newly funded channel can be announced to the network.
This commit also removes the SingleFundingOpenProof message.
Once a channel funding process has advanced to the point of broadcasting
the funding transaction, the state of the channel should be persisted
so that the nodes can disconnect or go down without having to wait for the
funding transaction to be confirmed on the blockchain.
Previously, the finalization of the funding process was handled by a
combination of the funding manager, the peer and the wallet, but if
the remote peer is no longer online or no longer connected, this flow
will no longer work. This commit moves all funding steps following
the transaction broadcast into the funding manager, which is available
as long as the daemon is running.
In order to facilitate persistence during the funding process, added
the isPending flag to channels so that when the daemon restarts, we can
properly re-initialize the chain notifier and update the state of
channels that were going through the funding process.
