multi: remove deprecated RPCs and config flags scheduled for 0.21

[erickcestari]

This PR removes the deprecated RPCs, fields, and configuration options that
were announced for removal in 0.21 via the
0.20 release notes.

Changes

Removed deprecated RPCs

The following RPCs are removed. Callers must migrate to the V2 equivalents
listed in the 0.20 release notes:

Removed RPC	Replacement
lnrpc.SendPayment (streaming)	routerrpc.SendPaymentV2
lnrpc.SendPaymentSync	routerrpc.SendPaymentV2
lnrpc.SendToRoute (streaming)	routerrpc.SendToRouteV2
lnrpc.SendToRouteSync	routerrpc.SendToRouteV2
routerrpc.SendPayment (streaming)	routerrpc.SendPaymentV2
routerrpc.SendToRoute	routerrpc.SendToRouteV2
routerrpc.TrackPayment (streaming)	routerrpc.TrackPaymentV2

This includes removing the corresponding REST gateway routes:

• POST /v1/channels/transaction-stream
• POST /v1/channels/transactions
• POST /v1/channels/transactions/route

Removed deprecated OutgoingChanId field

The single-channel outgoing_chan_id field on QueryRoutesRequest and
SendPaymentRequest is no longer honored. Callers must use the multi-channel
outgoing_chan_ids field introduced in 0.20.

The compatibility fallback that accepted either field (and errored when both
were set) is removed from the routerrpc backend.

Removed deprecated tor v2 support

The --tor.v2 configuration flag is removed. Tor v2 onion services have been
obsolete since October 2021 when the Tor network dropped support for them.

The hidden service setup paths in config.go, lnd.go, and server.go are
simplified to assume v3 whenever a hidden service is configured.

Internal cleanups

• Removed the dead payment infrastructure in rpcserver.go that was
  exclusively used by the deleted lnrpc handlers: paymentStream,
  rpcPaymentRequest, rpcPaymentIntent, extractPaymentIntent,
  dispatchPaymentIntent, sendPayment, and sendPaymentSync (~640 lines).
• Removed the legacyTrackPaymentServer wrapper, PaymentState enum, and
  PaymentStatus message that were only used by the deleted
  routerrpc.TrackPayment stream.
• Removed the SendToRoute and SendToRouteSync helpers from the integration
  test harness.

Test changes

• itest/lnd_routing_test.go: collapsed three SendToRoute test cases (sync,
  stream, v2) into a single test exercising SendToRouteV2. Updated the error
  propagation test to assert on HTLCAttempt.Failure.Code instead of the
  legacy PaymentError string.
• itest/lnd_channel_policy_test.go: migrated from streaming SendToRoute to
  SendToRouteV2 with structured failure assertions.
• lnrpc/routerrpc/router_backend_test.go: removed the singleChanID and
  bothChanIds test variants that exercised the deprecated single-field path
  and its conflict detection.

Commits

The PR is split into six logical commits:

1. proto: remove deprecated SendPayment, SendToRoute, TrackPayment RPCs - all
   proto, yaml, and regenerated stub files
2. lnrpc: remove deprecated Send* RPC server implementations - server-side
   handlers and dead payment infrastructure in rpcserver.go
3. routerrpc: remove deprecated SendPayment, SendToRoute, TrackPayment impls -
   server-side shims and macaroon entries
4. routerrpc: remove deprecated outgoing_chan_id field handling - backend
   compatibility fallback removal
5. lncfg: remove deprecated tor v2 support - tor v2 config flag removal
6. itest: migrate deprecated lnrpc Send* calls to routerrpc V2 - test harness
   and integration test updates

Breaking changes

This is a breaking change for any client that still uses the deprecated RPCs,
fields, or config flag listed above. All have had V2 / replacement equivalents
available for multiple releases.

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request completes the deprecation cycle for several RPCs, configuration flags, and fields that were announced for removal in the 0.20 release. By removing these legacy components, the codebase is simplified and technical debt is reduced, while ensuring that users migrate to the more robust V2 alternatives.

Highlights

• Removal of Deprecated RPCs: Removed several deprecated RPCs, including lnrpc.SendPayment, lnrpc.SendToRoute, and routerrpc.TrackPayment, along with their REST gateway equivalents. Callers are directed to use the V2 equivalents.
• Removal of Deprecated Fields: Removed the outgoing_chan_id field from QueryRoutesRequest and SendPaymentRequest, requiring callers to use the multi-channel outgoing_chan_ids field.
• Tor v2 Support Removal: Removed the --tor.v2 configuration flag and associated infrastructure, as Tor v2 onion services are obsolete.
• Internal Cleanup and Testing: Cleaned up dead payment infrastructure in rpcserver.go and migrated integration tests to use the V2 RPC equivalents.

New Features

🧠 You can now enable Memory (public preview) to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[github-actions]

🔴 PR Severity: CRITICAL

Highest-severity file wins | 15 non-test/non-generated files | ~1,473 lines changed (excl. tests & generated)

🔴 Critical (2 files)

• rpcserver.go - Core RPC server coordination (explicitly listed as critical)
• server.go - Core server coordination (explicitly listed as critical)

🟠 High (3 files, plus 7 auto-generated excluded from count)

• lnrpc/routerrpc/router_backend.go - RPC/API router backend logic
• lnrpc/routerrpc/router_server.go - Router RPC server implementation
• lnrpc/routerrpc/router_server_deprecated.go - Deprecated router RPC endpoints removed
• (auto-generated, excluded: lnrpc/lightning.pb.go, lightning.pb.gw.go, lightning.pb.json.go, lightning_grpc.pb.go, routerrpc/router.pb.go, router.pb.json.go, router_grpc.pb.go)

🟡 Medium (9 files)

• config.go - Root configuration file
• lnd.go - Root entrypoint
• lncfg/tor.go - lncfg package (Tor config)
• lnrpc/lightning.proto - Lightning RPC proto definition
• lnrpc/lightning.swagger.json - Swagger API spec
• lnrpc/lightning.yaml - API YAML spec
• lnrpc/routerrpc/router.proto - Router RPC proto definition
• lnrpc/routerrpc/router.swagger.json - Router swagger spec
• lnrpc/routerrpc/router.yaml - Router YAML spec

🟢 Low (7 files — excluded from severity calculation)

• docs/release-notes/release-notes-0.21.0.md - Release notes
• itest/lnd_channel_policy_test.go - Integration test
• itest/lnd_routing_test.go - Integration test
• lntest/harness_assertion.go - Test harness
• lntest/rpc/lnd.go - Test RPC helper
• config_test.go - Unit test
• lnrpc/routerrpc/router_backend_test.go - Unit test

Analysis

This PR touches rpcserver.go (788 lines removed) and server.go, both of which are explicitly classified as CRITICAL core server coordination files. The changes appear to be a significant cleanup/removal of deprecated RPC endpoints — particularly in rpcserver.go (~788 lines removed) and lnrpc/routerrpc/router_server_deprecated.go (~114 lines removed), along with corresponding proto/swagger changes.

Even though most changes are deletions (3,055 deletions vs. 423 additions, net reduction of ~2,632 lines), removing RPC handlers from the core server warrants careful expert review to ensure no active functionality is inadvertently dropped and that all call sites have been migrated.

The >500 non-test/non-generated lines changed threshold for a severity bump is met (~1,473 lines), but the PR is already at the maximum CRITICAL level.

---

_{To override, add a severity-override-{critical,high,medium,low} label.}
<!-- pr-severity-bot -->

[gemini-code-assist]

Code Review

This pull request removes deprecated Tor v2 support and several legacy payment and tracking RPCs, including SendPayment, SendPaymentSync, SendToRoute, and TrackPayment, along with associated configuration flags and test cases. The changes simplify the codebase by removing obsolete logic and updating integration tests to use V2 RPC equivalents. Review feedback suggests moving the QueryProbability function to router_server.go and deleting the now-redundant router_server_deprecated.go file, while also improving the function's documentation to comply with the LND style guide for exported functions.

[erickcestari]

@claude Check that all deprecated features have been removed correctly.

[claude]

Claude Code is working…

I'll analyze this and get back to you.

View job run

[ziggie1984]

This bot does not work on forked repos.

[yyforyongyu]

Looking good, left a few comments found by gpt

[erickcestari]

Thanks for the review @yyforyongyu.

Here is a summary of the changes since the last review:

• proto removal (4728515): dropped the now-orphan SendRequest/SendResponse/SendToRouteRequest messages from lightning.proto, regenerated pb.go. Removed /v1/channels/transaction-stream from LndClientStreamingURIs, updated docs/rest/websockets.md example, and removed stale SendPayment*/SendToRoute* doc bullets from lnrpc/README.md.
• outgoing_chan_id (1d37383): non-zero deprecated outgoing_chan_id on QueryRoutesRequest/SendPaymentRequest is now explicitly rejected with an error instead of silently dropped.
• tor v2 (72b4388): removed --tor.v2 from docs/configuring_tor.md and sample-lnd.conf; cleaned up tor/cmd_onion.go (dropped V2 OnionType, V2KeyParam, V2 branches in prepareKeyparam/AddOnion, updated RSA1024 → ED25519-V3 protocol example); updated tor/cmd_onion_test.go expectations.
• itest (d0225e7): re-added the HtlcMinimumMsat == customMinHtlc assertion on the SendToRouteV2 failure path in lnd_channel_policy_test.go.
• release notes (95d7c04): reworded the outgoing_chan_id bullet to reflect that the proto field is kept but non-zero values are rejected.

[ziggie1984]

I double-checked the remaining matches after the latest update. Two leftovers still look worth addressing/clarifying:

1. routerrpc.SendToRouteResponse still exists even though the deprecated routerrpc.SendToRoute RPC has been removed.

   • lnrpc/routerrpc/router.proto: message SendToRouteResponse
   • generated references remain in lnrpc/routerrpc/router.pb.go
   • I did not find a remaining RPC method that returns this message; SendToRouteV2 returns lnrpc.HTLCAttempt.

2. Tor v2 onion-service creation/config is removed, but Tor v2 address parsing/storage compatibility remains.

   • tor/onionaddr.go: V2DecodedLen, V2Len
   • tor/tor.go: v2 onion parsing paths
   • additional compatibility paths remain in lnwire and graph DB address handling, for example graph/db/sql_store.go still stores/decodes addressTypeTorV2.

[ziggie1984]

Open question: how do we want to handle the deprecated outgoing_chan_id proto fields?

This PR currently keeps the deprecated fields in the public proto surface and rejects non-zero values at runtime:

• lnrpc.QueryRoutesRequest.outgoing_chan_id = 14
• routerrpc.SendPaymentRequest.outgoing_chan_id = 8

I confirmed both are still present directly in the proto files:

• lnrpc/lightning.proto: uint64 outgoing_chan_id = 14 [jstype = JS_STRING, deprecated = true];
• lnrpc/routerrpc/router.proto: uint64 outgoing_chan_id = 8 [jstype = JS_STRING, deprecated = true];

Keeping them has the advantage that old clients get an explicit error instead of having the field silently ignored. But it also means the fields remain in generated clients, swagger, and API docs, so they are not fully removed from the proto surface.

Should we instead remove these fields from the messages and reserve their tag numbers?

For example:

message QueryRoutesRequest {
    reserved 14;
    ...
}

and:

message SendPaymentRequest {
    reserved 8;
    ...
}

There is precedent for reserved tags in the current codebase:

• lnrpc/lightning.proto: reserved 11 in GetInfoResponse
• lnrpc/lightning.proto: reserved 2 with the comment “Previously used for confirmation_height. Do not reuse.”
• lnrpc/lightning.proto: reserved 3 in QueryRoutesRequest
• lnrpc/routerrpc/router.proto: reserved 1 in QueryMissionControlResponse
• lnrpc/routerrpc/router.proto: reserved 3, 4, 5, 6 in PairHistory
• lnrpc/routerrpc/router.proto: reserved 3 in PairData
• lnrpc/invoicesrpc/invoices.proto: reserved 1 in SubscribeSingleInvoiceRequest

The tradeoff is that deleting the fields means old binary gRPC clients that still send those tags may have them decoded as unknown fields, so the server may no longer be able to return a targeted “use outgoing_chan_ids” error. Keeping the fields allows that explicit rejection, but leaves deprecated fields in the API surface.

Which behavior do we want for the 0.21 removal?

I am for removing it completely.

[erickcestari]

Thanks for the review @ziggie1984 !

The summary of the changes after addressing your comments:

• ec24f0a proto: removed orphan routerrpc.SendToRouteResponse; removed deprecated outgoing_chan_id field from lnrpc.QueryRoutesRequest (tag 14) and routerrpc.SendPaymentRequest (tag 8), reserving both tags; dropped the runtime fallback in router_backend.go; regenerated pb.go/swagger.
• ffcc993 tor v2: dropped V2 onion encoder paths in lnwire.WriteOnionAddr, graph/db.encodeOnionAddr, graph/db.collectAddressRecords, and tor.OnionHostToFakeIP. Decoders kept for backwards-compat with existing DBs and peer gossip. Tests updated to V3 fixtures.
• b512b99 docs: updated 0.21 release notes to reflect the proto field removal (vs runtime rejection), the SendToRouteResponse drop, and the asymmetric V2 encoder removal.

[erickcestari]

It looks like my last push caused the CI to break. I'm working on the fix.

[ziggie1984]

One more Tor-related edge case worth clarifying/fixing: restored onion keys are not validated as v3.

The new-key path now correctly creates v3 services because prepareKeyparam defaults to NEW:ED25519-V3. But if an OnionStore returns an existing private key, prepareKeyparam currently uses it directly:

case nil:
    keyParam = string(privateKey)

That means a restored key such as RSA1024:... can still be passed to Tor via ADD_ONION, even though --tor.v2, tor.V2, and V2KeyParam were removed.

This is about our own hidden service / watchtower hidden service restoration path, not about parsing other peers’ historical v2 onion addresses. The call path is roughly:

• server.createNewHiddenService / watchtower.createNewHiddenService
• tor.NewOnionFile(...) as the store
• TorController.AddOnion
• prepareKeyparam
• stored key replaces NEW:ED25519-V3 if PrivateKey() succeeds

The default plaintext old-v2-key case is partially blocked now because OnionFile.PrivateKey() no longer treats RSA1024 as a valid plaintext key prefix. But encrypted old v2 keys, custom stores, or future store implementations can still return RSA1024:... after retrieval/decryption and bypass that check.

Proposal: fail strictly when a restored onion private key is not v3. For example, after loading/decrypting a stored key, reject anything that does not start with ED25519-V3 and return a clear error telling the user to remove the old onion key file if they want a new v3 service generated.

I think strict failure is safer than silently regenerating because regenerating would change our advertised onion identity automatically. For watchtower in particular, address stability can matter, so changing it should be an explicit user action rather than a hidden migration side effect.

A small unit test with a fake OnionStore returning RSA1024:... would lock this in.

[gemini-code-assist]

Code Review

This pull request removes support for Tor v2 onion services and several deprecated payment-related RPCs, including their proto definitions, server implementations, and associated tests. The review feedback identifies multiple style guide violations regarding function call wrapping in integration tests and the router backend, specifically where calls that fit within the 80-character limit were unnecessarily wrapped or where long calls were wrapped incorrectly. Additionally, a redundant test case in lnrpc/routerrpc/router_backend_test.go was noted for removal to improve code cleanliness.

[gemini-code-assist]

This function call wrapping violates the style guide. If a function call fits within the 80-character limit, it should be on a single line. If it must be wrapped, the closing parenthesis should be on its own line and all arguments should start on a new line after the opening parenthesis.

payReqs, rHashes, _ := ht.CreatePayReqs(dave, paymentAmtSat, numPayments)

References

1. Wrapping long function calls: If a function call exceeds the column limit, place the closing parenthesis on its own line and start all arguments on a new line after the opening parenthesis. ^(link)

[yyforyongyu]

Gemini is not wrong here: https://github.com/lightningnetwork/lnd/blob/master/docs/development_guidelines.md#wrapping-long-function-calls

[erickcestari]

Got it! I'll update it.

[erickcestari]

Proposal: fail strictly when a restored onion private key is not v3. For example, after loading/decrypting a stored key, reject anything that does not start with ED25519-V3 and return a clear error telling the user to remove the old onion key file if they want a new v3 service generated.

I think strict failure is safer than silently regenerating because regenerating would change our advertised onion identity automatically. For watchtower in particular, address stability can matter, so changing it should be an explicit user action rather than a hidden migration side effect.

A small unit test with a fake OnionStore returning RSA1024:... would lock this in.

Good idea. I've pushed new changes addressing this.

[erickcestari]

The CI with fuzz regression caught a failed roundtrip from nodeAnnounecement which accepts onion v2. Working in a fix fro this one.

https://github.com/lightningnetwork/lnd/actions/runs/25880327640/job/76058506859?pr=10795#step:9:41

[yyforyongyu]

Gemini is not wrong here: https://github.com/lightningnetwork/lnd/blob/master/docs/development_guidelines.md#wrapping-long-function-calls

[yyforyongyu]

Happy cleanup! My main comment is the error case when serializing the legacy v2, sth like,

• A graph node containing an old v2 onion address can be read from DB.
• If that node is later updated/re-saved, the write path sees the v2 *tor.OnionAddr.
• graph/db/addr.go or graph/db/sql_store.go rejects it.
• The whole node update/write fails, not just the obsolete address.

I think we can just drop v2 addrs at serialization.

[erickcestari]

Thanks for the review @yyforyongyu . Your comments should be addressed now!