By returning a *TxWeightEstimator from each method, we now all callers
to chain the methods. This adds a bit of nice sugar when interacting
with the struct.
In this commit, we rename several of the existing WitnessType
definitions to be more descriptive than they were previously. We also
add a number of additional types which we need to handle scripts for,
but weren’t yet added before. Finally, we modify the
receiverHtlcSpendTimeout to optionally take an additional parameter to
set the locktime of the spending transaction accordingly. This final
modification allows the caller to specify that the lock time has
already been set on the main transaction.
To implement the BOLT 03 test vectors, a more powerful mockSigner is
required. The new version of mockSigner stores multiple keys and signs
the transaction outputs with the appropriate one.
This commit removes the `peerport` and `rpcport` config options and
adds `listen`, `rpclisten`, and `restlisten` options to allow setting
one or multiple interfaces to listen on for incoming connections.
It also adds a `nolisten` option to allow disabling the listener for
incoming peer connections.
When accessing a value from a byte slice, the value is returned as a
byte, which is just a uint8. When the first byte takes more than 3 bits
of space, shifting 5 bits left results in data loss.
This commit allows parseRoutingInfo to return an error when parsing a
routing info field whose length is not a multiple of 51 bytes, rather
than crash.
This commit refactors parsing each of the tagged fields of an invoice
into their own method. This makes the code easier to read and will allow
us to introduce unit tests for each parsing method.
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.
