Before this commit, we wouldn’t properly set the TotalFees attribute.
As a result, our sorting algorithm at the end to select candidate
routes would simply maintain the time-lock order rather than also sort
by total fees. This commit fixes this issue and also allows the test
added in the prior commit to pass.
This commit is a follow up to the prior commit: as it’s possible for
the channel_reestablish message to be sent *before* the channel has
been fully confirmed, we’ll now ensure that we process it to the link
even if the channel isn’t yet open.
In this commit, we modify the logic within loadActiveChannels to
*always* load a channel, even if it isn’t yet fully confirmed. With
this change, we ensure that we’ll always send a channel_reestablish
message upon reconnection.
Fixes#458.
In this commit, we modify the logic within the channelManager to be
able to process any retransmitted FundingLocked messages. Before this
commit, we would simply ignore any new channels sent to us, iff, we
already had an active channel with the same channel point. With the
recent change to the loadActiveChannels method in the peer, this is now
incorrect.
When a peer retransmits the FundingLocked message, it goes through to
the fundingManager. The fundingMgr will then (if we haven’t already
processed it), send the channel to the breach arbiter and also to the
peer’s channelManager. In order to handle this case properly, if we
already have the channel, we’ll check if our current channel *doesn’t*
already have the RemoteNextRevocation field set. If it doesn’t, then
this means that we haven’t yet processed the FundingLcoked message, so
we’ll process it for the first time.
This new logic will properly:
* ensure that the breachArbiter still has the most up to date channel
* allow us to update the state of the link has been added to the
switch at this point
* this link will now be eligible for forwarding after this
sequence
In this commit we revert a prior change which was added after
FundingLocked retransmission was implemented. This prior change didn’t
factor in the fact that the FundingLocked message will *only* be
re-sent after both sides receive the ChannelReestablishment message.
With the prior code, as we never added the channel to the link, we’d
never re-send the ChannelReestablishment, meaning the other side would
never send the FundingLocked message.
By unconditionally adding the channel to the switch, we ensure that
we’ll always properly retransmit the FundingLocked message.
In this commit, we further constrain the candidacy for an “active”
channel. In addition to being present within the link, it *must* also
have the RemoteNextRevocation set. Otherwise, this indicates that we
haven’t yet processed a FundingLocked message for this channel.
In this commit, when selecting a candidate link to forward a payment,
we’ll ensure that it’s actually able to take on the HTLC. Otherwise,
we’ll skip over the link itself. Currently, a link is only fully
eligible for forwarding, *after* we’ve received and fully processed the
FundingLocked message.
In this commit, we add a new method to the ChanneLink interface:
EligibleToForward. This method allows a link to be added to the switch,
but in an intermediate state which indicates that it isn’t yet ready to
forward any incoming HTLC’s.
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.
