This commit fixes an existing bug within the ChannelRouter. Prior to
this commit, if the chain view skipped blocks or for some reason we had
a gap in blocks delivered, then we would simply accept them. This had
the potential to cause us to miss on-chain channel closure events. To
remedy this, we won’t process any blocks whose heights aren’t
*strictly* increasing.
A longer term fix would be to have the ChainView take a block height,
and re-dispatch any notifications from that height to the current
height.
In this commit, we increase the default number of confirmations we
require for funding flows from 1 to 3. The value of 1 was rather
unstable on testnet due to the frequent multi-block re-orgs.
Additionally, a value of 3 ensures our funding transaction is
sufficiently buried before we deem is usable.
This commit fixes an existing bug wherein we would blank out a node’s
color instead of properly setting the field when syncing graph state
with another node This would cause the node to reject the node
announcement and we would generate an we would invalidate the signature
of the node announcement. We fix this simply by properly setting the
node announcement.
In this commit, we fix an existing bug when processing new node
announcement. Before this commit, we wouldn’t also copy over the color
field of a node’s announcement. As a result, when went to synchronize
our graph state with that of a connecting peer, we would generate an
invalid node announcement. We fix this by properly setting the color
field of a node.
In this commit, we fix a bug that would cause the DNS seeds to be
*always* active regardless of which chain+network we were on. Before we
would look up the network in the reverseChainMap. However, if we were
on regtest or testate, then it would still (incorrectly) resolve to a
valid hash.
To remedy this, we now directly use the genesis hash of the current
active chain.
This new field was added as a recent modification to the spec, but the
curve parameter within the attribute wasn’t set to nil. As a result
this would result in a large degree of spam within the logs when set to
trace mode. This commit fixes this issue by setting it to nil along
with all the other pub keys within messages.
In this commit, we implement a recent spec change that require nodes to
advertise the minHTLC of the remote node within their ChannelUpdate. We
do this as it will be the remote node which carries the HTLC towards
us, therefore we should advertise *their* minHTLC value.
In this commit, we now properly examine the Flag field within the
ChannelUpdate message as a bitfield. Before this commit we would
manually check the flags for zero or one. This was incorrect as a their
bit has now been defined. To properly dispatch the messages, we’ll now
treat it properly as a bitmask.
In this commit, we fix an existing bug within the
createChanAnnouncement function. Before we would set the flag to be 0,
or 1 depending on which edge it was. This was incorrect as since then
additional flags have been defined. We now properly set the entire
flag, rather than taking a shortcut. With this, we’ll properly
advertise all ChannelUpdate announcements.
In this commit, we implement adherence of the disabled bit within a
ChannelUpdate during path finding. If a channel is marked as disabled,
then we won’t attempt to route through it. A test has been added to
exercise this new check.
In this commit, we update path finding to skip an edge if the amount
we’re trying to route through it is below the MinHTLC (in mSAT) value
for that node. We also add a new test to exercise this behavior. In
order for out test to work properly, we’ve modified the JSON to make
the edge to Goku have a higher min HTLC value.
In this commit, we add a new type to the lnwire package:
ChanUpdateFlag. This type represent the bitfield that’s used within the
ChannelUpdate message to give additional details as how the message
should be interpreted.
It dictates in the spec, that the error message should be an ASCII
string to allow other implementations to easily discern the type of
error. The other implementations do this, but we don’t yet, but we’ll
go ahead and display it anyway as it’s helpful when debugging.
In this commit, we fix an existing bug within the EstimateFeePerWeight
method for the BtcdFeeEstimator. If the sat/byte value returned was too
low, then it was possible for us to end up with a zero valued
sat/weight. We correct this issue by detecting, and falling back to the
default fee rate if so.
