Use strict metadata reads during migration selection so a metadata bucket with a
missing metadata/dbp key is not interpreted as the latest DB version.
Recover this state from mandatory DB version 33, the last mandatory version
before the v0.20.x releases that could initialize a DB without writing the DB
version key. This runs migration 35 without replaying migrations 0 through 33
against a DB that was already created by a modern schema/code path.
After the selected migrations complete, syncVersions writes the latest DB
version as usual.
On an already-seen channel, the loop returned from the whole node
callback instead of continuing, skipping the node's remaining
channels, this undercounted the stats.
Update the release branch management guide to use the release tag helper
instead of raw git tag commands.
This keeps the process aligned with the new script while leaving the final
push as an explicit maintainer step.
Mark the payments relational backend as available in v0.21 and refresh
the related guidance that previously told payment-heavy operators to wait
for the v0.21 release. Add btcwallet and channel state as in-progress
subsystems targeted for v0.22 (replacing the forwarding history entry),
and update the migration flow diagram and future improvements list to
match.
The block-dn.org service now offers a */import/latest shortcut
for the block and filter header import, so a block height
doesn't need to be specified.
The issue on testnet3 was also fixed, so the warning in the
text is no longer required.
Add a 0.21 release-notes entry covering the `--tor.v2` removal, the
boundary rejection of v2 input on operator entry points, the
persisted-state filtering (self-node announcement, watchtower client,
autopilot, graph bootstrapper, SCB restore), the Tor controller's
v3-only ADD_ONION restriction, and the wire-faithful behavior that
preserves peer-signed v2 entries through `lnwire`, `graph/db`, and
the graph RPCs.
Tor stopped serving v2 onion services in October 2021; lnd should not
produce v2 addresses anymore, but it must still verify signatures on
and re-broadcast peer NodeAnnouncement messages that carry v2 entries.
Stop accepting v2 as configuration input (lncfg), strip the legacy
`--tor.v2` flag from the sample config, and remove the
`tor.OnionHostToFakeIP` helper. Operator entry points (`--externalip`,
`--listen`, `lncli connect`, `lncli wtclient towers add`) fail fast on
a v2 `.onion` string, so upgrading nodes must remove any v2 entry from
`lnd.conf` before lnd will start.
Filter persisted v2 state before use without rewriting on-disk records:
the self-announcement builder strips any v2 entry inherited from the
stored self-node; the watchtower client drops v2 entries from each
persisted tower's address list (skipping the tower entirely if no
non-v2 address remains); the autopilot connector, graph bootstrapper,
and static-channel backup restore paths skip v2 entries before
attempting outbound dials. Restrict the Tor controller's ADD_ONION
path to v3 keys, including the encrypted on-disk legacy-key fallback.
For inbound announcements, keep the wire codec wire-faithful:
`lnwire.WriteOnionAddr`, `graph/db.encodeOnionAddr`, and the matching
decoders round-trip v2 bytes so `DataToSign` reproduces the bytes the
remote peer signed, signature validation succeeds, and the announcement
is persisted to the graph DB and re-broadcast across restarts byte-for-
byte. RPC surfaces continue to expose the full address set so external
tools can independently reproduce and verify the signed bytes.
Add a netann regression test that signs a [v3, v2, ipv4] announcement,
round-trips it through Encode/Decode, verifies the signature, and
confirms the resulting models.Node preserves the v2 entry. Add a
graph bootstrapper test asserting v2 entries are skipped while v3 and
plain TCP entries on the same node still surface as bootstrap
candidates.
In this commit, we add three focused unit tests in contractcourt
plus an itest that exercises the regression end-to-end.
The chain watcher harness gains an opt-in early-dispatch capture that
records every notifyEarlyCoopClose invocation so tests can assert how
many fired and what summaries they carried. On top of that:
TestEarlyDispatchCoopClose verifies the headline behavior. An
async-path coop close fires exactly one early dispatch with
IsPending=true and the post-N-conf flow still produces the regular
CooperativeCloseInfo downstream.
TestEarlyDispatchForceCloseNotInvoked guards the carve-out: force
closes never fire the early dispatch since their CLOSED_CHANNEL
event timing is intentionally unchanged.
TestEarlyDispatchReorgRefiresOnReReplacement nails down the reorg
path. Once a deep reorg removes the close, the early-dispatch flag
is cleared and the next coop close re-fires the early event with its
own summary, so a subscriber observes each distinct close attempt.
testZeroConfCoopCloseSubscribeEvents brings up a zero-conf channel
between Alice and Bob with --dev.force-channel-close-confs=3 so the
chain watcher takes the async multi-confirmation path. Alice
subscribes to channel events, initiates a cooperative close, and the
test asserts that CLOSED_CHANNEL fires after only one confirmation
of the close tx (not after the full three) and that
FULLY_RESOLVED_CHANNEL arrives once the close has reached three
confirmations. A quiet-window assertion at the end verifies that
exactly one CLOSED_CHANNEL event is delivered. If the suppression in
MarkChannelClosed broke and let it re-fire NotifyClosedChannel at N
confs, this assertion would catch the duplicate.
In this commit, we shuffle the CLI and RPC names so the bare "taproot"
identifier refers to the production taproot channel type (final
scripts, feature bits 80/81), i.e. the variant new integrations should
actually be using. Before this commit, "taproot" on the CLI mapped to
the staging bits, and anyone who wanted a real production taproot
channel had to spell out "taproot-final" on `lncli openchannel` or
`SIMPLE_TAPROOT_FINAL` over RPC. The recommended choice was hidden
behind the longer name.
On the CLI (`lncli openchannel --channel_type=...`):
- "taproot" now selects the production variant (it used to mean
staging).
- "taproot-staging" is added for the legacy development bits, for
peers that haven't moved over yet.
- "taproot-final" stays as a deprecated alias for "taproot" so
existing scripts don't break.
On the RPC (`CommitmentType`):
- `TAPROOT = 7` is added as the canonical name for the production
type. `SIMPLE_TAPROOT_FINAL = 7` is kept as a deprecated alias via
`option allow_alias = true`, so existing clients keep compiling
against the same Go constant and the wire value doesn't change.
- `SIMPLE_TAPROOT = 5` (staging) is unchanged.
- `SIMPLE_TAPROOT_OVERLAY = 6` is unchanged. The taproot-assets
daemon hard-codes this distinct enum value, so it's unaffected.
Wire compat is preserved end-to-end: only the comments, enum entry
order, and the CLI string-to-enum mapping change. The numeric values
and the existing generated Go identifiers stay stable.
Document the neutrino fast sync feature that allows importing block and
filter headers from local files or HTTP URLs on startup. Cover
configuration for mainnet (block-dn.org), testnet3, testnet4, signet,
file format details, security considerations, and troubleshooting.
Add entries to the Breaking Changes section covering the payment and
tracking RPCs and the `outgoing_chan_id` field removed in this branch,
all of which were announced for removal in 0.21 via the 0.20 release
notes.
Remove the following deprecated RPC definitions that were announced for
removal in 0.21 via the 0.20 release notes:
lnrpc:
- SendPayment (bidirectional streaming)
- SendPaymentSync
- SendToRoute (bidirectional streaming)
- SendToRouteSync
routerrpc:
- SendPayment (streaming)
- SendToRoute
- TrackPayment (streaming)
Also remove the now-unused PaymentState enum and PaymentStatus message
that were only used by the deprecated TrackPayment response stream, plus
the corresponding REST annotations from the yaml files.
Drop the now-orphan routerrpc.SendToRouteResponse message that was only
referenced by the deleted routerrpc.SendToRoute RPC.
Also remove the deprecated outgoing_chan_id field from
lnrpc.QueryRoutesRequest (tag 14) and routerrpc.SendPaymentRequest
(tag 8); their tag numbers are now reserved. Callers must use the
multi-channel outgoing_chan_ids field introduced in 0.20.
Drop the compat fallback in router_backend.go that previously consumed
the field, and regenerate all protobuf, gRPC, REST gateway, JSON, and
swagger files.
Document that bitcoind outbound peer health checks now use
getnetworkinfo.connections_out instead of getpeerinfo.
Also mention that texts of zmq port mismatch warnings were fixed.
Adds docs/testing-guides/v0.21.0/ with a per-feature guide for the
v0.21.0-beta.rc1 release. Each guide follows a fixed template
(prereqs, setup, scenarios with concrete pass/fail signals, failure
investigation) so RC testers and automated agents can work through
them predictably.
Coverage:
- Headline features: production taproot channels, RBF taproot
coop-close, payment store KV->SQL migration, onion messaging +
rate limiting.
- High-risk regressions / breaking changes: closed-channel
tombstone (sqlite/postgres downgrade trap), reorg-safe channel
closes + MinCLTVDelta raise, chain_params network-mismatch DB
guard, GetDebugInfo log opt-in.
- New RPCs / operator features: payment-adjacent RPCs bundle,
multiple read-only middleware interceptors.
This is a first draft intended for community review on the PR.
payment-sql-migration.md carries a TBD callout for the
SkipNativeSQLMigration rescue-path behavior, pending developer
confirmation.
