In this commit, we alter the different chain notifiers to query their
height hint cache before registering a confimation notification. We do
this as it's possible that the cache has a higher height hint, which
can potentially reduce the amount of blocked fetched when attempting
historical dispatches.
In this commit, we extend our TxConfNotifier to cache height hints for
our confirmation events. Each transaction we've requested a confirmation
notification for will have its initial height hint cached. We increment
this height hint at every new block for unconfirmed transactions. This
allows us to retrieve the *exact* height at which the transaction has
been included in a block. By doing this, we optimize the different
ChainNotifier implementations since they will no longer have to scan
forward (and possibly fetch blocks in the neutrino/pruned node case)
from the initial height hint looking for the confirmation.
In this commit, we introduce two new interfaces: SpendHintCache and
ConfirmHintCache for a height hint cache. The SpendHintCache is
responsible for maintaining the earliest height at which an outpoint
could have been spent within the chain, while the ConfirmHintCache is
responsible for maintaining the earliest height at which a transaction
confirms within the chain. We also add an implementation of these
interfaces with a single struct HeightHintCache, backed by a channeldb
instance, which will cary the duties of the interfaces above.
This commit loosens the fwdpkg reference acking to be more tolerant
of prior deletions. Specifically, we won't fail if certain channels
are not found or fwdpkgs do not exist. This will make us more
tolerant to future changes where we:
- remove fwdpkgs on channel close
- defensively cleanup stray responses
In this commit, we address an issue that could arise when using the
SendToRoute RPC. In this RPC, we specify the exact hops that a payment
should take. However, within the switch, we would set a constraint for
the first hop to be any hop as long as the first peer was at the end of
it. This would cause discrepancies when attempting to use the RPC as the
payment would actually go through another hop with the same peer. We fix
this by explicitly specifying the channel ID of the first hop.
Fixes#1500.
Fixes#1515.
In this commit, we modify the readHandler w/in
the mock peer to drop messages if it is unable
to find the target link. This has led to observed
race conditions related to removing a link and still
attempting to deliver messages. By removing this,
the readHandler shouldn't fail the test as a result.
This commit increases the fwdpkg garbage collection
interval to 15s, to mitigate the likelihood of it
interfering with our unit tests related to fwdpkgs.
This commit removes the concept of "circuit deletion
forgivness" from the link. This was originally
implemented due to the strict semantics of the original
DeleteCircuit implementation, which would fail if we tried
to delete unknown circuits. Forgivness is used on startup
to ignore this error in case the circuits had already been
deleted before shutting down.
Now that the circuit deletion has been relaxed, this
behavior is no longer necessary, as requests to delete
unknown (or previously deleted) circuits will be ignored.
This is necessary for future changes regarding switch
cleanup, which may attempt to cleanup already deleted
circuits.
Previously, we would only allow deletion of circuits if all circuit keys
were found in the pending map.
In this commit, we relax this to allow for deletion of any circuits
that are found pending, and ignore those that are not found. This
is a preliminary step to cleaning up duplicate forwards that get caught
by the switch. It also allows us to gracefully handle any nodes that
are still afflicted by the split mailbox issue.
Replaces the log statement in CommitCircuits so that
it prints the circuit key of the incoming channel. This way
we avoid spewing the secp curve stored in the ErrorEncrypter.
This commit adds a goroutine watchChannelStatus to the server, which
will query the switch for the status of all open channels every
InactiveChanTimeout / 4. If a channel's status has remained unchanged
during the last InactiveChanTimeout it'll send out a ChannelUpdate
setting the disabled bit accordingly.
This commit changes the test testSendUpdateDisableChannel to use Dave to
listen for channel updates, as was originally intended.
Since a ChannelUpdate won't propagate in the network if the channel is
already closed (if the closing transaction has been mined), we change
the closing procedure to initiate the closing process, wait for the
ChannelUpdates, then finally mining the closing transaction. This avoids
a propagation race between the mined block and the ChannelUpdate.
ProcessLocalAnnouncement will attempt to call UpdateEdge with the new
policy. If we call it manually before handing it to the gossiper, that
call will fail with "Outdated" and the announcement won't propagate.
