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.
In this commit, we add a new option for the existing confirmation
notification system that optionally allows the caller to specify that a
block should be included as well.
The only quirk w/ the implementation here is the neutrino backend:
usually we get filtered blocks, we so need to first fetch the block
again so we can deliver the full block to the notifier. On the notifier
end, it'll only be checking for the transactions we care about, to
sending a full block doesn't affect the correctness.
We also extend the `testBatchConfirmationNotification` test to assert
that a block is only included if the caller specifies it.
An OptionalMsgField has been added that allows outside subsystems
to provide a short channel id we should insert into a ChannelUpdate
that we then sign and send to our peer.
When the gossiper receives a ChannelUpdate, it will query the
alias manager by the passed-in FindBaseByAlias function to determine
if the short channel id in the ChannelUpdate points to a known
channel. If this lookup returns an error, we'll fallback to using
the original id in the ChannelUpdate when querying the router.
The lookup and potential fallback must occur in order to properly
lock the multimutex, query the correct router channels, and rate
limit the correct short channel id. An unfortunate side effect of
receiving ChannelUpdates from our peer that reference on of our
aliases rather than the real SCID is that we must store this policy.
Yet it is not broadcast-able. Care has been taken to ensure the
gossiper does not broadcast *any* ChannelUpdate with an alias SCID.
The cachedNetworkMsg uses the new processedNetworkMsg struct. This
is necessary so that delete-and-reinsert in the funding manager
doesn't process a ChannelUpdate twice and end up in a deadlock since
the err chan is no longer being used.
This commit was previously split into the following parts to ease
review:
- 2d746f68: replace imports
- 4008f0fd: use ecdsa.Signature
- 849e33d1: remove btcec.S256()
- b8f6ebbd: use v2 library correctly
- fa80bca9: bump go modules
This commit adds a method to resend premature when new blocks arrive.
Previously when a message has specified a block+delta in the future, we
would ignore the message and never process it again, causing an open
channel never being broadcast under fast blocks generation. This commit
fixes it by saving the future messages and resending them once the
required block height is reached.
