This commit fixes a potential issue within the fundingmanager, where
failing to write the channel opening state could cause the channel being
marked open in the DB, but the opening state not being set. On startup
this would cause the channel state machine to not be able to resume.
We fix this by saving the channel opening state _first_. This works
because saving the opening state is idempotent, and in case a channel is
found pending at startup, it will re-register for confirmation
notifications and re-do the process.
Since the advanceFundingState now can handle pending channels, we'll
call it for both pending and non-pending channels, just making sure that
we re-initialize the channel barriers and re-publish the funding tx fro
pending channels.
This commit makes advanceFundingState check whether a channel is still
pending before checking the channel opening state. This lets us call it
directly, without checking whether a channel has confirmed first.
This commit makes the waitForFundingTimeout method synchronous, and
return ErrConfirmationTimeout in case the timeout is reached.
We also simplify the internals by using waitForTimout defined earlier.
This commit defines a new method waitForTimeout, that will be used to
listen for channels timing out. It handles a subset of what is already
handled by waitForFundingWithTimeout, but we want to break that one up
in smaller parts, and waitForTimeout is the first of these.
Since waitForFundingConfirmation is always called in a goroutine, we
make this explicit by requireing the caller to always increment the
waitgroup before calling it.
Similarly to what we did in the previous commit, we move the
responsibility of marking the channel open by calling
handleFundingConfirmation out from waitForFundingWithTimeout to the
caller.
This commit moves the handling of a funding confirmation out of
waitForFundingConfirmation, and instead let the caller handle marking
the channel opened.
This commit moves the opening logic found within
waitForFundingConfirmation into a new method handleFundingConfirmation.
This will make it easier to later break up waitForFundingConfirmation,
and avoid code duplication.
This commit removes the handleFundingConfirmation method, and instead
hands the newly confirmed channel of to advanceFundingState, which will
take the channel through the rest of the channel opening flow.
Since the advanceFundingSigned now can resume a channel from any state,
we resue the logic in handleFundingSigned instead of manually executing
each step of the funding flow.
This commit make the advanceFundingStateMethod synchronous. It will now
query the database for a channel's opening state, and call the method
stateStep until the channel has finished the opening procedure.
This commit extracts the funding state check we do at startup into a new
method advanceFundingState. In later commits we will modify this method
to work for all funding state machine flows, not only on restart.
Since the ErrorCodes are not part of the spec, they cannot be read by
other implementations.
Instead of only sending the error code we therefore send the complete
error message. This will have the same effect at the client, as it will
just get the full error instead of the code indicating which error it
is. It will also be compatible with other impls.
Note that the GRPC error codes will change, since we don't set them
anymore.
This commit makes the funding manager access the MaxPendingChannels and
RejectPush values from the fundingConfig instead of the global config
struct.
Done to avoid sharing state between tests.
The previous value was set to two days, which may not be enough to
handle large fee spikes where users still which to submit channels with
a low fee and don't mind lowering their time preference. Since the
timeout is only applied to channels that we don't initiate, there's real
downside since it's not our funds that are locked up.
Now that the success resolver preimage field is always populated by the
incoming contest resolver, preimage lookups earlier in the
process (channel and channel arbitrator) can mostly be removed.
This commit serves as another stop-gap for light clients since they are
unable to obtain the capacity and channel point of graph edges. Since
they're aware of these things for their own channels, they can populate
the information within the graph themselves once each channel has been
successfully added to the graph.
In this commit, we address a lingering issue within some subsystems that
are responsible for broadcasting transactions. Previously,
ErrDoubleSpend indicated that a transaction was already included in the
mempool/chain. This error was then modified to actually be returned for
conflicting transactions, but its callers were not modified accordingly.
This would lead to conflicting transactions to be interpreted as valid,
when they shouldn't be.
This commit is a step to split the lnwallet package. It puts the Input
interface and implementations in a separate package along with all their
dependencies from lnwallet.
We are not longer validating the max_value_in_flight field set by the
remote peer, so it is not always less than the channel capacity anymore.
We therefore make sure to cap it before advertising it.
This reverts commit 4aa52d267f000f84caf912c62fc14a5b8e7cacb5.
It turns out that the other implementations set values for this field
which aren't based on the actual capacity of the channel. As a result,
we'll no reject most of their channel offerings, since they may offer a
value of a max `uint64` or something else hard coded that's above the
size of the channel. As a result, we're reverting this check for now to
maintain proper compatibility.
In this commit, we set a default max HTLC value in ChannelUpdates
sent out for newly funded channels. As a result, we also default
to setting `MessageFlags` equal to 1 in each new ChannelUpdate, since
the max HTLC field is an optional field and MessageFlags indicates
the presence of optional fields within the ChannelUpdate.
For a default max HTLC, we choose the maximum msats worth of
HTLCs that can be pending (or in-flight) on our side of the channel.
The reason for this is because the spec specifies that the max
HTLC present in a ChannelUpdate must be less than or equal to
both total channel capacity and the maximum in-flight amount set
by the peer. Since this in-flight value will always be less than
or equal to channel capacity, it is a safe spec-compliant default.
Co-authored-by: Johan T. Halseth <johanth@gmail.com>
In this commit:
* we partition lnwire.ChanUpdateFlag into two (ChanUpdateChanFlags and
ChanUpdateMsgFlags), from a uint16 to a pair of uint8's
* we rename the ChannelUpdate.Flags to ChannelFlags and add an
additional MessageFlags field, which will be used to indicate the
presence of the optional field HtlcMaximumMsat within the ChannelUpdate.
* we partition ChannelEdgePolicy.Flags into message and channel flags.
This change corresponds to the partitioning of the ChannelUpdate's Flags
field into MessageFlags and ChannelFlags.
Co-authored-by: Johan T. Halseth <johanth@gmail.com>
In this commit, we remove the per channel `sigPool` within the
`lnwallet.LightningChannel` struct. With this change, we ensure that as
the number of channels grows, the number of gouroutines idling in the
sigPool stays constant. It's the case that currently on the daemon, most
channels are likely inactive, with only a hand full actually
consistently carrying out channel updates. As a result, this change
should reduce the amount of idle CPU usage, as we have less active
goroutines in select loops.
In order to make this change, the `SigPool` itself has been publicly
exported such that outside callers can make a `SigPool` and pass it into
newly created channels. Since the sig pool now lives outside the
channel, we were also able to do away with the Stop() method on the
channel all together.
Finally, the server is the sub-system that is currently responsible for
managing the `SigPool` within lnd.
In this commit, we modify the funding manager to send our
NodeAnnouncement to our channel counterparty in the event of an
unadvertised channel. We do this to ensure that our counterparty learns
about some information about us that may aid them in one way or another
(e.g., addresses to reconnect, features supported, etc.).
In this commit, we add a caller quit channel to waitUntilChannelOpen.
This ensures that the caller won't block forever if it needs to exit
before the funding manager exits, or the channel barrier is actually
closed.
This commit fixes a bug that would make us advertise the remote's
min_htlc value in our channel update.
The min_htlc value is set by a node Alice to limit its exposure to small
HTLCs, and the channel counter party should not forward HTLCs of value
smaller than this to Alice. This means that the value a node Bob should
advertise in its ChannelUpdate, is the min_htlc value the counter party
require all HTLCs to be above.
Instead of populating the ChannelUpdate with the MinHtlc value found in
the remote constraints, we now use the value from the local constraints.
In this commit, we fix a slight bug in the existing implementation of
DeriveNextKey for btcwallet. Before this commit, we would only set the
public key, and not also the derivation path. It's important that we
also set the path information, as in the near future we'll be using the
KeyDescriptors returned from this method to create static channel back
ups. With these static backups, the key alone may be insufficient to
re-derive the private key as we may need to fallback to brute forcing in
order to re-derive the key as it's possible we add new key families in
the future.
This commit moves the responsibility for publishing the funding tx to
the network from the wallet to the funding manager. This is done to
distinguish the failure of completing the reservation within the wallet
and failure of publishing the transaction.
Earlier we could fail to broadcast the transaction, which would cause us
to fail the funding flow. This is not something we can do directly,
since the CompeteReservation call will mark the channel IsPending in the
databas.e
This commit makes sure we delete a pending channel from the set of
activeReservations within the fundingmanager immediately after the
channel is moved to the openChannelBucket in the DB. Previously we
wouldn't do this before the funding tx was confirmed, making it possible
that failing the funding flow at a later point would try to cancel a
non-existent reservation context.
callbacks
The FindPeer and SendToPeer callbacks are no longer needed within the
fundingManager due to the previous commit allowing us to send messages
to peers directly.
In this commit, we modify the existing message sending functionality
within the fundingmanager. Due to each mesage send requiring to hold the
server's lock to retrieve the peer, we might run into a case where the
lock is held for a larger than usual amount of time and would therefore
block on sending the message within the fundingmanager. We remedy this
by taking a similar approach to some recent changes within the gossiper.
We now keep track of each peer within the internal fundingmanager
messages and send messages directly to them.
In this commit, we fix an issue where we would always assume the dust
limit was Bitcoin's dust limit, rather than the active chain. This would
lead to issues when attempting to open channels on the Litecon chain.
In this commit, we add and enforce a min fee rate for commitment
transactions created, and also any updates we propose to the remote
party. It's important to note that this is only a temporary patch, as
nodes can dynamically raise their min fee rate whenever their mempool is
saturated.
Fixes#1330.
This commit changes cancelReservationCtx to gold the resMtx from start
to finish. Earlier it would lock at different times only when accessing
the maps, meaning that other goroutines (I'm looking at you
PeerTerminationWatcher) could come in and grab the context in between
locks, possibly leading to a race.
This commit moves the responsibility of sending a funding error on the
reservation error channel inside failFundingFlow, reducing the places we
need to keep track of sending it.
This commit fixes an issue in funding manager startup,
where a goroutine reads from a range value. The method in
question could cause a channel to be announced at the
wrong time.
This may have been a cause for certain channels having
phantom HTLCs before they had even received the funding
locked message from the remote peer.
This is fixed simply by using the locally scoped
variable passed in as an argument to the goroutine.
