This commit alters the NodeAlias String method to trim null-bytes from
the end of the alias. This is helpful for presentation in contexts such
as the GetInfo response.
This commit factors out the btcd and ltcd options into their own sections
similar to neutrino, and adds a bitcoind section as well. Now, you specify
node options similarly to:
--ltcd.rpchost=...
or
--btcd.rpcuser=...
or
--bitcoind.zmqpath=...
For Bitcoin, you specify an alternate back-end to btcd as follows:
--bitcoin.node=bitcoind
or
--bitcoin.node=neutrino
You can also specify the default option:
--bitcoin.node=btcd
For Litecoin, only `btcd` mode is valid, and corresponds to the `ltcd`
section. For example:
--litecoin.node=btcd
--ltcd.rpchost=...
The new code also attempts to read the correct options and auth info
from bitcoin.conf just as it does from btcd.conf/ltcd.conf.
This commit adds a new integration test, that checks that
policy/fee updates get propagated properly in the network,
such that the other nodes learn about the changes.
This commit extracts the launching of a goroutine subscribing
to and forwarding graph topology notifications into its own
utility method, such that it can be used in other tests as
well.
This commit ensures that we always increment the timestamp of
ChannelUpdates we send telling the network about changes to
our channel policy. We do this because it could happen
(especially during tests) that we issued an update, but the
ChannelUpdate would have the same timestamp as our last
ChannelUpdate, and would be ignored by the network.
This commit makes the value returned fomr NumRequiredConfs
and RequiredRemoteDelay used during the funding process scale
linearly with the channel size. This is done to ensure that
in cases there are more at stake in a channel, we have more
time to react to reorgs, or unilateral closes.
If the user explicitly specified values for these two at
startup, we return those instead, without doing the scaling.
This commit defines minRemoteDelay and maxRemoteDelay,
which is the extremes of the CSV delay we will require
the remote to use for its commitment transaction. The
actual delay we will require will be somewhere between
these values, depending on channel size.
This commit moves the definition of DefaultNumChanConfs into
the chainConfig (such that it is set as e.g.
"--bitcoin.defaultchanconfs"), making it possible to set
individually for different chains.
It also adds the flag DefaultRemoteDelay to the chainConfig,
which can be used to set the CSV delay we will require the remote
to wait before retrieving its own funds in case of an
uncooperative close of the channel.
Both these are set 0 by default (if not specified by the user),
which in that case we will dynamically set the values, scaling
them according to the channel size.
This commit removes the definitions of
defaultBitcoinForwardingPolicy and defaultLitecoinForwardingPolicy
from the the chainregistry, and instead creates a routingPolicy
from the values found in the config.
This commit moves the forwarding policy rules for Bitcoin
and Litecoin, previously defined in the chainregistry, to
config.go, making them possible to define by the user.
We validate that the TimeLockDelta set is at least 4, the
other rules we let the user specify arbitrarily, even 0.
This commit makes the fundingmanager read the minHtlc
field of the initFundingMsg, and add it to the reservation
as this node's htlc_minimum_msat for the open_channel
message. If the field is not specified in the initFundingMsg,
the default value found in the DefaultRoutingPolicy will
be used.
This commit changes the name of the UpdateFee method to
UpdateChannelPolicy, to mimic the recent proto change.
It also reads and validates the passed TimeLockDelta,
and sends it to the gossiper for announcing it to the
network, and to the switch for updating the forwarding
policy of the links.
This commit renames the UpdateFee RPC call together
with associated types to UpdateChannelPolicy. In addition
to fees, now also timelock delta can be specified using
this call.
In this commit, we fix an existing bug that could cause lnd to crash if
we sent a payment, and the *destination* sent a temp channel failure
error message. When handling such a message, we’ll look in the nextHop
map to see which channel was *after* the node that sent the payment.
However, if the destination sends this error, then there’ll be no entry
in this map.
To address this case, we now add a prevHop map. If we attempt to lookup
a node in the nextHop map, and they don’t have an entry, then we’ll
consult the prevHop map.
We also update the set of tests to ensure that we’re properly setting
both the prevHop map and the nextHop map.
