This commit fixes a send on closed channel panic by adding additional
synchronization when cancelling the notifications for a particular
topology client. We now ensure that all goroutines belonging to a
particular topology client exit fully before we close the notification
channel in order to avoid a panic.
This commit fixes a race condition that would at times occur in the
htlcswitch.TestChannelLinkBidirectionalOneHopPayments test case. A race
condition would occur in the goroutine running ReceiveNewCommitment
compared with the grouting that would obtain the snapshot in order to
make a forwarding decision.
We fix this by creating a new public key for each new commitment
transaction such that we complete avoid the read/write race condition.
This commit increases the history size of the race condition detector
such that we will more reliably be able to recover the stack in the
case that a race condition occurs.
This commit fixes a bit of a wart in the configuration file handling
wherein if the config file isn’t found, an error was printed to stderr.
At times, this would cause the testing framework to erroneously mark as
test as failed. Instead, we now keep a particular config file error,
and check that, printing to a warning log level.
This commit adds a new method to the ChannelLink interface which is
meant to allow outside sub-system to update the forwarding policy of a
channel. This can be triggered either by a new RPC method, or
automatically by some sort of control system which seeks to optimize
fee revenue, or block off channels, etc.
This commit puts a missing piece in place by properly parsing and
validating the per hop payload received in incoming HTLC’s. When
forwarding HTLC’s we ensure that the payload recovered is consistent
with our current forwarding policy. Additionally, when we’re the “exit
node” for a payment, then we ensure that the HTLC extended matches up
with our expectation w.r.t the payment amount to be received.
This commit modifies the HopIterator interface to allow nodes that
receive incoming HTLC’s to make forwarding decisions based on the
returned peer hop information, rather than just the next hop. With this
change, we can now enforce our routing policy, and reject any HTLC’s
that violate the policy.
This commit adds a new bit of synchronization to the funding manager to
ensure that we only process the funding locked message directly _after_
the short channel ID has become available within the channel. This
fixes a possible bug wherein we would receive the funding locked
message, and register the channel with the switch without yet knowing
the short chan ID. This would then cause any HTLC’s routed to the new
channel to fail, as it would be using the incorrect short channel ID.
This commit modifies the funding process to use the short channel ID,
rather than only the opening block height to mark a channel as open
once it has been confirmed. With this change, the short channel ID
information will now be available immediately after the channel has
been confirmed in the chain.
This commit adds a new method to the routing.Route struct:
ToHopPayloads. This function will converts a complete route into the
series of per-hop payloads that is to be encoded within each HTLC using
an opaque Sphinx packet.
We can now use this function when creating the sphinx packet to
properly encoded the hop payload for each hop in the route.
This commit inches towards fully validation+adherance of the per-hop
payloads within an HTLC’s route by properly calculating the outgoing
time lock value for each hop according to the current draft
specification.
This commit modifies the OpenChannel struct to include the full short
channel ID rather than simply the opening height. This new field will
be needed by an upcoming change to uniformly switch to using short
channel ID’s when forwarding HTLC’s due to the change in per-hop
payloads.
This commit updates the OnionPacketSize constant in order to reflect
the size of the onion payload as a result of the recent changes to the
sphinx packet format in the specification.
This commit fixes a possible race condition wherein a call to
FilterBlock after a call to UpdateFilter would result in the call to
FilterBlock not yet using the updated filter. We fix this by ensuring
the internal chain filter is updated by the time the call to
FilterBlock returns.
