In this commit, we verify that ChannelUpdates for newly
funded channels contain the max HTLC that we expect.
We expect the max HTLC value of each ChannelUpdate to
equal the maximum pending msats in HTLCs required by
the remote peer.
Co-authored-by: Johan T. Halseth <johanth@gmail.com>
Previously, nursery generated and published its own sweep txes. It
stored the sweep tx in nursery_store to prevent a new tx with a new
sweep address from being generated on restart.
In this commit, sweep generation and publication is removed from nursery
and delegated to the sweeper. Also the confirmation notification is
received from the sweeper.
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.).
This commit adds TestFundingManagerCustomChannelParameters, which checks
that custom channel parameters specified at channel creation is
preserved and recorded correctly on both sides of the channel.
Note: This commit also creates a function called
assertFundingMsgSent, which replaces checkNodeSendingFundingLocked
by doing the same work not just for FundingLocked messages but
also for AcceptChannel, FundingCreated, and FundingLocked messages.
initiated by the user doesn't timeout.
Split assertNumPendingChannels into assertNumPendingChannelsRemains,
and assertNumPendingChannelsRemains to prevent possible false
positives passing tests
This commit makes more channel constraints available
via closures part of the fundingConfig, moving them
from the reservation.RemoteChanConstraints method.
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 modify the interaction between the chanCloser
sub-system and the chain notifier all together. This fixes a series of
bugs as before this commit, we wouldn’t be able to detect if the remote
party actually broadcasted *any* of the transactions that we signed off
upon. This would be rejected to the user by having a “zombie” channel
close that would never actually be resolved.
Rather than the chanCloser watching for on-chain closes, we’ll now open
up a co-op close context to the chainWatcher (via a layer of
indirection via the ChainArbitrator), and report to it all possible
closes that we’ve signed. The chainWatcher will then be able to launch
a goroutine to properly update the database state once any of the
possible closure transactions confirms.
This commit make the fundingmanager tests poll for database state
for a time, instead of using an explicit sleep before accessing the
DB. This should address some of the flakes encountered on Travis,
where db writes might take longer than usual.
This commit cleans the fundingManager tests by extracting
most of the common code from the different test cases into
assert methods, making the test cases easier to follow
and distinguish.
It also adds a new test for the case where the peer goes
offline, and the fundingManager must wait for it to come
online before it can send the fundingLocked message and
continue the funding flow.
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 the fee negotiation procedure performed
on channel shutdown. The current algorithm picks an ideal
a fee based on the FeeEstimator and commit weigth, then
accepts the remote's fee if it is at most 50%-200% away
from the ideal. The fee negotiation procedure is similar
both as sender and receiver of the initial shutdown
message, and this commit also make both sides use the
same code path for handling these messages.
This commit adds the +build !rpctest build flag to the test files in
the main package other than the RPC tests. With this, if the protest
build flag is set, then ONLY those tests will be run.
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.
