Proto commits in lightningnetwork/lnd

These commits are when the Protocol Buffers files have changed: (only the last 100 relevant commits are shown)

2026-09-24

lnrpc: document that the legacy commitment type is rejected on input In this commit, we document the restriction on the API itself, so callers can discover it without reading the release notes. The LEGACY enum value notes that it is only ever reported for channels that already exist, and the commitment_type fields of OpenChannelRequest and BatchOpenChannel note that it is turned down as an input. Worth spelling out on those fields that an empty channel type on the wire asks for the legacy type as well, so there is no way to request it at all. The generated code carries no change beyond the comments. (cherry picked from commit 9b634bfd0929ecc0f0e0ddc0b6aa85a5234a06b6)

multi: require explicit channel type in all negotiations Move from optional implicit negotiation to mandatory explicit channel type in OpenChannel and AcceptChannel. The returned ChannelType is now always non-nil. Channel type is required in all negotiations now. We only fallback to a default channel type when the RPC caller does not explicitly specify one. Signed-off-by: Nishant Bansal <nishant.bansal.282003@gmail.com> (cherry picked from commit 53da78ad68a5182240c10d5de369cc54fb802cef)

multi: require explicit channel type in all negotiations Move from optional implicit negotiation to mandatory explicit channel type in OpenChannel and AcceptChannel. The returned ChannelType is now always non-nil. Channel type is required in all negotiations now. We only fallback to a default channel type when the RPC caller does not explicitly specify one. Signed-off-by: Nishant Bansal <nishant.bansal.282003@gmail.com> (cherry picked from commit 53da78ad68a5182240c10d5de369cc54fb802cef)

lnrpc: document that the legacy commitment type is rejected on input In this commit, we document the restriction on the API itself, so callers can discover it without reading the release notes. The LEGACY enum value notes that it is only ever reported for channels that already exist, and the commitment_type fields of OpenChannelRequest and BatchOpenChannel note that it is turned down as an input. Worth spelling out on those fields that an empty channel type on the wire asks for the legacy type as well, so there is no way to request it at all. The generated code carries no change beyond the comments. (cherry picked from commit 9b634bfd0929ecc0f0e0ddc0b6aa85a5234a06b6)

Merge pull request #11212 from ziggie1984/disable-legacy-channels multi: stop opening legacy channels

The documentation is generated from this commit.

2026-09-23

lnrpc: document that the legacy commitment type is rejected on input In this commit, we document the restriction on the API itself, so callers can discover it without reading the release notes. The LEGACY enum value notes that it is only ever reported for channels that already exist, and the commitment_type fields of OpenChannelRequest and BatchOpenChannel note that it is turned down as an input. Worth spelling out on those fields that an empty channel type on the wire asks for the legacy type as well, so there is no way to request it at all. The generated code carries no change beyond the comments.

routerrpc: allow BuildRoute RPC to use arbitrary source The routerrpc.Server and ChannelRouter assume that the source public key for a route is always the node’s public key when calling BuildRoute. We update to allow overriding of this field to any arbitrary public key. The list of hop public keys must be connected to the source via channels in our graph view.

lnrpc: allow arbitrary route source The RouterBackend assumes that the source public key for a route is always the node’s public key when calling UnmarshallRoute. Here we update to allow overriding of this field to any arbitrary public key.

switchrpc: add DisableRemoteRouter rpc In this commit, we add a DisableRemoteRouter RPC to the switchrpc sub-server that allows an operator to transition from external (switchrpc) back to local payment lifecycle management. The handler delegates to the Switch's DisableRemoteRouter method and distinguishes between precondition failures (attempt entries still exist) and internal errors, returning codes.FailedPrecondition or codes.Internal respectively. This gives callers a clear signal to drain pending attempts before retrying.

switchrpc: add DeleteAttempts RPC Expose the store-layer DeleteAttempts as a gRPC endpoint on the Switch sub-server, allowing remote callers to garbage-collect terminal attempt records by explicitly naming the finished IDs. A unit test with a stateful mock demonstrates that hard delete removes the idempotency protection, allowing re-dispatch with the same ID.

switchrpc: update SendOnion error handling Update both proto and handler to communicate error information via gRPC status details.

switchrpc: update TrackOnion rpc error handling The new structure uses a top-level `oneof` to provide a compile-time distinction between a successful payment (preimage) and a failed one. Additional information on a failed attempt can be found in FailureDetails. We now also use a structured ForwardingFailure type for communicating the failure index and wire message from failures which occur during htlc forwarding downstream in the route.

switchrpc: update sendonion rpc docs Clarify useage of API for rpc clients.

switchrpc: proto message updates Update the Switch RPC protos to make use of the 'optional' directive. Though this may not impact the generated types or how the user interacts with these types, it may serve to document the fact that they are optional a bit better.

switchrpc: add new BuildOnion rpc proto

switchrpc: add new TrackOnion rpc proto

switchrpc: add new SendOnion rpc proto Support all fields from UpdateAddHtlc. This allows users of the SendOnion RPC to include all fields that we support using with the UpdateAddHtlc type.

switchrpc: add new grpc subserver The SwitchRPC server will be hidden behind a non default build tag.

multi: preserve invoice HTLC replay outcomes Keep unexpected invoice lookup errors retryable instead of turning them into terminal HTLC failures. Resolve recorded HTLCs before invoking the interceptor, while retaining the atomic replay check during the invoice update. Only turn interceptor errors for confirmed-new HTLCs into individual failures. Update failure reporting and multi-backend regression tests to cover the final behavior. (cherry picked from commit 044d260bb6b4fb93d52b966376b0a7e0645dac6b)

multi: preserve invoice HTLC replay outcomes Keep unexpected invoice lookup errors retryable instead of turning them into terminal HTLC failures. Resolve recorded HTLCs before invoking the interceptor, while retaining the atomic replay check during the invoice update. Only turn interceptor errors for confirmed-new HTLCs into individual failures. Update failure reporting and multi-backend regression tests to cover the final behavior. (cherry picked from commit 044d260bb6b4fb93d52b966376b0a7e0645dac6b)

routerrpc: FailureDetail enums for invoice/AMP validation failures (cherry picked from commit 05eed5cdb40bd38f1b2f078dfad043d39ad91ce6)

2026-09-22

multi: preserve invoice HTLC replay outcomes Keep unexpected invoice lookup errors retryable instead of turning them into terminal HTLC failures. Resolve recorded HTLCs before invoking the interceptor, while retaining the atomic replay check during the invoice update. Only turn interceptor errors for confirmed-new HTLCs into individual failures. Update failure reporting and multi-backend regression tests to cover the final behavior. (cherry picked from commit 044d260bb6b4fb93d52b966376b0a7e0645dac6b)

routerrpc: FailureDetail enums for invoice/AMP validation failures (cherry picked from commit 05eed5cdb40bd38f1b2f078dfad043d39ad91ce6)

multi: preserve invoice HTLC replay outcomes Keep unexpected invoice lookup errors retryable instead of turning them into terminal HTLC failures. Resolve recorded HTLCs before invoking the interceptor, while retaining the atomic replay check during the invoice update. Only turn interceptor errors for confirmed-new HTLCs into individual failures. Update failure reporting and multi-backend regression tests to cover the final behavior.

2026-09-19

docs+routerrpc: document that interceptor outgoing amount is untrusted The `outgoing_amount_msat` field of `ForwardHtlcInterceptRequest` is the sender's `amt_to_forward` value copied straight out of the onion payload. The incoming link does not validate it, and the switch only compares it against the real incoming amount and the outgoing forwarding policy in `CheckHtlcForward` when the HTLC is resumed. When the interceptor answers with SETTLE that check never runs, so an interceptor that credits the outgoing amount can be made to release a preimage for far more than the incoming HTLC is actually worth. The field comments did not say any of this, and the naming makes the outgoing amount look like "the" amount. Spell out that only `incoming_amount_msat` reflects what the peer committed to, and that the `in_amount_msat` override on RESUME_MODIFIED replaces the value used by the policy check without changing what is actually received. Generated files are updated by hand to match the proto comments since only comments changed. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> (cherry picked from commit cee8ed624e17a91dc4c46ccf0cff0d8dab26056d)

docs+routerrpc: document that interceptor outgoing amount is untrusted The `outgoing_amount_msat` field of `ForwardHtlcInterceptRequest` is the sender's `amt_to_forward` value copied straight out of the onion payload. The incoming link does not validate it, and the switch only compares it against the real incoming amount and the outgoing forwarding policy in `CheckHtlcForward` when the HTLC is resumed. When the interceptor answers with SETTLE that check never runs, so an interceptor that credits the outgoing amount can be made to release a preimage for far more than the incoming HTLC is actually worth. The field comments did not say any of this, and the naming makes the outgoing amount look like "the" amount. Spell out that only `incoming_amount_msat` reflects what the peer committed to, and that the `in_amount_msat` override on RESUME_MODIFIED replaces the value used by the policy check without changing what is actually received. Generated files are updated by hand to match the proto comments since only comments changed. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> (cherry picked from commit cee8ed624e17a91dc4c46ccf0cff0d8dab26056d)

2026-09-18

docs+routerrpc: document that interceptor outgoing amount is untrusted The `outgoing_amount_msat` field of `ForwardHtlcInterceptRequest` is the sender's `amt_to_forward` value copied straight out of the onion payload. The incoming link does not validate it, and the switch only compares it against the real incoming amount and the outgoing forwarding policy in `CheckHtlcForward` when the HTLC is resumed. When the interceptor answers with SETTLE that check never runs, so an interceptor that credits the outgoing amount can be made to release a preimage for far more than the incoming HTLC is actually worth. The field comments did not say any of this, and the naming makes the outgoing amount look like "the" amount. Spell out that only `incoming_amount_msat` reflects what the peer committed to, and that the `in_amount_msat` override on RESUME_MODIFIED replaces the value used by the policy check without changing what is actually received. Generated files are updated by hand to match the proto comments since only comments changed. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

2026-09-15

walletrpc: expose configurable output leases Add optional confirmation-depth fields to LeaseOutput and FundPsbt. A non-zero value selects a lease that ignores wall-clock expiry and releases at the requested spend depth or by explicit owner release. Zero preserves time-controlled leases. Resolve wallet capability before acquiring inputs so unsupported backends fail closed even when FundPsbt selects no new input. Echo the accepted depth after installation, and expose persisted spend height through ListLeases so clients can observe confirmation and reorg progress. Cover option forwarding, zero-depth compatibility, unsupported wallets, partial acquisition rollback, and response marshalling.

2026-09-11

walletrpc: return the master key birthday from ListAccounts In this commit, we add a master_key_birthday_timestamp field to ListAccountsResponse and populate it from the wallet. The accounts in that response are extended public keys, and an xpub says nothing about when it was created. That's a problem for the one thing the response exists for: exporting a signer's accounts so a watch-only wallet can import them. The importing side has no birthday to work with, so lnd substitutes the aezeed "Bitcoin Days Genesis" epoch of 2017-08-24 and rescans from there. On mainnet that's hundreds of thousands of blocks and several hours, even for a node with no history whatsoever. See lightninglabs/lndinit#97 for what that looks like in practice. The field is named to match WatchOnly.master_key_birthday_timestamp on the InitWallet request, which is where the value ends up, and it round-trips through the accounts JSON file that lncli's createwatchonly and lndinit both read. A wallet that somehow has no birthday at all reports zero rather than the nonsense a uint64 cast of a pre-epoch time would produce, since zero is already what InitWallet reads as "unknown".

2026-09-03

walletrpc: expose configurable output leases Add optional confirmation-depth fields to LeaseOutput and FundPsbt. A non-zero value selects a lease that ignores wall-clock expiry and releases at the requested spend depth or by explicit owner release. Zero preserves time-controlled leases. Resolve wallet capability before acquiring inputs so unsupported backends fail closed even when FundPsbt selects no new input. Echo the accepted depth after installation, and expose persisted spend height through ListLeases so clients can observe confirmation and reorg progress. Cover option forwarding, zero-depth compatibility, unsupported wallets, partial acquisition rollback, and response marshalling.

2026-08-31

Merge pull request #11064 from NishantBansal2003/explicit-chan-type funding: require explicit channel type in all negotiations

2026-08-28

multi: require explicit channel type in all negotiations Move from optional implicit negotiation to mandatory explicit channel type in OpenChannel and AcceptChannel. The returned ChannelType is now always non-nil. Channel type is required in all negotiations now. We only fallback to a default channel type when the RPC caller does not explicitly specify one. Signed-off-by: Nishant Bansal <nishant.bansal.282003@gmail.com>

2026-08-17

lnrpc: document payment request fields Document the encoding, units, defaults, and absent-value behavior of every field returned by DecodePayReq. Clarify in particular that expiry is a relative duration from the invoice timestamp and defaults to 3600 seconds when the BOLT-11 expiry field is omitted. This is a documentation-only change and does not alter RPC behavior.

walletrpc: define the XCreateAccount RPC Declares the RPC and its messages, and regenerates the stubs. The implementation follows in the next commits. The account's address type selects the BIP-0043 key scope it is created under, which is permanent and also fixes the address type of its change outputs, so the proto spells out both that pairing and the fact that a seed-only recovery does not rediscover funds held in such an account. The X prefix follows XImportMissionControl and the XAddLocalChanAliases family: it marks the API as experimental, so it may change or be removed without the usual deprecation period. It comes off once a seed-only recovery can find these accounts. (cherry picked from commit 9a6a3a701365130cf5249b2f66b18cad96dcea38)

Merge pull request #11065 from ellemouton/agent/walletrpc-create-account walletrpc: add XCreateAccount for wallet-derived accounts

2026-08-13

walletrpc: define the XCreateAccount RPC Declares the RPC and its messages, and regenerates the stubs. The implementation follows in the next commits. The account's address type selects the BIP-0043 key scope it is created under, which is permanent and also fixes the address type of its change outputs, so the proto spells out both that pairing and the fact that a seed-only recovery does not rediscover funds held in such an account. The X prefix follows XImportMissionControl and the XAddLocalChanAliases family: it marks the API as experimental, so it may change or be removed without the usual deprecation period. It comes off once a seed-only recovery can find these accounts.

watchonlyrpc: add `SignCoordinatorStreams` RPC To enable an outbound remote signer to connect to the watch-only lnd node, we add a SignCoordinatorStreams bi-directional streaming RPC endpoint. The stream created when the remote signer connects to this endpoint can be used to pass any requests to the remote signer and to receive the corresponding responses. The RPC endpoint is added to the new `watchonlyrpc` package, which will have a dedicated RPC server that specifically accepts incoming requests from the remote signer. We clearly define the types of requests and responses that can be sent over the stream, including all the requests that can be sent to the remote signer with the previous implementation. Those are the ones sent to the `signrpc.SignerClient` and `walletrpc.WalletKitClient` in the `lnwallet/rpcwallet.go` file. We also include messages for the required handshake between the remote signer and the watch-only node, and a message that the remote signer can send if it encounters an error while processing a request.

2026-08-05

lnwallet+walletrpc: add SubmitPackage for v3 CPFP package relay Add SubmitPackage to the lnwallet.WalletController interface and a new WalletKit.SubmitPackage RPC, so a client of lnd can relay a package of related transactions (parents first, child last) through lnd's own chain connection. This lets a zero-fee v3/TRUC parent be accepted via its fee-paying CPFP child without the caller needing a separate connection to the chain backend. BtcWallet.SubmitPackage forwards to the chain backend's submitpackage for bitcoind/btcd, and broadcasts each transaction individually for neutrino (no mempool; relies on the peer's 1p1c package relay). The WalletKit handler maps the proto request/response to the btcjson result and is gated by the onchain:write macaroon permission. Mock controllers and the no-chain backend gain trivial implementations. (cherry picked from commit f55c0565d02cff63760b055970d36eca82e2beb1) Backport note: the original bumps btcwallet to v0.18.0, which sits on top of the btcd v2 module migration. This branch tracks the pre-v2 btcd layout, so it pins btcwallet v0.16.19 instead: the same chain.Interface SubmitPackage backported onto the v0.16 line. The lnd-side change is otherwise unmodified.

2026-08-04

lnwallet+walletrpc: add SubmitPackage for v3 CPFP package relay Add SubmitPackage to the lnwallet.WalletController interface and a new WalletKit.SubmitPackage RPC, so a client of lnd can relay a package of related transactions (parents first, child last) through lnd's own chain connection. This lets a zero-fee v3/TRUC parent be accepted via its fee-paying CPFP child without the caller needing a separate connection to the chain backend. BtcWallet.SubmitPackage forwards to the chain backend's submitpackage for bitcoind/btcd, and broadcasts each transaction individually for neutrino (no mempool; relies on the peer's 1p1c package relay). The WalletKit handler maps the proto request/response to the btcjson result and is gated by the onchain:write macaroon permission. Mock controllers and the no-chain backend gain trivial implementations. (cherry picked from commit f55c0565d02cff63760b055970d36eca82e2beb1)

2026-07-30

routerrpc: allow BuildRoute RPC to use arbitrary source The routerrpc.Server and ChannelRouter assume that the source public key for a route is always the node’s public key when calling BuildRoute. We update to allow overriding of this field to any arbitrary public key. The list of hop public keys must be connected to the source via channels in our graph view.

lnrpc: allow arbitrary route source The RouterBackend assumes that the source public key for a route is always the node’s public key when calling UnmarshallRoute. Here we update to allow overriding of this field to any arbitrary public key.

lnrpc/routerrpc: add outgoing_node_id to HTLC intercept request A blinded route may identify the next hop by node ID (next_node_id) rather than by channel, in which case there is no sender-specified outgoing channel to report to an HTLC interceptor. Add an outgoing_node_id field to ForwardHtlcInterceptRequest to carry the next hop's public key for these forwards, and document that outgoing_requested_chan_id then holds a reserved sentinel value so that clients switching on a zero channel ID to detect the exit hop do not misclassify the forward as a final receive. This commit only adds the schema and regenerated stubs; the fields are populated by later commits. (cherry picked from commit 14640a501658cd18853b14a2f2d2ff86b56dfbf8)

lnrpc/routerrpc: add outgoing_node_id to HTLC intercept request A blinded route may identify the next hop by node ID (next_node_id) rather than by channel, in which case there is no sender-specified outgoing channel to report to an HTLC interceptor. Add an outgoing_node_id field to ForwardHtlcInterceptRequest to carry the next hop's public key for these forwards, and document that outgoing_requested_chan_id then holds a reserved sentinel value so that clients switching on a zero channel ID to detect the exit hop do not misclassify the forward as a final receive. This commit only adds the schema and regenerated stubs; the fields are populated by later commits. (cherry picked from commit 14640a501658cd18853b14a2f2d2ff86b56dfbf8)

2026-07-29

lnrpc/routerrpc: add outgoing_node_id to HTLC intercept request A blinded route may identify the next hop by node ID (next_node_id) rather than by channel, in which case there is no sender-specified outgoing channel to report to an HTLC interceptor. Add an outgoing_node_id field to ForwardHtlcInterceptRequest to carry the next hop's public key for these forwards, and document that outgoing_requested_chan_id then holds a reserved sentinel value so that clients switching on a zero channel ID to detect the exit hop do not misclassify the forward as a final receive. This commit only adds the schema and regenerated stubs; the fields are populated by later commits.

2026-07-28

routerrpc: allow BuildRoute RPC to use arbitrary source The routerrpc.Server and ChannelRouter assume that the source public key for a route is always the node’s public key when calling BuildRoute. We update to allow overriding of this field to any arbitrary public key. The list of hop public keys must be connected to the source via channels in our graph view.

lnrpc: allow arbitrary route source The RouterBackend assumes that the source public key for a route is always the node’s public key when calling UnmarshallRoute. Here we update to allow overriding of this field to any arbitrary public key.

switchrpc: add DisableRemoteRouter rpc In this commit, we add a DisableRemoteRouter RPC to the switchrpc sub-server that allows an operator to transition from external (switchrpc) back to local payment lifecycle management. The handler delegates to the Switch's DisableRemoteRouter method and distinguishes between precondition failures (attempt entries still exist) and internal errors, returning codes.FailedPrecondition or codes.Internal respectively. This gives callers a clear signal to drain pending attempts before retrying.

switchrpc: add DeleteAttempts RPC Expose the store-layer DeleteAttempts as a gRPC endpoint on the Switch sub-server, allowing remote callers to garbage-collect terminal attempt records by explicitly naming the finished IDs. A unit test with a stateful mock demonstrates that hard delete removes the idempotency protection, allowing re-dispatch with the same ID.

switchrpc: update SendOnion error handling Update both proto and handler to communicate error information via gRPC status details.

switchrpc: update TrackOnion rpc error handling The new structure uses a top-level `oneof` to provide a compile-time distinction between a successful payment (preimage) and a failed one. Additional information on a failed attempt can be found in FailureDetails. We now also use a structured ForwardingFailure type for communicating the failure index and wire message from failures which occur during htlc forwarding downstream in the route.

switchrpc: update sendonion rpc docs Clarify useage of API for rpc clients.

switchrpc: proto message updates Update the Switch RPC protos to make use of the 'optional' directive. Though this may not impact the generated types or how the user interacts with these types, it may serve to document the fact that they are optional a bit better.

switchrpc: add new BuildOnion rpc proto

switchrpc: add new TrackOnion rpc proto

switchrpc: add new SendOnion rpc proto Support all fields from UpdateAddHtlc. This allows users of the SendOnion RPC to include all fields that we support using with the UpdateAddHtlc type.

switchrpc: add new grpc subserver The SwitchRPC server will be hidden behind a non default build tag.

2026-07-25

walletrpc: return the master key birthday from ListAccounts In this commit, we add a master_key_birthday_timestamp field to ListAccountsResponse and populate it from the wallet. The accounts in that response are extended public keys, and an xpub says nothing about when it was created. That's a problem for the one thing the response exists for: exporting a signer's accounts so a watch-only wallet can import them. The importing side has no birthday to work with, so lnd substitutes the aezeed "Bitcoin Days Genesis" epoch of 2017-08-24 and rescans from there. On mainnet that's hundreds of thousands of blocks and several hours, even for a node with no history whatsoever. See lightninglabs/lndinit#97 for what that looks like in practice. The field is named to match WatchOnly.master_key_birthday_timestamp on the InitWallet request, which is where the value ends up, and it round-trips through the accounts JSON file that lncli's createwatchonly and lndinit both read. A wallet that somehow has no birthday at all reports zero rather than the nonsense a uint64 cast of a pre-epoch time would produce, since zero is already what InitWallet reads as "unknown".

2026-06-30

Merge pull request #10900 from ellemouton/walletkit-submitpackage lnwallet+walletrpc: add WalletKit.SubmitPackage for v3 CPFP package relay

lnwallet+walletrpc: add SubmitPackage for v3 CPFP package relay Add SubmitPackage to the lnwallet.WalletController interface and a new WalletKit.SubmitPackage RPC, so a client of lnd can relay a package of related transactions (parents first, child last) through lnd's own chain connection. This lets a zero-fee v3/TRUC parent be accepted via its fee-paying CPFP child without the caller needing a separate connection to the chain backend. BtcWallet.SubmitPackage forwards to the chain backend's submitpackage for bitcoind/btcd, and broadcasts each transaction individually for neutrino (no mempool; relies on the peer's 1p1c package relay). The WalletKit handler maps the proto request/response to the btcjson result and is gated by the onchain:write macaroon permission. Mock controllers and the no-chain backend gain trivial implementations.

Merge pull request #10832 from bitromortac/2604-bolt12-1b bolt12: add `InvoiceRequest` codec and structural validators

2026-06-26

routerrpc: add clarifying docs for the intercepted forward routerrpc: document on-chain interceptor responses (cherry picked from commit 8909c2fbf5535b81ee18c4f4e7fe0160ca43e725)

routerrpc: add clarifying docs for the intercepted forward routerrpc: document on-chain interceptor responses (cherry picked from commit 8909c2fbf5535b81ee18c4f4e7fe0160ca43e725)

routerrpc: add clarifying docs for the intercepted forward routerrpc: document on-chain interceptor responses

2026-06-23

lnrpc: document reply_path verbatim passthrough on OnionMessageUpdate Document that the introduction_node field in an OnionMessageUpdate's reply_path is passed through verbatim from the wire, potentially carrying either a 33-byte pubkey or a 9-byte sciddir form. Subscribers wishing to reply must resolve sciddir forms against their local channel graph. The SubscribeOnionMessages bridge is refactored to use a new marshallBlindedPath helper, ensuring a nil reply path remains nil in the RPC response rather than being emitted as an empty struct.

2026-06-19

routerrpc: allow BuildRoute RPC to use arbitrary source The routerrpc.Server and ChannelRouter assume that the source public key for a route is always the node’s public key when calling BuildRoute. We update to allow overriding of this field to any arbitrary public key. The list of hop public keys must be connected to the source via channels in our graph view.

lnrpc: allow arbitrary route source The RouterBackend assumes that the source public key for a route is always the node’s public key when calling UnmarshallRoute. Here we update to allow overriding of this field to any arbitrary public key.

switchrpc: add DisableRemoteRouter rpc In this commit, we add a DisableRemoteRouter RPC to the switchrpc sub-server that allows an operator to transition from external (switchrpc) back to local payment lifecycle management. The handler delegates to the Switch's DisableRemoteRouter method and distinguishes between precondition failures (attempt entries still exist) and internal errors, returning codes.FailedPrecondition or codes.Internal respectively. This gives callers a clear signal to drain pending attempts before retrying.

switchrpc: add DeleteAttempts RPC Expose the store-layer DeleteAttempts as a gRPC endpoint on the Switch sub-server, allowing remote callers to garbage-collect terminal attempt records by explicitly naming the finished IDs. A unit test with a stateful mock demonstrates that hard delete removes the idempotency protection, allowing re-dispatch with the same ID.

switchrpc: update SendOnion error handling Update both proto and handler to communicate error information via gRPC status details.

switchrpc: update TrackOnion rpc error handling The new structure uses a top-level `oneof` to provide a compile-time distinction between a successful payment (preimage) and a failed one. Additional information on a failed attempt can be found in FailureDetails. We now also use a structured ForwardingFailure type for communicating the failure index and wire message from failures which occur during htlc forwarding downstream in the route.

switchrpc: update sendonion rpc docs Clarify useage of API for rpc clients.

switchrpc: proto message updates Update the Switch RPC protos to make use of the 'optional' directive. Though this may not impact the generated types or how the user interacts with these types, it may serve to document the fact that they are optional a bit better.

switchrpc: add new BuildOnion rpc proto

switchrpc: add new TrackOnion rpc proto

switchrpc: add new SendOnion rpc proto Support all fields from UpdateAddHtlc. This allows users of the SendOnion RPC to include all fields that we support using with the UpdateAddHtlc type.

switchrpc: add new grpc subserver The SwitchRPC server will be hidden behind a non default build tag.

2026-06-10

routerrpc: document default timeout for EstimateRouteFee probes The RouteFeeRequest.timeout field did not document its behavior when unset or explicitly set to zero. This is easy to misread as "no timeout", i.e. an unbounded, uncancellable probe, especially given the adjacent note that canceling the context does not stop the payment loop. In practice the probe path runs through SendPaymentV2, which replaces a zero timeout_seconds with DefaultPaymentTimeout (60 seconds) before dispatching the probe. A zero or unset timeout therefore falls back to the same 60 second default that SendPaymentRequest.timeout_seconds already documents. Mirror that wording on RouteFeeRequest.timeout so the zero-value behavior is explicit, and update the generated gRPC stub and swagger description to match. Documentation only; no behavior change.

2026-05-21

multi: rename "taproot" channel type to mean production variant 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. (cherry picked from commit 0aa1d8bdd6a5cbb10561d3a05d178a612663ba54)

multi: rename "taproot" channel type to mean production variant 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.

2026-05-19

proto: remove deprecated SendPayment, SendToRoute, TrackPayment RPCs 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. (cherry picked from commit d0768f0f78b8936c07595f1b97853a40bad7e7f5)

Merge pull request #10814 from erickcestari/deprecated-rpc-removal Remove deprecated Send* / TrackPayment RPCs and outgoing_chan_id field

proto: remove deprecated SendPayment, SendToRoute, TrackPayment RPCs 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.

2026-05-15

routerrpc: add outgoing_chan_ids to EstimateRouteFee

2026-05-12

lnwallet+walletrpc: add witness_size_hint RPC field for tapscript fees The previous taproot script path fee estimation passed `len(leafScript.Script)` as `leafWitnessSize` to `AddTapscriptInput`, which both double-counts the script and uses the wrong unit: `leafWitnessSize` is meant only for the witness stack elements that satisfy the revealed leaf (e.g. signatures), not the script itself. When no hint is supplied we now fall back to `input.TaprootSignatureWitnessSize` (a single Schnorr signature), matching every existing in-tree call site of `AddTapscriptInput`. For non-trivial leaves (e.g. multi-signature tapscripts) callers can supply an exact size via the new per-outpoint `witness_size_hint` field on `FundPsbtRequest`, threaded through `EstimateInputWeight`. The unit tests in `lnwallet/btcwallet` cover both the default and explicit-hint paths, and the integration test `testFundPsbtTaprootScriptPath` is extended to assert that a hint changes the realized fee by exactly the extra witness weight it requests.

2026-04-16

lnrpc+rpcserver: expose per-peer onion message stats in ListPeers Add an OnionMessageStats submessage with six uint64 fields that mirror the peer.OnionMessageStats snapshot struct 1:1 — bytes recv/sent for admitted traffic plus per-reason drop counters (peer, freebie, global, no-channel) — and hang it off the Peer message as onion_message_stats at tag 16. Regenerate the protobuf, gRPC gateway, and swagger stubs. Populate the new field in ListPeers by calling Brontide.OnionStats() for each connected peer and translating the six atomic-loaded counters into the proto message. The resulting rpc field lets operators see, per peer, how much onion traffic is actually flowing and which rate limiter (if any) is dropping messages — without which the freebie slot, strict gate, and relay-all policies are all opaque black boxes from lncli.

2026-04-13

lnrpc/walletrpc: add witness types for taproot chans final

lnrpc+rpcserver: add production taproot commitment type to RPC interface This commit extends the Lightning RPC interface to support production taproot channels by adding a new SIMPLE_TAPROOT_FINAL commitment type. This allows external clients to explicitly request channels that use the finalized taproot specification with optimized script structures and feature bits 80/81. The RPC server has been updated to properly handle the new commitment type during channel opening operations, mapping the SIMPLE_TAPROOT_FINAL type to the appropriate internal channel type flags including both SimpleTaprootFeatureBit and TaprootFinalBit. This ensures that channels opened through the RPC interface are properly configured with production taproot capabilities. The existing SIMPLE_TAPROOT commitment type has been clarified in its documentation to indicate that it represents the staging version using development scripts, providing clear distinction between the two taproot variants available to RPC clients. The protobuf definitions and generated code have been updated accordingly to support this new functionality.

2026-04-08

lnrpc/walletrpc: add witness types for taproot chans final

lnrpc+rpcserver: add production taproot commitment type to RPC interface This commit extends the Lightning RPC interface to support production taproot channels by adding a new SIMPLE_TAPROOT_FINAL commitment type. This allows external clients to explicitly request channels that use the finalized taproot specification with optimized script structures and feature bits 80/81. The RPC server has been updated to properly handle the new commitment type during channel opening operations, mapping the SIMPLE_TAPROOT_FINAL type to the appropriate internal channel type flags including both SimpleTaprootFeatureBit and TaprootFinalBit. This ensures that channels opened through the RPC interface are properly configured with production taproot capabilities. The existing SIMPLE_TAPROOT commitment type has been clarified in its documentation to indicate that it represents the staging version using development scripts, providing clear distinction between the two taproot variants available to RPC clients. The protobuf definitions and generated code have been updated accordingly to support this new functionality.

2026-03-27

routerrpc: add DeleteForwardingHistory to Router proto In this commit, we define the DeleteForwardingHistory RPC in the Router sub-server protocol and regenerate all derived Go stubs, JSON bindings, and Swagger documentation. The RPC uses a oneof for time specification, allowing callers to provide either an absolute Unix timestamp (delete_before_time) or a relative duration string (delete_before_duration, e.g. "-30d", "-1M"). The response includes the count of deleted events and total fees earned in millisatoshis, allowing operators to maintain financial records while purging detailed routing surveillance data.

2026-03-25

Merge pull request #10659 from guggero/lncli-wallet-psbt-sign lncli: add missing `wallet psbt sign` sub command

2026-03-24

Merge pull request #10658 from saubyk/fix_rpc_documentation Fix rpc documentation for Router Service

Merge pull request #10065 from ellemouton/asyncGraphCacheLoad graph/db: async graph cache population

routerrpc: add missing lncli tags for RPC documentation Add lncli: tags to SendPaymentV2, SendToRouteV2, and EstimateRouteFee proto definitions so the generated API docs correctly show their corresponding CLI commands (sendpayment, sendtoroute, estimateroutefee) instead of "There is no CLI command for this RPC".

lnrpc: add lncli command hint for API docs generator

lnrpc: expose graph cache state in GetInfo Add a GraphCacheStatus enum to GetInfoResponse so callers can tell whether the graph cache is disabled, still loading, or fully loaded. This makes the async graph cache startup state visible to operators and clients without changing the existing DB fallback behaviour for reads.

2026-03-19

lnrpc+rpcserver: add new info to WaitingCloseChannel Add a new fields blocks_til_closed and close_height to the WaitingCloseChannel message in PendingChannels RPC response. This shows users how many more blocks until the waiting close channel will be fully closed and removed. The required confirmations are determined by CloseConfsForCapacity which scales based on channel capacity for reorg safety. If the close tx is not yet confirmed, the full required confirmations are shown.

2026-03-12

multi: add omit_hops option to ListPayments RPC Add a new omit_hops field to ListPaymentsRequest that allows clients to skip loading hop-level route data for HTLC attempts, reducing both query cost and response size. When set, the route is returned with only route-level fields (TotalTimeLock, TotalAmount, SourcePubKey) and no individual hop data or hop-level custom records.

2026-03-07

lnrpc: add include_log field to GetDebugInfoRequest Add an `include_log` bool field to GetDebugInfoRequest proto message. When set to true, the server will include the log file content in the response in addition to the configuration map.

2026-03-02

multi: actor-based onion message forwarding Add onion message forwarding capability using the OnionPeerActor for communication. Messages are routed through a receptionist pattern where each peer has a dedicated OnionPeerActor for handling message sends. The OnionEndpoint uses the sphinx router for decoding and decrypting the onion message packet and the encrypted recipient data in the payload of the onion messages.