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.
In this commit, we add a new legacy protocol command line flag:
`committweak`. When set, this forces the node to NOT signal usage of the
new commitment format. This allows us to test that we're able to
properly establish channels with legacy nodes. Within the server, we'll
now gate our signalling of this new feature based on the legacy protocol
config. Finally, when accepting/initiating a new channel funding, we'll
now check both the local and remote global feature bits, only using the
new commitment format if both signal the global feature bit.
In this commit, we update the router and link to support users
updating the max HTLC policy for their channels. By updating these internal
systems before updating the RPC server and lncli, we protect users from
being shown an option that doesn't actually work.
The policy update logic that resided part in the gossiper and
part in the rpc server is extracted into its own object.
This prepares for additional validation logic to be added for policy
updates that would otherwise make the gossiper heavier.
It is also a small first step towards separation of our own channel data
from the rest of the graph.
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 add a new build tag protected sub-config for legacy
protocol features. The goal of this addition is to be able to default to
new feature within lnd, but expose hooks at the config level to allow
integration tests to force the old behavior to ensure that we're able to
support both the old+new versions.
htlcs
config: Adding RejectHTLC field in config struct
This commit adds a RejectHTLC field in the config struct in config.go.
This allows the user to run lnd as a node that does not accept onward
HTLCs.
htlcswitch/switch: Adding a field RejectHTLC to the switch config
This commit adds a field RejectHTLC to the switch config. When the
switch receives an HTLC it will check this flag and if the HTLC is not
from the source hop, the HTLC will be rejected.
htlcswitch/switch: adding check for RejectHTLC flag and incomingChanID
This commit adds a check when receiving UpdateAddHTLC. The check looks
for the RejectHTLC flag set and whether the HTLC is from the sourceHop
(the local switch). If the HTLC is not from the sourceHop, then we
reject the HTLC and return a FailChannelDisabled error.
server: adding RejectHTLC field to initialization of switch
lnd_test: adding test for RejectHTLC
This commit adds a test which tests that a node with the --rejecthtlc
flag will reject any onward HTLCs but still can receive direct HTLCs and
can send HTLCs.
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.
This commit adds the ignore-historical-filters CLI option, initially
defaulting to false. Users may use this option to prevent lnd from doing
historical gossip dumps to peers that set their `gossip_timestamp_range`
in the past. Enabling this option will result in lower bandwidth and
memory consumption. Down the road the plan is to make this default to
true.
With the introduction of the WatchtowerClient RPC subserver, the lnd
configuration flag to specify private watchtowers for the client is no
longer needed and can lead to confusion upon users. Therefore, we remove
the flag completely, and only rely on the watchtower client being active
through a new --wtclient.active flag.
This commit makes the outgoing link pipeline the settle to the
switch as soon as it receives it. Previously, it would wait for a
revocation before sending it, which caused increased latency on
payments as well as possibly never settling on the incoming link.
A duplicate settle is still sent to the switch, but it is handled
gracefully. A new AckEventTicker was added to the switch which
acknowledges any pending settle / fail entries in an outgoing
link's fwd pkgs in batch. This was needed in order to reduce the
number of db txn's which would have been incurred by acking whenever
we receive a duplicate settle without batching.
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.
In this commit we add exponential back off to the `initialPeerBootstrap`
method. Before this change, if the DNS seed was down, we would hammer it
in an attempt to get our initial set of peers. This makes this section a
bit less aggressive, but saves log spam and also will hit the DNS
servers less frequently.
This commit moves the newSweepPkScript function
previously in the nursery to be a helper function
within the server. Additionally, the function now
returns a closure that satisfies the configuration
interfaces of several other subsystems.
As a result, the configuration sites contain much
less boilerplate, as it's now encapsulated in
the newSweepPkScriptGen helper.
This commit exposes the three main parameters that influence mission
control and path finding to the user as command line or config file
flags. It allows for fine-tuning for optimal results.
