Add a gossip version parameter to HighestChanID in the Store interface
and both KV/SQL implementations. Update callers in the discovery
ChanSeries and server bootstrap code.
Add gossip version parameters to ForEachNodeCacheable and
ForEachChannelCacheable in the Store interface and both implementations.
Thread the version through SQL helpers and update call sites/tests
accordingly.
Add a gossip version parameter to ForEachSourceNodeChannel in the Store
interface and both KV/SQL implementations. The VersionedGraph wrapper
delegates with its baked-in version. Convert the
testAddChannelEdgeShellNodes and testForEachSourceNodeChannel tests to
run against both v1 and v2 gossip versions.
Update ForEachNodeChannel to accept a gossip version parameter,
allowing callers to specify which gossip version's channels should be
iterated. This change mirrors the approach taken in ForEachChannel and
prepares the graph database for supporting multiple gossip versions
while maintaining backward compatibility.
The Store interface is updated to include the version parameter, and
both KVStore and SQLStore implementations are updated accordingly:
- KVStore validates that only GossipVersion1 is requested, returning
ErrVersionNotSupportedForKVDB for other versions.
- SQLStore passes the version through to the underlying node query,
enabling version-specific channel iteration.
The ChannelGraph wrapper is updated to accept and pass through the
version parameter. VersionedGraph gains a ForEachNodeChannel method
that automatically uses its configured gossip version, providing a
clean interface for version-specific operations.
Update all call sites to explicitly pass lnwire.GossipVersion1, except
for the local channel manager in server.go which now uses the v1Graph
directly (matching the pattern used in other parts of the codebase).
Add version-aware DeleteChannelEdges method to VersionedGraph and
update call sites in graph builder, rpcserver, and server to use
versioned graphs. This ensures channel deletion operations are
properly scoped to the correct gossip version.
In this commit, we add a new param that'll allow us to scale up the
number of confirmations before we act on a new close. We'll use this
later to improve the current on chain handling logic.
In the previous iteration with endorsement
signaling, the recommendation was for the sender to
set it to 1 and that could have had privacy concerns
when first deploying given that the default was to
downgrade the signal to 0. In the latest proposal
the recommended default for both sending and
forwarding nodes is to set `accountable` to 0.
As a result, the dates have been removed given
that there are no privacy risks associated
with relaying the signal with zero values.
Fix bug where setSelfNode compared only the seconds component of
timestamps instead of the full timestamp. This caused the node to
attempt persisting an older timestamp than what existed in the
database during restart, resulting in "sql: no rows in result set"
errors.
Modifiers of the node announcement may add duplicate addresses, which we
remove here after the modifications were applied. This also ensures that
any previously added duplicate addresses are removed as well.
Introduced a new config value `upfront-shutdown-address`
in the `lnd.conf` file. This ensures that channel close
funds are transferred to the specified shutdown address.
The value applies to both the funder and the fundee but
can be overridden by the value specified during
`openchannel` or by the `channel acceptor`.
NOTE: If this field is set when opening a channel with a
peer that does not advertise support for upfront shutdown
feature, the channel open will fail.
Signed-off-by: Nishant Bansal <nishant.bansal.282003@gmail.com>
The only way to unblock SendCustomMessage is if the peer activates,
disconnects or the server shuts down. This means that if the context is
cancelled, we will still wait until one of those other events happen.
With this commit we thread the context through to SendCustomMessage, so
that if the context is cancelled, we can return early. This improves the
cancellation semantics.
This commit creates the necessary endpoints for onion messages.
Specifically, it adds the following:
- `SendOnionMessage` endpoint to send onion messages.
- `SubscribeOnionMessages` endpoint to subscribe to incoming onion
messages.
It uses the `msgmux` package to handle the onion messages.
This commit addresses a regression where Neutrino rescanning starts
from an outdated height (~100k blocks behind) instead of using the
current synced height.
Root Cause:
In commit 16a8b623b, the initialization order was changed so that
Chain Notifier starts before wallet syncing completes. This means
the rescan begins using the stale height from BuildChainControl
rather than the fully synced height.
Old behavior (commit 1dfb5a0c2):
1. RPC server starts
2. Headers sync as part of daemon server
3. Chain Notifier starts after sync completes
4. Rescan begins from current (synced) height
Current behavior (regression):
1. Chain Notifier starts in newServer (before RPC)
2. Wallet sync happens after RPC server starts
3. Rescan uses outdated height from BuildChainControl
Solution:
- Ensure headers are fully synced before starting the chain notifier,
and after starting the RPC server.
- Move chain notifier startup to its correct location after headers are
fully synced.
- Make sure the starting beat is lazily called after chain notifier
started and before that starting beat result is used.
In preparation for adding a NodeAnnouncement2 struct along with a
NodeAnnouncement interface, this commit renames the existing
NodeAnnouncment struct to NodeAnnouncement1.
In this commit we stop using persisted address in LND's prev run.
This means addresses set using `externalip` will be used without
merging them with the ones from prev run. We will introduce the
condition to use persisted addresses in the next commit.
This is the final step, we actually call the interface and either
provide or retrieve the custom features over the message. We also notify
the aux components when channel reestablish is received.
This commit ensures that we start with the alias, node color,
addresses, and features as advertised in the node's previous
runtime. This approach maintains consistency in the node's
advertised information across restarts.
This commit moves most of the code into its own package. It is
the smallest code move possible without moving import cycles and
keeping the changes to the code base as small as possible during
refactor.
This error is returned when one attempts to use taproot overlay channels
without the necessary auxiliary funding controller being supplied. In
practice, when running lnd via litd, the latter will always supply
'tapd' as the aux funding controller, but a standalone lnd has no
knowledge of that.
The previous message sort of reads like the lnd user has forgotten to
set some available option or flag, but nothing or the sort actually
exists. The update makes it clearer that the feature isn't available in
the standalone build.
We also addd this new db on the server level to use it in the
following commit to do all the payment related queries of the
rpcserver.
We add a new payment db instance on the server level. Which we
will you for the payment related queries in a following commit.
In the following commits we will gradually unify the current
payment db operations into an interface to later down the road
support both backends (sql+kv).
In this commit, we complete the integration of the configurable gossip
filter concurrency by wiring the new FilterConcurrency configuration
through all layers of the application.
The changes connect the gossip.filter-concurrency configuration option
from the command-line interface through the server initialization code
to the gossiper and sync manager. This ensures that operators can
actually use the new configuration option to tune their node's
concurrent gossip filter processing capacity based on their specific
requirements and available resources.
Elle Mouton