This commit adds a PendingCommitTicker to the link config, which allows
us to control how quickly we fail the link if the commitment dance
stalls. Now that the mailbox has the ability to cancel packets, when the
link fails it will reset the mailbox packets on exit, forcing a
reevaluation of the HTLCs against their mailbox expiries.
This is less brittle than blacklisting states since it may not be clear
that new states needs to be added. Now that HasChanStatus is fixed for
ChanStatusDefault, we can safely implement this.
The linter complains about not checking the return value from
WipeChannel in certain places. Instead of checking we simply remove the
returned error because the in-memory modifications cannot fail.
We'll only do so when we have at least one confirmed advertised channel
with the remote peer. This ensures that our node announcement can
propagate throughout the network even for nodes that were offline when
we initially broadcast it.
Add an error buffer to the peer struct which will store errors for
peers that we have active channels with. We do not store these errors
with peers that we do not have channels open with to prevent peers from
connecting and costlessly spamming us with error messages. When the peer
disconnects, the error buffer is offloaded to the server so that we can
track errors across connections. When peers reconnect, they are created
with their historic error buffer.
If a peer receives a channel reestablish message shortly after the
channel has been closed, it will resend its own channel reestablish
message. In the meantime the other peer could also have seen the channel
being closed and will also resend its own message. This leads to a
resend loop that never terminates.
To avoid two peers getting into this situation, we now allow only one
such resent message per conection.
This commit adds two new channel statuses which indicate the party that
initatited closing the channel. These statuses are set in conjunction
with the existing commit broadcast status so that we do not need to
migrate existing logic to handle multiple types of closes. This status
is set for locally initiated force closes in this commit because they
follow a similar pattern to cooparative closes, marking the commitment
broadcast then proceeding with tx broadcast. Remote force closes are
added in the following commit, as they are handled differently.
In this commit, a htlcNotifier interface is added to allow for easy
unit testing. Instances of the HtlcNotifier are added to the server,
switch and link.
This commit is adapted from @Bluetegu's original
pull request #1462.
This commit reads an optional address to pay funds out to
from a user iniitiated close channel address. If the channel
already has a shutdown script set, the request will fail if
an address is provided. Otherwise, the cooperative close will
pay out to the address provided.
In this commit, we start to clamp the max HTLC forwarding policy to the
current register max HTLC payment size. By doing this, we ensure that
any links that have a advertised max HTLC transit size above the max
payment size will reject any incoming or outgoing attempts for such
large payments.
This commit sets our close addresss to the address
specified by option upfront shutdown, if specified,
and disconnects from peers that fail to provide
their upfront shutdown address for coopertaive closes
of channels that were opened with the option set.
Without waiting, we would proceed to retrieve the remote peer's
supported features, which may have not been set due to not yet receiving
their Init message.
This prevents the DLP protocol from breaking as a result of the
refactor, since the closing or closed channels won't be included in the
peer's active map.
When loading active channels for a connected peer, we gather channel
sync messages for all borked channels, and send them to the peer. This
should help a peer realize that the state is irreconcible, as we have
already realized.
Since we will now wait to deliver the event after channel reestablish,
notifying when the link is added to the switch will no longer be
sufficient. Later, we will add receiving reestablish as an additional
requirement for EligibleToForward returning true.
The inactive ntfn is also moved, to ensure that we don't fire inactive
notifications if no corresponding active notification was sent.
In this commit, we begin to enforce a maximum channel commitment fee for
channel initiators when attempting to update their commitment fee. Now,
if the new commitment fee happens to exceed their maximum, then a fee
update of the maximum fee allocation will be proposed instead if needed.
A default of up to 50% of the channel initiator's balance is enforced
for the maximum channel commitment fee. It can be modified through the
`--max-channel-fee-allocation` CLI flag.
Debug invoices are rarely used nowadays, but keep asking for maintenance
every time refactoring in primarily the invoice registry occurs. We have
passed the cost/benefit tipping point, so therefore the debug invoice
concept is removed in this commit.
Previously the debughtlc flag also controlled whether hodl masks were
active. It is safe to remove that additional condition because the hodl
masks are still guarded by the dev build tag.
We stopped requesting this from other nodes as it is very expensive as
the graph continues to grow. In this commit we will also stop
responding, as nodes are recommended to begin using the `gossip_queries`
and upcoming `extended_gossip_queries` to reconcile missing graph data.
This commit is the final step in making the link unaware of invoices. It
now purely offers the htlc to the invoice registry and follows
instructions from the invoice registry about how and when to respond to
the htlc.
The change also fixes a bug where upon restart, hodl htlcs were
subjected to the invoice minimum cltv delta requirement again. If the
block height has increased in the mean while, the htlc would be canceled
back.
Furthermore the invoice registry interaction is aligned between link and
contract resolvers.
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 modifies sendMessage to break on the server's quit channel,
which allows synchronous callers of SendMessage or SendLazyMessage to
receive an error during server shutdown which can be independent of a
particular peer's shutdown.
As of https://github.com/lightningnetwork/lnd/pull/2916, all replies
made by gossip syncers were modified to be synchronous. In certain
cases, This would prevent the syncers from shutting down promptly, as
they would try to offload a batch a of messages that could not be
aborted. Now, an error will be propagated back to the caller, allowing
them to detect the error condition, and reevaluate their own quit
signals, releasing any waitgrouped goroutines and permitting a quick
shutdown.
As a prepatory step to making gossip replies synchronous, we will move
the ErrPeerExiting error into the lnpeer package so that it can be
imported by the discovery package. With synchronous sends, this error
can now be detected and handled by goroutines in the syncer, and cause
them to exit instead of continue to sending backlogs.
