In this commit, we modify our gossip broadcast logic to ensure that we
always will send out our own gossip messages regardless of the
filtering/feature policies of the peer.
Before this commit, it was possible that when we went to broadcast an
announcement, none of our peers actually had us as a syncer peer (lnd
terminology). In this case, the FilterGossipMsg function wouldn't do
anything, as they don't have an active timestamp filter set. When we go
to them merge the syncer map, we'd add all these peers we didn't send
to, meaning we would skip them when it came to broadcast time.
In this commit, we now split things into two phases: we'll broadcast
_our_ own announcements to all our peers, but then do the normal
filtering and chunking for the announcements we got from a remote peer.
Fixes https://github.com/lightningnetwork/lnd/issues/6531
Fixes https://github.com/lightningnetwork/lnd/issues/7223
Fixes https://github.com/lightningnetwork/lnd/issues/7073
We start with a simple Map function that can be useful for transforming
objects on the fly.
We may want to eventually make this Taro pakage into a module so we can
just have everything in one place:
https://github.com/lightninglabs/taro/tree/main/chanutils.
Ensure active nodes are synced to the latest block mined.
There are two scenarios where they might not be synced to the correct
block even when SyncedToChain is true:
1. The backend may have rejected a newly mined block (e.g., see
#7241).
2. The backend might not have fully processed the new blocks yet.
In either case SyncedToChain will (correctly) be true since the node is
indeed fully synced to the backend. This commit makes sure we detect
case 1 above, while making sure we continue to wait in case 2.
We deprecate `QueryProbability`, as it displays the same information as
`QueryMissionControl` less the probability. `QueryRoutes` still contains
the total probability of a route.
We multiply the apriori probability with a factor to take capacity into
account:
P *= 1 - 1 / [1 + exp(-(amount - cutoff)/smearing)]
The factor is a function value between 1 (small amount) and 0 (high
amount). The zero limit may not be reached exactly depending on the
smearing and cutoff combination. The function is a logistic function
mirrored about the y-axis. The cutoff determines the amount at which a
significant reduction in probability takes place and the smearing
parameter defines how smooth the transition from 1 to 0 is. Both, the
cutoff and smearing parameters are defined in terms of fixed fractions
of the capacity.
Extends the pathfinder with a capacity argument for later usage.
In tests, the inserted testCapacity has no effect, but will be used
later to estimate reduced probabilities from it.
This commit adds the maximal capacity between two nodes to the unified
edge data. We use MaxHTLC as a replacement if the channel capacity is
not available.
In tests we use larger maxHTLC values to be able to convert to a
non-zero sat capacity.
This commit refactors the semantics of unified policies to unified
edges. The main changes are the following renamings:
* unifiedPolicies -> nodeEdgeUnifier
* unifiedPolicy -> edgeUnifier
* unifiedPolicyEdge -> unifiedEdge
Comments and shortened variable names are changed to reflect the new
semantics.
We encapsulate the capacity inside a unifiedPolicyEdge for later usage.
The meaning of "policy" has changed now, which will be refactored in the
next commmit.
Because the wallet loader sets its internal database reference to nil
when unloading a wallet, it cannot be loaded again in case of a remote
DB such as etcd or postgres. To avoid running into a nil pointer panic
we just re-create the loader as well before opening the wallet.
Now that we have patched the btcwallet version to the one that includes
the fix, we can adjust the rescan test to show the correct and expected
behavior.
In this commit we add a test that demonstrates the problem of ghost
UTXOs lingering in the wallet after a re-scan, even if they were spent.
NOTE: This test shows the incorrect behavior and will be adjusted in a
follow-up commit to show the correct behavior after patching the
btcwallet version.
This commit makes the `handleChanAnnouncement` always returning `true`
for messages processed but ignored by router, even when the extracted
announcements are empty.
Previously we'd return false when the announcements are empty, which
could cause `ChannelUpdate`s being ignored since the validation barrier
will signal deny for the jobs. This can easily be trigger using
following setup,
1. Alice connects to Bob and open a channel.
2. Alice connects to Carol, Bob connects to Carol.
3. Once the channel is open, Alice and Bob will both announce it to Carol.
At some point, we'd have the following messages in Carol's node,
- Alice's ChannelAnnouncement
- Alice's ChannelUpdates, for both directions
- Bob's ChannelAnnouncement
- Bob's ChannelUpdates, for both directions
And a bug could happen, if,
- Alice's ChannelAnnouncement is processed by router, hence added to db,
but not reporting back to gossiper yet, so the validation barrier
hasn't sent signal allow.
- Bob's ChannelAnnouncement is processed by router, and returned
`ErrIgnored` as the edge info is already in db, and reported back to
gossiper, the validation barrier will signal deny to all the
ChannelUpdates jobs.
- Depending on how fast Alice's ChannelAnnouncement is processed, we may
get zero to four denies to the above ChannelUpdates, causing a channel
edge policy never being updated.
This commit moves the `shouldBroadcast` logic closer to the execution
logic of deciding whether we want to broadcast the announcements. This
is a pure code refactor and should make no difference in announcing
message unless the `d.syncMgr.IsGraphSynced()` gives different results
inside the goroutine.
This commit refactors the `networkHandler` to use the new method
`handleNetworkUpdate`. Because the `select` is called inside a for loop,
which is equivalent of firing goroutine inside range loop, it's possible
that a variable used inside a previous goroutine is referencing the
current one. This is now fixed by making the goroutine taking the params
used for network update.
