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.
