In this commit, the FetchChanInfos ChannelGraph method is updated to
take in an optional read transaction for the case where it is called
from within another transaction.
In processZombieUpdate, the SCID passed to MarkEdgeLive should _not_ be
derived from the ChannelEdgeInfo ChannelID field since this field will
not be populated when GetChannelByID returns a ChannelEdgeInfo along
with an ErrZombieEdge error. So this commit ensures that a usable
SCID is provided to processZombieUpdate.
Let MarkEdgLive return a new ErrNotZombieEdge error if an entry with the
given channel ID cannot be found. In processZombieUpdate, we then
check for this error and log accordingly.
Finally, The LightningNode object is removed from ChannelEdgePolicy.
This is a step towards letting ChannelEdgePolicy reflect exactly the
schema that is on disk.
This is also nice because the `Node` object is not necessarily always
required when the ChannelEdgePolicy is loaded from the DB, so now it
only get's loaded when needed.
When we first go to boot up the syncer, when we're in the active phase,
after we do the historical sync, we'll send a timestamp message that we
want everything, then transition to the passive mode. The test didn't
account for this extra message before, as the last test was being
re-used here (ran in parallel).
We fix this by asserting that the first expected message is sent, then
also the follow up messages as well.
In this commit, we add support for the new musig2 channel funding flow.
This flow is identical to the existing flow, but not both sides need to
exchange local nonces up front, and then signatures sent are now partial
signatures instead of regular signatures.
The funding manager also gains some new state of the local nonces it
needs to generate in order to send the funding locked message, and also
process the funding locked message from the remote party.
In order to allow the funding manger to generate the nonces that need to
be applied to each channel, then AddNewChannel method has been modified
to accept a set of options that the peer will then use to bind the
nonces to a new channel.
In this commit, we update the Sig type to support ECDSA and schnorr
signatures. We need to do this as the HTLC signatures will become
schnorr sigs for taproot channels. The current spec draft opts to
overload this field since both the sigs are actually 64 bytes in length.
The only consideration with this move is that callers need to "coerce" a
sig to the proper type if they need schnorr signatures.
This commit adds a new interface method, `RemovePendingChannel`, to be
used when the funding flow is failed after calling `AddPendingChannel`
such that the Brontide has the most up-to-date view of the active
channels.
The funding manager has been updated to use `AddPendingChannel`. Note
that we track the pending channel before it's confirmed as the peer may
have a block height in the future(from our view), thus they may start
operating in this channel before we consider it as fully open.
The mocked peers have been updated to implement the new interface method.
In this commit, we eliminate some code duplication by removing the old
`HashMutex` struct as it just duplicates all the code with a different
type (uint64 and hash). We then make the main Mutex struct take a type
param, so the key can be parametrized when the struct is instantiated.
In preparation for a more complex function signature for set node
announcement, separate get and set so that readonly callers don't need
to handle the extra arguments.
This commit adds a simple struct `futureMsgCache` that embeds a lru
cache with the message ID. A unit test is added to check the eviction
behaves as expected.
This commit removes the slice used when saving future messages into the
cache. Instead, each message is now saved independently into the cache
with a monotonically increasing integer as its ID.
This commit adds a new const to increase the max future messages allowed
from 100 to 1000, which is needed as during IBD a node with lots of
channels might receive many future messages.
We require channel updates to have the max HTLC message flag set.
Several flows need to pass that check before channel updates are
forwarded to peers:
* after channel funding: `addToRouterGraph`
* after receiving channel updates from a peer:
`ProcessRemoteAnnouncement`
* after we update channel policies: `PropagateChanPolicyUpdate`
We rename `ChanUpdateOptionMaxHtlc` to `ChanUpdateRequiredMaxHtlc`
as with the latest changes it is now required.
Similarly, rename `validateOptionalFields` to
`ValidateChannelUpdateFields`, export it to use it in a later commit.
This commit changes the sending of anns from using separate goroutines
to always sending both local and remote announcements in the same
goroutine. In addition, the local announcements are always sent first.
This change is to fix the following case:
1. Alice and Bob have a channel
2. Alice receives Bob's NodeAnnouncement
3. Alice goes to broadcast the channel
4. The broadcast is split into a local and remote broadcast due to PR
#7239. Bob's NodeAnnouncement is in the remote batch. Everything else
(ChannelAnnouncement, ChannelUpdate x2, and Alice's NodeAnnouncement)
is in the local batch.
5. The remote batch (containing Bob's NodeAnnouncement) runs before the
local batch since they are spawned in separate goroutines. This means
that Alice sends Carol the NodeAnnouncement before Carol knows of the
channel.
In step 2), Bob's NodeAnnouncement (isRemote = true) replaces Bob's
NodeAnnouncement that Alice was going to relay (isRemote = false) after
processing the AnnouncementSignatures.
This commit refactors the method `sendBatch` into `sendLocalBatch` and
`sendRemoteBatch` for clarity. The batch size calculation is also moved
into `splitAnnouncementBatches`.
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
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.
