Get desktop application:
View/edit binary Protocol Buffers messages
Lightning is the main RPC server of the daemon.
lncli: `walletbalance` WalletBalance returns total unspent outputs(confirmed and unconfirmed), all confirmed unspent outputs and all unconfirmed unspent outputs under control of the wallet.
The wallet account the balance is shown for. If this is not specified, the balance of the "default" account is shown.
The minimum number of confirmations each one of your outputs used for the funding transaction must satisfy. If this is not specified, the default value of 1 is used.
The balance of the wallet
The confirmed balance of a wallet(with >= 1 confirmations)
The unconfirmed balance of a wallet(with 0 confirmations)
The total amount of wallet UTXOs held in outputs that are locked for other usage.
The amount of reserve required.
A mapping of each wallet account's name to its balance.
lncli: `channelbalance` ChannelBalance returns a report on the total funds across all open channels, categorized in local/remote, pending local/remote and unsettled local/remote balances.
(message has no fields)
Deprecated. Sum of channels balances denominated in satoshis
Deprecated. Sum of channels pending balances denominated in satoshis
Sum of channels local balances.
Sum of channels remote balances.
Sum of channels local unsettled balances.
Sum of channels remote unsettled balances.
Sum of channels pending local balances.
Sum of channels pending remote balances.
Custom channel data that might be populated if there are custom channels present.
lncli: `listchaintxns` GetTransactions returns a list describing all the known transactions relevant to the wallet.
lncli: `estimatefee` EstimateFee asks the chain backend to estimate the fee rate and total fees for a transaction that pays to multiple specified outputs. When using REST, the `AddrToAmount` map type can be set by appending `&AddrToAmount[<address>]=<amount_to_send>` to the URL. Unfortunately this map type doesn't appear in the REST API documentation because of a bug in the grpc-gateway library.
The map from addresses to amounts for the transaction.
The target number of blocks that this transaction should be confirmed by.
The minimum number of confirmations each one of your outputs used for the transaction must satisfy.
Whether unconfirmed outputs should be used as inputs for the transaction.
The strategy to use for selecting coins during fees estimation.
The total fee in satoshis.
Deprecated, use sat_per_vbyte. The fee rate in satoshi/vbyte.
The fee rate in satoshi/vbyte.
lncli: `sendcoins` SendCoins executes a request to send coins to a particular address. Unlike SendMany, this RPC call only allows creating a single output at a time. If neither target_conf, or sat_per_vbyte are set, then the internal wallet will consult its fee model to determine a fee for the default confirmation target.
The address to send coins to
The amount in satoshis to send
The target number of blocks that this transaction should be confirmed by.
A manual fee rate set in sat/vbyte that should be used when crafting the transaction.
Deprecated, use sat_per_vbyte. A manual fee rate set in sat/vbyte that should be used when crafting the transaction.
If set, the amount field should be unset. It indicates lnd will send all wallet coins or all selected coins to the specified address.
An optional label for the transaction, limited to 500 characters.
The minimum number of confirmations each one of your outputs used for the transaction must satisfy.
Whether unconfirmed outputs should be used as inputs for the transaction.
The strategy to use for selecting coins.
A list of selected outpoints as inputs for the transaction.
The transaction ID of the transaction
lncli: `listunspent` Deprecated, use walletrpc.ListUnspent instead. ListUnspent returns a list of all utxos spendable by the wallet with a number of confirmations between the specified minimum and maximum.
The minimum number of confirmations to be included.
The maximum number of confirmations to be included.
An optional filter to only include outputs belonging to an account.
A list of utxos
SubscribeTransactions creates a uni-directional stream from the server to the client in which any newly discovered transactions relevant to the wallet are sent over.
lncli: `sendmany` SendMany handles a request for a transaction that creates multiple specified outputs in parallel. If neither target_conf, or sat_per_vbyte are set, then the internal wallet will consult its fee model to determine a fee for the default confirmation target.
The map from addresses to amounts
The target number of blocks that this transaction should be confirmed by.
A manual fee rate set in sat/vbyte that should be used when crafting the transaction.
Deprecated, use sat_per_vbyte. A manual fee rate set in sat/vbyte that should be used when crafting the transaction.
An optional label for the transaction, limited to 500 characters.
The minimum number of confirmations each one of your outputs used for the transaction must satisfy.
Whether unconfirmed outputs should be used as inputs for the transaction.
The strategy to use for selecting coins during sending many requests.
The id of the transaction
lncli: `newaddress` NewAddress creates a new address under control of the local wallet.
The type of address to generate.
The name of the account to generate a new address for. If empty, the default wallet account is used.
The newly generated wallet address
lncli: `signmessage` SignMessage signs a message with this node's private key. The returned signature string is `zbase32` encoded and pubkey recoverable, meaning that only the message digest and signature are needed for verification.
The message to be signed. When using REST, this field must be encoded as base64.
Instead of the default double-SHA256 hashing of the message before signing, only use one round of hashing instead.
The signature for the given message
lncli: `verifymessage` VerifyMessage verifies a signature over a message and recovers the signer's public key. The signature is only deemed valid if the recovered public key corresponds to a node key in the public Lightning network. The signature must be zbase32 encoded and signed by an active node in the resident node's channel database. In addition to returning the validity of the signature, VerifyMessage also returns the recovered pubkey from the signature.
The message over which the signature is to be verified. When using REST, this field must be encoded as base64.
The signature to be verified over the given message
Whether the signature was valid over the given message
The pubkey recovered from the signature
lncli: `connect` ConnectPeer attempts to establish a connection to a remote peer. This is at the networking level, and is used for communication between nodes. This is distinct from establishing a channel with a peer.
Lightning address of the peer to connect to.
If set, the daemon will attempt to persistently connect to the target peer. Otherwise, the call will be synchronous.
The connection timeout value (in seconds) for this request. It won't affect other requests.
The status of the connect operation.
lncli: `disconnect` DisconnectPeer attempts to disconnect one peer from another identified by a given pubKey. In the case that we currently have a pending or active channel with the target peer, then this action will be not be allowed.
The pubkey of the node to disconnect from
The status of the disconnect operation.
lncli: `listpeers` ListPeers returns a verbose listing of all currently active peers.
If true, only the last error that our peer sent us will be returned with the peer's information, rather than the full set of historic errors we have stored.
The list of currently connected peers
SubscribePeerEvents creates a uni-directional stream from the server to the client in which any events relevant to the state of peers are sent over. Events include peers going online and offline.
(message has no fields)
The identity pubkey of the peer.
lncli: `getinfo` GetInfo returns general information concerning the lightning node including it's identity pubkey, alias, the chains it is connected to, and information concerning the number of open+pending channels.
(message has no fields)
The version of the LND software that the node is running.
The SHA1 commit hash that the daemon is compiled with.
The identity pubkey of the current node.
If applicable, the alias of the current node, e.g. "bob"
The color of the current node in hex code format
Number of pending channels
Number of active channels
Number of inactive channels
Number of peers
The node's current view of the height of the best block
The node's current view of the hash of the best block
Timestamp of the block best known to the wallet
Whether the wallet's view is synced to the main chain
Whether we consider ourselves synced with the public channel graph.
Whether the current node is connected to testnet. This field is deprecated and the network field should be used instead
A list of active chains the node is connected to. This will only ever contain a single entry since LND will only ever have a single chain backend during its lifetime.
The URIs of the current node.
Features that our node has advertised in our init message, node announcements and invoices.
Indicates whether the HTLC interceptor API is in always-on mode.
Indicates whether final htlc resolutions are stored on disk.
lncli: 'getdebuginfo' GetDebugInfo returns debug information concerning the state of the daemon and its subsystems. This includes the full configuration and the latest log entries from the log file.
(message has no fields)
* lncli: `getrecoveryinfo` GetRecoveryInfo returns information concerning the recovery mode including whether it's in a recovery mode, whether the recovery is finished, and the progress made so far.
(message has no fields)
Whether the wallet is in recovery mode
Whether the wallet recovery progress is finished
The recovery progress, ranging from 0 to 1.
lncli: `pendingchannels` PendingChannels returns a list of all the channels that are currently considered "pending". A channel is pending if it has finished the funding workflow and is waiting for confirmations for the funding txn, or is in the process of closure, either initiated cooperatively or non-cooperatively.
Indicates whether to include the raw transaction hex for waiting_close_channels.
The balance in satoshis encumbered in pending channels
Channels pending opening
Deprecated: Channels pending closing previously contained cooperatively closed channels with a single confirmation. These channels are now considered closed from the time we see them on chain.
Channels pending force closing
Channels waiting for closing tx to confirm
lncli: `listchannels` ListChannels returns a description of all the open channels that this node is a participant in.
Filters the response for channels with a target peer's pubkey. If peer is empty, all channels will be returned.
Informs the server if the peer alias lookup per channel should be enabled. It is turned off by default in order to avoid degradation of performance for existing clients.
The list of active channels
SubscribeChannelEvents creates a uni-directional stream from the server to the client in which any updates relevant to the state of the channels are sent over. Events include new active channels, inactive channels, and closed channels.
(message has no fields)
lncli: `closedchannels` ClosedChannels returns a description of all the closed channels that this node was a participant in.
OpenChannelSync is a synchronous version of the OpenChannel RPC call. This call is meant to be consumed by clients to the REST proxy. As with all other sync calls, all byte slices are intended to be populated as hex encoded strings.
lncli: `openchannel` OpenChannel attempts to open a singly funded channel specified in the request to a remote peer. Users are able to specify a target number of blocks that the funding transaction should be confirmed in, or a manual fee rate to us for the funding transaction. If neither are specified, then a lax block confirmation target is used. Each OpenStatusUpdate will return the pending channel ID of the in-progress channel. Depending on the arguments specified in the OpenChannelRequest, this pending channel ID can then be used to manually progress the channel funding flow.
Signals that the channel is now fully negotiated and the funding transaction published.
Signals that the channel's funding transaction has now reached the required number of confirmations on chain and can be used.
Signals that the funding process has been suspended and the construction of a PSBT that funds the channel PK script is now required.
The pending channel ID of the created channel. This value may be used to further the funding flow manually via the FundingStateStep method.
lncli: `batchopenchannel` BatchOpenChannel attempts to open multiple single-funded channels in a single transaction in an atomic way. This means either all channel open requests succeed at once or all attempts are aborted if any of them fail. This is the safer variant of using PSBTs to manually fund a batch of channels through the OpenChannel RPC.
The list of channels to open.
The target number of blocks that the funding transaction should be confirmed by.
A manual fee rate set in sat/vByte that should be used when crafting the funding transaction.
The minimum number of confirmations each one of your outputs used for the funding transaction must satisfy.
Whether unconfirmed outputs should be used as inputs for the funding transaction.
An optional label for the batch transaction, limited to 500 characters.
The strategy to use for selecting coins during batch opening channels.
FundingStateStep is an advanced funding related call that allows the caller to either execute some preparatory steps for a funding workflow, or manually progress a funding workflow. The primary way a funding flow is identified is via its pending channel ID. As an example, this method can be used to specify that we're expecting a funding flow for a particular pending channel ID, for which we need to use specific parameters. Alternatively, this can be used to interactively drive PSBT signing for funding for partially complete funding transactions.
The funding shim to register. This should be used before any channel funding has began by the remote party, as it is intended as a preparatory step for the full channel funding.
Used to cancel an existing registered funding shim.
Used to continue a funding flow that was initiated to be executed through a PSBT. This step verifies that the PSBT contains the correct outputs to fund the channel.
Used to continue a funding flow that was initiated to be executed through a PSBT. This step finalizes the funded and signed PSBT, finishes negotiation with the peer and finally publishes the resulting funding transaction.
(message has no fields)
ChannelAcceptor dispatches a bi-directional streaming RPC in which OpenChannel requests are sent to the client and the client responds with a boolean that tells LND whether or not to accept the channel. This allows node operators to specify their own criteria for accepting inbound channels through a single persistent connection.
Whether or not the client accepts the channel.
The pending channel id to which this response applies.
An optional error to send the initiating party to indicate why the channel was rejected. This field *should not* contain sensitive information, it will be sent to the initiating party. This field should only be set if accept is false, the channel will be rejected if an error is set with accept=true because the meaning of this response is ambiguous. Limited to 500 characters.
The upfront shutdown address to use if the initiating peer supports option upfront shutdown script (see ListPeers for the features supported). Note that the channel open will fail if this value is set for a peer that does not support this feature bit.
The csv delay (in blocks) that we require for the remote party.
The reserve amount in satoshis that we require the remote peer to adhere to. We require that the remote peer always have some reserve amount allocated to them so that there is always a disincentive to broadcast old state (if they hold 0 sats on their side of the channel, there is nothing to lose).
The maximum amount of funds in millisatoshis that we allow the remote peer to have in outstanding htlcs.
The maximum number of htlcs that the remote peer can offer us.
The minimum value in millisatoshis for incoming htlcs on the channel.
The number of confirmations we require before we consider the channel open.
Whether the responder wants this to be a zero-conf channel. This will fail if either side does not have the scid-alias feature bit set. The minimum depth field must be zero if this is true.
The pubkey of the node that wishes to open an inbound channel.
The hash of the genesis block that the proposed channel resides in.
The pending channel id.
The funding amount in satoshis that initiator wishes to use in the channel.
The push amount of the proposed channel in millisatoshis.
The dust limit of the initiator's commitment tx.
The maximum amount of coins in millisatoshis that can be pending in this channel.
The minimum amount of satoshis the initiator requires us to have at all times.
The smallest HTLC in millisatoshis that the initiator will accept.
The initial fee rate that the initiator suggests for both commitment transactions.
The number of blocks to use for the relative time lock in the pay-to-self output of both commitment transactions.
The total number of incoming HTLC's that the initiator will accept.
A bit-field which the initiator uses to specify proposed channel behavior.
The commitment type the initiator wishes to use for the proposed channel.
Whether the initiator wants to open a zero-conf channel via the channel type.
Whether the initiator wants to use the scid-alias channel type. This is separate from the feature bit.
lncli: `closechannel` CloseChannel attempts to close an active channel identified by its channel outpoint (ChannelPoint). The actions of this method can additionally be augmented to attempt a force close after a timeout period in the case of an inactive peer. If a non-force close (cooperative closure) is requested, then the user can specify either a target number of blocks until the closure transaction is confirmed, or a manual fee rate. If neither are specified, then a default lax, block confirmation target is used.
The outpoint (txid:index) of the funding transaction. With this value, Bob will be able to generate a signature for Alice's version of the commitment transaction.
If true, then the channel will be closed forcibly. This means the current commitment transaction will be signed and broadcast.
The target number of blocks that the closure transaction should be confirmed by.
Deprecated, use sat_per_vbyte. A manual fee rate set in sat/vbyte that should be used when crafting the closure transaction.
An optional address to send funds to in the case of a cooperative close. If the channel was opened with an upfront shutdown script and this field is set, the request to close will fail because the channel must pay out to the upfront shutdown addresss.
A manual fee rate set in sat/vbyte that should be used when crafting the closure transaction.
The maximum fee rate the closer is willing to pay. NOTE: This field is only respected if we're the initiator of the channel.
If true, then the rpc call will not block while it awaits a closing txid to be broadcasted to the mempool. To obtain the closing tx one has to listen to the stream for the particular updates. Moreover if a coop close is specified and this flag is set to true the coop closing flow will be initiated even if HTLCs are active on the channel. The channel will wait until all HTLCs are resolved and then start the coop closing process. The channel will be disabled in the meantime and will disallow any new HTLCs.
lncli: `abandonchannel` AbandonChannel removes all channel state from the database except for a close summary. This method can be used to get rid of permanently unusable channels due to bugs fixed in newer versions of lnd. This method can also be used to remove externally funded channels where the funding transaction was never broadcast. Only available for non-externally funded channels in dev build.
Override the requirement for being in dev mode by setting this to true and confirming the user knows what they are doing and this is a potential foot gun to lose funds if used on active channels.
The status of the abandon operation.
lncli: `sendpayment` Deprecated, use routerrpc.SendPaymentV2. SendPayment dispatches a bi-directional streaming RPC for sending payments through the Lightning Network. A single RPC invocation creates a persistent bi-directional stream allowing clients to rapidly send payments through the Lightning Network with a single persistent connection.
Deprecated, use routerrpc.SendPaymentV2. SendPaymentSync is the synchronous non-streaming version of SendPayment. This RPC is intended to be consumed by clients of the REST proxy. Additionally, this RPC expects the destination's public key and the payment hash (if any) to be encoded as hex strings.
lncli: `sendtoroute` Deprecated, use routerrpc.SendToRouteV2. SendToRoute is a bi-directional streaming RPC for sending payment through the Lightning Network. This method differs from SendPayment in that it allows users to specify a full route manually. This can be used for things like rebalancing, and atomic swaps.
Deprecated, use routerrpc.SendToRouteV2. SendToRouteSync is a synchronous version of SendToRoute. It Will block until the payment either fails or succeeds.
lncli: `addinvoice` AddInvoice attempts to add a new invoice to the invoice database. Any duplicated invoices are rejected, therefore all invoices *must* have a unique payment preimage.
A bare-bones invoice for a payment within the Lightning Network. With the details of the invoice, the sender has all the data necessary to send a payment to the recipient.
The "add" index of this invoice. Each newly created invoice will increment this index making it monotonically increasing. Callers to the SubscribeInvoices call can use this to instantly get notified of all added invoices with an add_index greater than this one.
The payment address of the generated invoice. This is also called payment secret in specifications (e.g. BOLT 11). This value should be used in all payments for this invoice as we require it for end to end security.
lncli: `listinvoices` ListInvoices returns a list of all the invoices currently stored within the database. Any active debug invoices are ignored. It has full support for paginated responses, allowing users to query for specific invoices through their add_index. This can be done by using either the first_index_offset or last_index_offset fields included in the response as the index_offset of the next request. By default, the first 100 invoices created will be returned. Backwards pagination is also supported through the Reversed flag.
If set, only invoices that are not settled and not canceled will be returned in the response.
The index of an invoice that will be used as either the start or end of a query to determine which invoices should be returned in the response.
The max number of invoices to return in the response to this query.
If set, the invoices returned will result from seeking backwards from the specified index offset. This can be used to paginate backwards.
If set, returns all invoices with a creation date greater than or equal to it. Measured in seconds since the unix epoch.
If set, returns all invoices with a creation date less than or equal to it. Measured in seconds since the unix epoch.
A list of invoices from the time slice of the time series specified in the request.
The index of the last item in the set of returned invoices. This can be used to seek further, pagination style.
The index of the last item in the set of returned invoices. This can be used to seek backwards, pagination style.
lncli: `lookupinvoice` LookupInvoice attempts to look up an invoice according to its payment hash. The passed payment hash *must* be exactly 32 bytes, if not, an error is returned.
The hex-encoded payment hash of the invoice to be looked up. The passed payment hash must be exactly 32 bytes, otherwise an error is returned. Deprecated now that the REST gateway supports base64 encoding of bytes fields.
The payment hash of the invoice to be looked up. When using REST, this field must be encoded as base64.
SubscribeInvoices returns a uni-directional stream (server -> client) for notifying the client of newly added/settled invoices. The caller can optionally specify the add_index and/or the settle_index. If the add_index is specified, then we'll first start by sending add invoice events for all invoices with an add_index greater than the specified value. If the settle_index is specified, then next, we'll send out all settle events for invoices with a settle_index greater than the specified value. One or both of these fields can be set. If no fields are set, then we'll only send out the latest add/settle events.
If specified (non-zero), then we'll first start by sending out notifications for all added indexes with an add_index greater than this value. This allows callers to catch up on any events they missed while they weren't connected to the streaming RPC.
If specified (non-zero), then we'll first start by sending out notifications for all settled indexes with an settle_index greater than this value. This allows callers to catch up on any events they missed while they weren't connected to the streaming RPC.
lncli: `decodepayreq` DecodePayReq takes an encoded payment request string and attempts to decode it, returning a full description of the conditions encoded within the payment request.
The payment request string to be decoded
lncli: `listpayments` ListPayments returns a list of all outgoing payments.
If true, then return payments that have not yet fully completed. This means that pending payments, as well as failed payments will show up if this field is set to true. This flag doesn't change the meaning of the indices, which are tied to individual payments.
The index of a payment that will be used as either the start or end of a query to determine which payments should be returned in the response. The index_offset is exclusive. In the case of a zero index_offset, the query will start with the oldest payment when paginating forwards, or will end with the most recent payment when paginating backwards.
The maximal number of payments returned in the response to this query.
If set, the payments returned will result from seeking backwards from the specified index offset. This can be used to paginate backwards. The order of the returned payments is always oldest first (ascending index order).
If set, all payments (complete and incomplete, independent of the max_payments parameter) will be counted. Note that setting this to true will increase the run time of the call significantly on systems that have a lot of payments, as all of them have to be iterated through to be counted.
If set, returns all payments with a creation date greater than or equal to it. Measured in seconds since the unix epoch.
If set, returns all payments with a creation date less than or equal to it. Measured in seconds since the unix epoch.
The list of payments
The index of the first item in the set of returned payments. This can be used as the index_offset to continue seeking backwards in the next request.
The index of the last item in the set of returned payments. This can be used as the index_offset to continue seeking forwards in the next request.
Will only be set if count_total_payments in the request was set. Represents the total number of payments (complete and incomplete, independent of the number of payments requested in the query) currently present in the payments database.
lncli: `deletepayments` DeletePayment deletes an outgoing payment from DB. Note that it will not attempt to delete an In-Flight payment, since that would be unsafe.
Payment hash to delete.
Only delete failed HTLCs from the payment, not the payment itself.
The status of the delete operation.
lncli: `deletepayments --all` DeleteAllPayments deletes all outgoing payments from DB. Note that it will not attempt to delete In-Flight payments, since that would be unsafe.
Only delete failed payments.
Only delete failed HTLCs from payments, not the payment itself.
Delete all payments. NOTE: Using this option requires careful consideration as it is a destructive operation.
The status of the delete operation.
lncli: `describegraph` DescribeGraph returns a description of the latest graph state from the point of view of the node. The graph information is partitioned into two components: all the nodes/vertexes, and all the edges that connect the vertexes themselves. As this is a directed graph, the edges also contain the node directional specific routing policy which includes: the time lock delta, fee information, etc.
Whether unannounced channels are included in the response or not. If set, unannounced channels are included. Unannounced channels are both private channels, and public channels that are not yet announced to the network.
Returns a new instance of the directed channel graph.
The list of `LightningNode`s in this channel graph
The list of `ChannelEdge`s in this channel graph
lncli: `getnodemetrics` GetNodeMetrics returns node metrics calculated from the graph. Currently the only supported metric is betweenness centrality of individual nodes.
The requested node metrics.
Betweenness centrality is the sum of the ratio of shortest paths that pass through the node for each pair of nodes in the graph (not counting paths starting or ending at this node). Map of node pubkey to betweenness centrality of the node. Normalized values are in the [0,1] closed interval.
lncli: `getchaninfo` GetChanInfo returns the latest authenticated network announcement for the given channel identified by its channel ID: an 8-byte integer which uniquely identifies the location of transaction's funding output within the blockchain.
The unique channel ID for the channel. The first 3 bytes are the block height, the next 3 the index within the block, and the last 2 bytes are the output index for the channel.
The channel point of the channel in format funding_txid:output_index. If chan_id is specified, this field is ignored.
lncli: `getnodeinfo` GetNodeInfo returns the latest advertised, aggregated, and authenticated channel information for the specified node identified by its public key.
The 33-byte hex-encoded compressed public of the target node
If true, will include all known channels associated with the node.
An individual vertex/node within the channel graph. A node is connected to other nodes by one or more channel edges emanating from it. As the graph is directed, a node will also have an incoming edge attached to it for each outgoing edge.
The total number of channels for the node.
The sum of all channels capacity for the node, denominated in satoshis.
A list of all public channels for the node.
lncli: `queryroutes` QueryRoutes attempts to query the daemon's Channel Router for a possible route to a target destination capable of carrying a specific amount of satoshis. The returned route contains the full details required to craft and send an HTLC, also including the necessary information that should be present within the Sphinx packet encapsulated within the HTLC. When using REST, the `dest_custom_records` map type can be set by appending `&dest_custom_records[<record_number>]=<record_data_base64_url_encoded>` to the URL. Unfortunately this map type doesn't appear in the REST API documentation because of a bug in the grpc-gateway library.
The 33-byte hex-encoded public key for the payment destination
The amount to send expressed in satoshis. The fields amt and amt_msat are mutually exclusive.
The amount to send expressed in millisatoshis. The fields amt and amt_msat are mutually exclusive.
An optional CLTV delta from the current height that should be used for the timelock of the final hop. Note that unlike SendPayment, QueryRoutes does not add any additional block padding on top of final_ctlv_delta. This padding of a few blocks needs to be added manually or otherwise failures may happen when a block comes in while the payment is in flight. Note: must not be set if making a payment to a blinded path (delta is set by the aggregate parameters provided by blinded_payment_paths)
The maximum number of satoshis that will be paid as a fee of the payment. This value can be represented either as a percentage of the amount being sent, or as a fixed amount of the maximum fee the user is willing the pay to send the payment. If not specified, lnd will use a default value of 100% fees for small amounts (<=1k sat) or 5% fees for larger amounts.
A list of nodes to ignore during path finding. When using REST, these fields must be encoded as base64.
Deprecated. A list of edges to ignore during path finding.
The source node where the request route should originated from. If empty, self is assumed.
If set to true, edge probabilities from mission control will be used to get the optimal route.
A list of directed node pairs that will be ignored during path finding.
An optional maximum total time lock for the route. If the source is empty or ourselves, this should not exceed lnd's `--max-cltv-expiry` setting. If zero, then the value of `--max-cltv-expiry` is used as the limit.
An optional field that can be used to pass an arbitrary set of TLV records to a peer which understands the new records. This can be used to pass application specific data during the payment attempt. If the destination does not support the specified records, an error will be returned. Record types are required to be in the custom range >= 65536. When using REST, the values must be encoded as base64.
The channel id of the channel that must be taken to the first hop. If zero, any channel may be used.
The pubkey of the last hop of the route. If empty, any hop may be used.
Optional route hints to reach the destination through private channels.
An optional blinded path(s) to reach the destination. Note that the introduction node must be provided as the first hop in the route.
Features assumed to be supported by the final node. All transitive feature dependencies must also be set properly. For a given feature bit pair, either optional or remote may be set, but not both. If this field is nil or empty, the router will try to load destination features from the graph as a fallback. Note: must not be set if making a payment to a blinded route (features are provided in blinded_payment_paths).
The time preference for this payment. Set to -1 to optimize for fees only, to 1 to optimize for reliability only or a value inbetween for a mix.
The route that results from the path finding operation. This is still a repeated field to retain backwards compatibility.
The success probability of the returned route based on the current mission control state. [EXPERIMENTAL]
lncli: `getnetworkinfo` GetNetworkInfo returns some basic stats about the known channel graph from the point of view of the node.
(message has no fields)
The number of edges marked as zombies.
lncli: `stop` StopDaemon will send a shutdown request to the interrupt handler, triggering a graceful shutdown of the daemon.
(message has no fields)
The status of the stop operation.
SubscribeChannelGraph launches a streaming RPC that allows the caller to receive notifications upon any changes to the channel graph topology from the point of view of the responding node. Events notified include: new nodes coming online, nodes updating their authenticated attributes, new channels being advertised, updates in the routing policy for a directional channel edge, and when channels are closed on-chain.
(message has no fields)
lncli: `debuglevel` DebugLevel allows a caller to programmatically set the logging verbosity of lnd. The logging can be targeted according to a coarse daemon-wide logging level, or in a granular fashion to specify the logging for a target sub-system.
lncli: `feereport` FeeReport allows the caller to obtain a report detailing the current fee schedule enforced by the node globally for each channel.
(message has no fields)
An array of channel fee reports which describes the current fee schedule for each channel.
The total amount of fee revenue (in satoshis) the switch has collected over the past 24 hrs.
The total amount of fee revenue (in satoshis) the switch has collected over the past 1 week.
The total amount of fee revenue (in satoshis) the switch has collected over the past 1 month.
lncli: `updatechanpolicy` UpdateChannelPolicy allows the caller to update the fee schedule and channel policies for all channels globally, or a particular channel.
If set, then this update applies to all currently active channels.
If set, this update will target a specific channel.
The base fee charged regardless of the number of milli-satoshis sent.
The effective fee rate in milli-satoshis. The precision of this value goes up to 6 decimal places, so 1e-6.
The effective fee rate in micro-satoshis (parts per million).
The required timelock delta for HTLCs forwarded over the channel.
If set, the maximum HTLC size in milli-satoshis. If unset, the maximum HTLC will be unchanged.
The minimum HTLC size in milli-satoshis. Only applied if min_htlc_msat_specified is true.
If true, min_htlc_msat is applied.
Optional inbound fee. If unset, the previously set value will be retained [EXPERIMENTAL].
Under unknown circumstances a channel can exist with a missing edge in the graph database. This can cause an 'edge not found' error when calling `getchaninfo` and/or cause the default channel policy to be used during forwards. Setting this flag will recreate the edge if not found, allowing updating this channel policy and fixing the missing edge problem for this channel permanently. For fields not set in this command, the default policy will be created.
List of failed policy updates.
lncli: `fwdinghistory` ForwardingHistory allows the caller to query the htlcswitch for a record of all HTLCs forwarded within the target time range, and integer offset within that time range, for a maximum number of events. If no maximum number of events is specified, up to 100 events will be returned. If no time-range is specified, then events will be returned in the order that they occured. A list of forwarding events are returned. The size of each forwarding event is 40 bytes, and the max message size able to be returned in gRPC is 4 MiB. As a result each message can only contain 50k entries. Each response has the index offset of the last entry. The index offset can be provided to the request to allow the caller to skip a series of records.
Start time is the starting point of the forwarding history request. All records beyond this point will be included, respecting the end time, and the index offset.
End time is the end point of the forwarding history request. The response will carry at most 50k records between the start time and the end time. The index offset can be used to implement pagination.
Index offset is the offset in the time series to start at. As each response can only contain 50k records, callers can use this to skip around within a packed time series.
The max number of events to return in the response to this query.
Informs the server if the peer alias should be looked up for each forwarding event.
A list of forwarding events from the time slice of the time series specified in the request.
The index of the last time in the set of returned forwarding events. Can be used to seek further, pagination style.
lncli: `exportchanbackup` ExportChannelBackup attempts to return an encrypted static channel backup for the target channel identified by it channel point. The backup is encrypted with a key generated from the aezeed seed of the user. The returned backup can either be restored using the RestoreChannelBackup method once lnd is running, or via the InitWallet and UnlockWallet methods from the WalletUnlocker service.
The target channel point to obtain a back up for.
ExportAllChannelBackups returns static channel backups for all existing channels known to lnd. A set of regular singular static channel backups for each channel are returned. Additionally, a multi-channel backup is returned as well, which contains a single encrypted blob containing the backups of each channel.
(message has no fields)
lncli: `verifychanbackup` VerifyChanBackup allows a caller to verify the integrity of a channel backup snapshot. This method will accept either a packed Single or a packed Multi. Specifying both will result in an error.
lncli: `restorechanbackup` RestoreChannelBackups accepts a set of singular channel backups, or a single encrypted multi-chan backup and attempts to recover any funds remaining within the channel. If we are able to unpack the backup, then the new channel will be shown under listchannels, as well as pending channels.
The channels to restore as a list of channel/backup pairs.
The channels to restore in the packed multi backup format. When using REST, this field must be encoded as base64.
The number of channels successfully restored.
SubscribeChannelBackups allows a client to sub-subscribe to the most up to date information concerning the state of all channel backups. Each time a new channel is added, we return the new set of channels, along with a multi-chan backup containing the backup info for all channels. Each time a channel is closed, we send a new update, which contains new new chan back ups, but the updated set of encrypted multi-chan backups with the closed channel(s) removed.
(message has no fields)
lncli: `bakemacaroon` BakeMacaroon allows the creation of a new macaroon with custom read and write permissions. No first-party caveats are added since this can be done offline.
The list of permissions the new macaroon should grant.
The root key ID used to create the macaroon, must be a positive integer.
Informs the RPC on whether to allow external permissions that LND is not aware of.
The hex encoded macaroon, serialized in binary format.
lncli: `listmacaroonids` ListMacaroonIDs returns all root key IDs that are in use.
(message has no fields)
The list of root key IDs that are in use.
lncli: `deletemacaroonid` DeleteMacaroonID deletes the specified macaroon ID and invalidates all macaroons derived from that ID.
The root key ID to be removed.
A boolean indicates that the deletion is successful.
lncli: `listpermissions` ListPermissions lists all RPC method URIs and their required macaroon permissions to access them.
(message has no fields)
A map between all RPC method URIs and their required macaroon permissions to access them.
CheckMacaroonPermissions checks whether a request follows the constraints imposed on the macaroon and that the macaroon is authorized to follow the provided permissions.
RegisterRPCMiddleware adds a new gRPC middleware to the interceptor chain. A gRPC middleware is software component external to lnd that aims to add additional business logic to lnd by observing/intercepting/validating incoming gRPC client requests and (if needed) replacing/overwriting outgoing messages before they're sent to the client. When registering the middleware must identify itself and indicate what custom macaroon caveats it wants to be responsible for. Only requests that contain a macaroon with that specific custom caveat are then sent to the middleware for inspection. The other option is to register for the read-only mode in which all requests/responses are forwarded for interception to the middleware but the middleware is not allowed to modify any responses. As a security measure, _no_ middleware can modify responses for requests made with _unencumbered_ macaroons!
The request message ID this response refers to. Must always be set when giving feedback to an intercept but is ignored for the initial registration message.
The middleware can only send two types of messages to lnd: The initial registration message that identifies the middleware and after that only feedback messages to requests sent to the middleware.
The registration message identifies the middleware that's being registered in lnd. The registration message must be sent immediately after initiating the RegisterRpcMiddleware stream, otherwise lnd will time out the attempt and terminate the request. NOTE: The middleware will only receive interception messages for requests that contain a macaroon with the custom caveat that the middleware declares it is responsible for handling in the registration message! As a security measure, _no_ middleware can intercept requests made with _unencumbered_ macaroons!
The middleware received an interception request and gives feedback to it. The request_id indicates what message the feedback refers to.
The unique ID of the intercepted original gRPC request. Useful for mapping request to response when implementing full duplex message interception. For streaming requests, this will be the same ID for all incoming and outgoing middleware intercept messages of the _same_ stream.
The raw bytes of the complete macaroon as sent by the gRPC client in the original request. This might be empty for a request that doesn't require macaroons such as the wallet unlocker RPCs.
The parsed condition of the macaroon's custom caveat for convenient access. This field only contains the value of the custom caveat that the handling middleware has registered itself for. The condition _must_ be validated for messages of intercept_type stream_auth and request!
There are three types of messages that will be sent to the middleware for inspection and approval: Stream authentication, request and response interception. The first two can only be accepted (=forward to main RPC server) or denied (=return error to client). Intercepted responses can also be replaced/overwritten.
Intercept stream authentication: each new streaming RPC call that is initiated against lnd and contains the middleware's custom macaroon caveat can be approved or denied based upon the macaroon in the stream header. This message will only be sent for streaming RPCs, unary RPCs must handle the macaroon authentication in the request interception to avoid an additional message round trip between lnd and the middleware.
Intercept incoming gRPC client request message: all incoming messages, both on streaming and unary RPCs, are forwarded to the middleware for inspection. For unary RPC messages the middleware is also expected to validate the custom macaroon caveat of the request.
Intercept outgoing gRPC response message: all outgoing messages, both on streaming and unary RPCs, are forwarded to the middleware for inspection and amendment. The response in this message is the original response as it was generated by the main RPC server. It can either be accepted (=forwarded to the client), replaced/overwritten with a new message of the same type, or replaced by an error message.
This is used to indicate to the client that the server has successfully registered the interceptor. This is only used in the very first message that the server sends to the client after the client sends the server the middleware registration message.
The unique message ID of this middleware intercept message. There can be multiple middleware intercept messages per single gRPC request (one for the incoming request and one for the outgoing response) or gRPC stream (one for each incoming message and one for each outgoing response). This message ID must be referenced when responding (accepting/rejecting/modifying) to an intercept message.
lncli: `sendcustom` SendCustomMessage sends a custom peer message.
Peer to send the message to
Message type. This value needs to be in the custom range (>= 32768). To send a type < custom range, lnd needs to be compiled with the `dev` build tag, and the message type to override should be specified in lnd's experimental protocol configuration.
Raw message data.
The status of the send operation.
lncli: `subscribecustom` SubscribeCustomMessages subscribes to a stream of incoming custom peer messages. To include messages with type outside of the custom range (>= 32768) lnd needs to be compiled with the `dev` build tag, and the message type to override should be specified in lnd's experimental protocol configuration.
(message has no fields)
Peer from which the message originates
Message type. This value will be in the custom range (>= 32768).
Raw message data
lncli: `listaliases` ListAliases returns the set of all aliases that have ever existed with their confirmed SCID (if it exists) and/or the base SCID (in the case of zero conf).
(message has no fields)
LookupHtlcResolution retrieves a final htlc resolution from the database. If the htlc has no final resolution yet, a NotFound grpc status code is returned.
Settled is true is the htlc was settled. If false, the htlc was failed.
Offchain indicates whether the htlc was resolved off-chain or on-chain.
State service is a always running service that exposes the current state of the wallet and RPC server.
SubscribeState subscribes to the state of the wallet. The current wallet state will always be delivered immediately.
(message has no fields)
GetState returns the current wallet state without streaming further changes.
(message has no fields)
WalletUnlocker is a service that is used to set up a wallet password for lnd at first startup, and unlock a previously set up wallet.
GenSeed is the first method that should be used to instantiate a new lnd instance. This method allows a caller to generate a new aezeed cipher seed given an optional passphrase. If provided, the passphrase will be necessary to decrypt the cipherseed to expose the internal wallet seed. Once the cipherseed is obtained and verified by the user, the InitWallet method should be used to commit the newly generated seed, and create the wallet.
aezeed_passphrase is an optional user provided passphrase that will be used to encrypt the generated aezeed cipher seed. When using REST, this field must be encoded as base64.
seed_entropy is an optional 16-bytes generated via CSPRNG. If not specified, then a fresh set of randomness will be used to create the seed. When using REST, this field must be encoded as base64.
cipher_seed_mnemonic is a 24-word mnemonic that encodes a prior aezeed cipher seed obtained by the user. This field is optional, as if not provided, then the daemon will generate a new cipher seed for the user. Otherwise, then the daemon will attempt to recover the wallet state linked to this cipher seed.
enciphered_seed are the raw aezeed cipher seed bytes. This is the raw cipher text before run through our mnemonic encoding scheme.
InitWallet is used when lnd is starting up for the first time to fully initialize the daemon and its internal wallet. At the very least a wallet password must be provided. This will be used to encrypt sensitive material on disk. In the case of a recovery scenario, the user can also specify their aezeed mnemonic and passphrase. If set, then the daemon will use this prior state to initialize its internal wallet. Alternatively, this can be used along with the GenSeed RPC to obtain a seed, then present it to the user. Once it has been verified by the user, the seed can be fed into this RPC in order to commit the new wallet.
wallet_password is the passphrase that should be used to encrypt the wallet. This MUST be at least 8 chars in length. After creation, this password is required to unlock the daemon. When using REST, this field must be encoded as base64.
cipher_seed_mnemonic is a 24-word mnemonic that encodes a prior aezeed cipher seed obtained by the user. This may have been generated by the GenSeed method, or be an existing seed.
aezeed_passphrase is an optional user provided passphrase that will be used to encrypt the generated aezeed cipher seed. When using REST, this field must be encoded as base64.
recovery_window is an optional argument specifying the address lookahead when restoring a wallet seed. The recovery window applies to each individual branch of the BIP44 derivation paths. Supplying a recovery window of zero indicates that no addresses should be recovered, such after the first initialization of the wallet.
channel_backups is an optional argument that allows clients to recover the settled funds within a set of channels. This should be populated if the user was unable to close out all channels and sweep funds before partial or total data loss occurred. If specified, then after on-chain recovery of funds, lnd begin to carry out the data loss recovery protocol in order to recover the funds in each channel from a remote force closed transaction.
stateless_init is an optional argument instructing the daemon NOT to create any *.macaroon files in its filesystem. If this parameter is set, then the admin macaroon returned in the response MUST be stored by the caller of the RPC as otherwise all access to the daemon will be lost!
extended_master_key is an alternative to specifying cipher_seed_mnemonic and aezeed_passphrase. Instead of deriving the master root key from the entropy of an aezeed cipher seed, the given extended master root key is used directly as the wallet's master key. This allows users to import/use a master key from another wallet. When doing so, lnd still uses its default SegWit only (BIP49/84) derivation paths and funds from custom/non-default derivation paths will not automatically appear in the on-chain wallet. Using an 'xprv' instead of an aezeed also has the disadvantage that the wallet's birthday is not known as that is an information that's only encoded in the aezeed, not the xprv. Therefore a birthday needs to be specified in extended_master_key_birthday_timestamp or a "safe" default value will be used.
extended_master_key_birthday_timestamp is the optional unix timestamp in seconds to use as the wallet's birthday when using an extended master key to restore the wallet. lnd will only start scanning for funds in blocks that are after the birthday which can speed up the process significantly. If the birthday is not known, this should be left at its default value of 0 in which case lnd will start scanning from the first SegWit block (481824 on mainnet).
watch_only is the third option of initializing a wallet: by importing account xpubs only and therefore creating a watch-only wallet that does not contain any private keys. That means the wallet won't be able to sign for any of the keys and _needs_ to be run with a remote signer that has the corresponding private keys and can serve signing RPC requests.
macaroon_root_key is an optional 32 byte macaroon root key that can be provided when initializing the wallet rather than letting lnd generate one on its own.
The binary serialized admin macaroon that can be used to access the daemon after creating the wallet. If the stateless_init parameter was set to true, this is the ONLY copy of the macaroon and MUST be stored safely by the caller. Otherwise a copy of this macaroon is also persisted on disk by the daemon, together with other macaroon files.
lncli: `unlock` UnlockWallet is used at startup of lnd to provide a password to unlock the wallet database.
wallet_password should be the current valid passphrase for the daemon. This will be required to decrypt on-disk material that the daemon requires to function properly. When using REST, this field must be encoded as base64.
recovery_window is an optional argument specifying the address lookahead when restoring a wallet seed. The recovery window applies to each individual branch of the BIP44 derivation paths. Supplying a recovery window of zero indicates that no addresses should be recovered, such after the first initialization of the wallet.
channel_backups is an optional argument that allows clients to recover the settled funds within a set of channels. This should be populated if the user was unable to close out all channels and sweep funds before partial or total data loss occurred. If specified, then after on-chain recovery of funds, lnd begin to carry out the data loss recovery protocol in order to recover the funds in each channel from a remote force closed transaction.
stateless_init is an optional argument instructing the daemon NOT to create any *.macaroon files in its file system.
(message has no fields)
lncli: `changepassword` ChangePassword changes the password of the encrypted wallet. This will automatically unlock the wallet database if successful.
current_password should be the current valid passphrase used to unlock the daemon. When using REST, this field must be encoded as base64.
new_password should be the new passphrase that will be needed to unlock the daemon. When using REST, this field must be encoded as base64.
stateless_init is an optional argument instructing the daemon NOT to create any *.macaroon files in its filesystem. If this parameter is set, then the admin macaroon returned in the response MUST be stored by the caller of the RPC as otherwise all access to the daemon will be lost!
new_macaroon_root_key is an optional argument instructing the daemon to rotate the macaroon root key when set to true. This will invalidate all previously generated macaroons.
The binary serialized admin macaroon that can be used to access the daemon after rotating the macaroon root key. If both the stateless_init and new_macaroon_root_key parameter were set to true, this is the ONLY copy of the macaroon that was created from the new root key and MUST be stored safely by the caller. Otherwise a copy of this macaroon is also persisted on disk by the daemon, together with other macaroon files.
Details specific to AMP HTLCs.
Used in:
An n-of-n secret share of the root seed from which child payment hashes and preimages are derived.
An identifier for the HTLC set that this HTLC belongs to.
A nonce used to randomize the child preimage and child hash from a given root_share.
The payment hash of the AMP HTLC.
The preimage used to settle this AMP htlc. This field will only be populated if the invoice is in InvoiceState_ACCEPTED or InvoiceState_SETTLED.
Used in:
The state the HTLCs associated with this setID are in.
The settle index of this HTLC set, if the invoice state is settled.
The time this HTLC set was settled expressed in unix epoch.
The total amount paid for the sub-invoice expressed in milli satoshis.
Used in:
`AddressType` has to be one of: - `p2wkh`: Pay to witness key hash (`WITNESS_PUBKEY_HASH` = 0) - `np2wkh`: Pay to nested witness key hash (`NESTED_PUBKEY_HASH` = 1) - `p2tr`: Pay to taproot pubkey (`TAPROOT_PUBKEY` = 4)
Used in:
,Used in:
, , , ,For non-zero-conf channels, this is the confirmed SCID. Otherwise, this is the first assigned "base" alias.
The set of all aliases stored for the base SCID.
Used in:
Value denominated in satoshis.
Value denominated in milli-satoshis.
Used in:
The pubkey of the node to open a channel with. When using REST, this field must be encoded as base64.
The number of satoshis the wallet should commit to the channel.
The number of satoshis to push to the remote side as part of the initial commitment state.
Whether this channel should be private, not announced to the greater network.
The minimum value in millisatoshi we will require for incoming HTLCs on the channel.
The delay we require on the remote's commitment transaction. If this is not set, it will be scaled automatically with the channel size.
Close address is an optional address which specifies the address to which funds should be paid out to upon cooperative close. This field may only be set if the peer supports the option upfront feature bit (call listpeers to check). The remote peer will only accept cooperative closes to this address if it is set. Note: If this value is set on channel creation, you will *not* be able to cooperatively close out to a different address.
An optional, unique identifier of 32 random bytes that will be used as the pending channel ID to identify the channel while it is in the pre-pending state.
The explicit commitment type to use. Note this field will only be used if the remote peer supports explicit channel negotiation.
The maximum amount of coins in millisatoshi that can be pending within the channel. It only applies to the remote party.
The maximum number of concurrent HTLCs we will allow the remote party to add to the commitment transaction.
Max local csv is the maximum csv delay we will allow for our own commitment transaction.
If this is true, then a zero-conf channel open will be attempted.
If this is true, then an option-scid-alias channel-type open will be attempted.
The base fee charged regardless of the number of milli-satoshis sent.
The fee rate in ppm (parts per million) that will be charged in proportion of the value of each forwarded HTLC.
If use_base_fee is true the open channel announcement will update the channel base fee with the value specified in base_fee. In the case of a base_fee of 0 use_base_fee is needed downstream to distinguish whether to use the default base fee value specified in the config or 0.
If use_fee_rate is true the open channel announcement will update the channel fee rate with the value specified in fee_rate. In the case of a fee_rate of 0 use_fee_rate is needed downstream to distinguish whether to use the default fee rate value specified in the config or 0.
The number of satoshis we require the remote peer to reserve. This value, if specified, must be above the dust limit and below 20% of the channel capacity.
An optional note-to-self to go along with the channel containing some useful information. This is only ever stored locally and in no way impacts the channel's operation.
Used in:
The blinded public key of the node.
An encrypted blob of data provided to the blinded node.
Used in:
The unblinded pubkey of the introduction node for the route.
The ephemeral pubkey used by nodes in the blinded route.
A set of blinded node keys and data blobs for the blinded portion of the route. Note that the first hop is expected to be the introduction node, so the route is always expected to have at least one hop.
Used in:
The minimum number of real hops to include in a blinded path. This doesn't include our node, so if the minimum is 1, then the path will contain at minimum our node along with an introduction node hop. If it is zero then the shortest path will use our node as an introduction node.
The number of hops to include in a blinded path. This doesn't include our node, so if it is 1, then the path will contain our node along with an introduction node or dummy node hop. If paths shorter than NumHops is found, then they will be padded using dummy hops.
The maximum number of blinded paths to select and add to an invoice.
A list of node IDs of nodes that should not be used in any of our generated blinded paths.
Used in:
,The blinded path to send the payment to.
The base fee for the blinded path provided, expressed in msat.
The proportional fee for the blinded path provided, expressed in parts per million.
The total CLTV delta for the blinded path provided, including the final CLTV delta for the receiving node.
The minimum hltc size that may be sent over the blinded path, expressed in msat.
The maximum htlc size that may be sent over the blinded path, expressed in msat.
The feature bits for the route.
Used in:
Deprecated. The chain is now always assumed to be bitcoin. The blockchain the node is on (must be bitcoin)
The network the node is on (eg regtest, testnet, mainnet)
Used as request type in: Lightning.VerifyChanBackup
Used as response type in: Lightning.ExportAllChannelBackups, Lightning.SubscribeChannelBackups
Used as field type in:
,The set of new channels that have been added since the last channel backup snapshot was requested.
A multi-channel backup that covers all open channels currently known to lnd.
Used in:
The size of the pre-crafted output to be used as the channel point for this channel funding.
The target channel point to refrence in created commitment transactions.
Our local key to use when creating the multi-sig output.
The key of the remote party to use when creating the multi-sig output.
If non-zero, then this will be used as the pending channel ID on the wire protocol to initate the funding request. This is an optional field, and should only be set if the responder is already expecting a specific pending channel ID.
This uint32 indicates if this channel is to be considered 'frozen'. A frozen channel does not allow a cooperative channel close by the initiator. The thaw_height is the height that this restriction stops applying to the channel. The height can be interpreted in two ways: as a relative height if the value is less than 500,000, or as an absolute height otherwise.
Indicates that the funding output is using a MuSig2 multi-sig output.
Used in:
,Whether this channel is active or not
The identity pubkey of the remote node
The outpoint (txid:index) of the funding transaction. With this value, Bob will be able to generate a signature for Alice's version of the commitment transaction.
The unique channel ID for the channel. The first 3 bytes are the block height, the next 3 the index within the block, and the last 2 bytes are the output index for the channel.
The total amount of funds held in this channel
This node's current balance in this channel
The counterparty's current balance in this channel
The amount calculated to be paid in fees for the current set of commitment transactions. The fee amount is persisted with the channel in order to allow the fee amount to be removed and recalculated with each channel state update, including updates that happen after a system restart.
The weight of the commitment transaction
The required number of satoshis per kilo-weight that the requester will pay at all times, for both the funding transaction and commitment transaction. This value can later be updated once the channel is open.
The unsettled balance in this channel
The total number of satoshis we've sent within this channel.
The total number of satoshis we've received within this channel.
The total number of updates conducted within this channel.
The list of active, uncleared HTLCs currently pending within the channel.
Deprecated. The CSV delay expressed in relative blocks. If the channel is force closed, we will need to wait for this many blocks before we can regain our funds.
Whether this channel is advertised to the network or not.
True if we were the ones that created the channel.
A set of flags showing the current state of the channel.
Deprecated. The minimum satoshis this node is required to reserve in its balance.
Deprecated. The minimum satoshis the other node is required to reserve in its balance.
Deprecated. Use commitment_type.
The commitment type used by this channel.
The number of seconds that the channel has been monitored by the channel scoring system. Scores are currently not persisted, so this value may be less than the lifetime of the channel [EXPERIMENTAL].
The number of seconds that the remote peer has been observed as being online by the channel scoring system over the lifetime of the channel [EXPERIMENTAL].
Close address is the address that we will enforce payout to on cooperative close if the channel was opened utilizing option upfront shutdown. This value can be set on channel open by setting close_address in an open channel request. If this value is not set, you can still choose a payout address by cooperatively closing with the delivery_address field set.
The amount that the initiator of the channel optionally pushed to the remote party on channel open. This amount will be zero if the channel initiator did not push any funds to the remote peer. If the initiator field is true, we pushed this amount to our peer, if it is false, the remote peer pushed this amount to us.
This uint32 indicates if this channel is to be considered 'frozen'. A frozen channel doest not allow a cooperative channel close by the initiator. The thaw_height is the height that this restriction stops applying to the channel. This field is optional, not setting it or using a value of zero will mean the channel has no additional restrictions. The height can be interpreted in two ways: as a relative height if the value is less than 500,000, or as an absolute height otherwise.
List constraints for the local node.
List constraints for the remote node.
This lists out the set of alias short channel ids that exist for a channel. This may be empty.
Whether or not this is a zero-conf channel.
This is the confirmed / on-chain zero-conf SCID.
The configured alias name of our peer.
This is the peer SCID alias.
An optional note-to-self to go along with the channel containing some useful information. This is only ever stored locally and in no way impacts the channel's operation.
Custom channel data that might be populated in custom channels.
Used as response type in: Lightning.ExportChannelBackup
Used as field type in:
Identifies the channel that this backup belongs to.
Is an encrypted single-chan backup. this can be passed to RestoreChannelBackups, or the WalletUnlocker Init and Unlock methods in order to trigger the recovery protocol. When using REST, this field must be encoded as base64.
Used in:
,A set of single-chan static channel backups.
Used in:
,The outpoint (txid:index) of the funding transaction.
The unique channel ID for the channel.
The hash of the genesis block that this channel resides within.
The txid of the transaction which ultimately closed this channel.
Public key of the remote peer that we formerly had a channel with.
Total capacity of the channel.
Height at which the funding transaction was spent.
Settled balance at the time of channel closure
The sum of all the time-locked outputs at the time of channel closure
Details on how the channel was closed.
Open initiator is the party that initiated opening the channel. Note that this value may be unknown if the channel was closed before we migrated to store open channel information after close.
Close initiator indicates which party initiated the close. This value will be unknown for channels that were cooperatively closed before we started tracking cooperative close initiators. Note that this indicates which party initiated a close, and it is possible for both to initiate cooperative or force closes, although only one party's close will be confirmed on chain.
This lists out the set of alias short channel ids that existed for the closed channel. This may be empty.
The confirmed SCID for a zero-conf channel.
Used in:
Used in:
The local channel close output. If the local channel balance was dust to begin with, this output will not be set.
The remote channel close output. If the remote channel balance was dust to begin with, this output will not be set.
Any additional outputs that might be added for custom channel types.
Used in:
The CSV delay expressed in relative blocks. If the channel is force closed, we will need to wait for this many blocks before we can regain our funds.
The minimum satoshis this node is required to reserve in its balance.
The dust limit (in satoshis) of the initiator's commitment tx.
The maximum amount of coins in millisatoshis that can be pending in this channel.
The smallest HTLC in millisatoshis that the initiator will accept.
The total number of incoming HTLC's that the initiator will accept.
A fully authenticated channel along with all its unique attributes. Once an authenticated channel announcement has been processed on the network, then an instance of ChannelEdgeInfo encapsulating the channels attributes is stored. The other portions relevant to routing policy of a channel are stored within a ChannelEdgePolicy for each direction of the channel.
Used as response type in: Lightning.GetChanInfo
Used as field type in:
,The unique channel ID for the channel. The first 3 bytes are the block height, the next 3 the index within the block, and the last 2 bytes are the output index for the channel.
Custom channel announcement tlv records.
Used in:
The unique channel ID for the channel. The first 3 bytes are the block height, the next 3 the index within the block, and the last 2 bytes are the output index for the channel.
Used in:
Used in:
The short channel id that this fee report belongs to.
The channel that this fee report belongs to.
The base fee charged regardless of the number of milli-satoshis sent.
The amount charged per milli-satoshis transferred expressed in millionths of a satoshi.
The effective fee rate in milli-satoshis. Computed by dividing the fee_per_mil value by 1 million.
The base fee charged regardless of the number of milli-satoshis sent.
The amount charged per milli-satoshis transferred expressed in millionths of a satoshi.
Used in:
Used as response type in: Lightning.OpenChannelSync
Used as field type in:
, , , , , , , , , , , ,Txid of the funding transaction. When using REST, this field must be encoded as base64.
Hex-encoded string representing the byte-reversed hash of the funding transaction.
The index of the output of the funding transaction
Used in:
The signature that validates the announced data and proves the ownership of node id.
The target chain that this channel was opened within. This value should be the genesis hash of the target chain. Along with the short channel ID, this uniquely identifies the channel globally in a blockchain.
The unique description of the funding transaction.
A timestamp that allows ordering in the case of multiple announcements. We should ignore the message if timestamp is not greater than the last-received.
The bitfield that describes whether optional fields are present in this update. Currently, the least-significant bit must be set to 1 if the optional field MaxHtlc is present.
The bitfield that describes additional meta-data concerning how the update is to be interpreted. Currently, the least-significant bit must be set to 0 if the creating node corresponds to the first node in the previously sent channel announcement and 1 otherwise. If the second bit is set, then the channel is set to be disabled.
The minimum number of blocks this node requires to be added to the expiry of HTLCs. This is a security parameter determined by the node operator. This value represents the required gap between the time locks of the incoming and outgoing HTLC's set to this node.
The minimum HTLC value which will be accepted.
The base fee that must be used for incoming HTLC's to this particular channel. This value will be tacked onto the required for a payment independent of the size of the payment.
The fee rate that will be charged per millionth of a satoshi.
The maximum HTLC value which will be accepted.
The set of data that was appended to this message, some of which we may not actually know how to iterate or parse. By holding onto this data, we ensure that we're able to properly validate the set of signatures that cover these new fields, and ensure we're able to make upgrades to the network in a forwards compatible manner.
Used in:
The amount in satoshi of this close output. This amount is the final commitment balance of the channel and the actual amount paid out on chain might be smaller due to subtracted fees.
The pkScript of the close output.
Whether this output is for the local or remote node.
The TLV encoded custom channel data records for this output, which might be set for custom channels.
Used in:
The unique channel ID for the channel. The first 3 bytes are the block height, the next 3 the index within the block, and the last 2 bytes are the output index for the channel.
Used in:
, , , , ,Use the coin selection strategy defined in the global configuration (lnd.conf).
Select the largest available coins first during coin selection.
Randomly select the available coins during coin selection.
Used in:
, , , ,Returned when the commitment type isn't known or unavailable.
A channel using the legacy commitment format having tweaked to_remote keys.
A channel that uses the modern commitment format where the key in the output of the remote party does not change each state. This makes back up and recovery easier as when the channel is closed, the funds go directly to that key.
A channel that uses a commitment format that has anchor outputs on the commitments, allowing fee bumping after a force close transaction has been broadcast.
A channel that uses a commitment type that builds upon the anchors commitment format, but in addition requires a CLTV clause to spend outputs paying to the channel initiator. This is intended for use on leased channels to guarantee that the channel initiator has no incentives to close a leased channel before its maturity date.
A channel that uses musig2 for the funding output, and the new tapscript features where relevant.
Identical to the SIMPLE_TAPROOT channel type, but with extra functionality. This channel type also commits to additional meta data in the tapscript leaves for the scripts in a channel.
Used in:
The short channel id of this edge.
The direction of this edge. If direction_reverse is false, the direction of this edge is from the channel endpoint with the lexicographically smaller pub key to the endpoint with the larger pub key. If direction_reverse is is true, the edge goes the other way.
Used in:
The outpoint in format txid:n
Reason for the policy update failure.
A string representation of the policy update error.
Used in:
,Failure code as defined in the Lightning spec
An optional channel update message.
A failure type-dependent htlc value.
The sha256 sum of the onion payload.
A failure type-dependent cltv expiry value.
A failure type-dependent flags value.
The position in the path of the intermediate or final node that generated the failure message. Position zero is the sender node.
A failure type-dependent block height.
Used in:
, ,The numbers assigned in this enumeration match the failure codes as defined in BOLT #4. Because protobuf 3 requires enums to start with 0, a RESERVED value is added.
An internal error occurred.
The error source is known, but the failure itself couldn't be decoded.
An unreadable failure result is returned if the received failure message cannot be decrypted. In that case the error source is unknown.
Used in:
, , , , ,Used in:
, , , ,Used in:
,The fee limit expressed as a fixed amount of satoshis. The fields fixed and fixed_msat are mutually exclusive.
The fee limit expressed as a fixed amount of millisatoshis. The fields fixed and fixed_msat are mutually exclusive.
The fee limit expressed as a percentage of the payment amount.
Used in:
Arbitrary float value.
The value normalized to [0,1] or [-1,1].
Used in:
Timestamp is the time (unix epoch offset) that this circuit was completed. Deprecated by timestamp_ns.
The incoming channel ID that carried the HTLC that created the circuit.
The outgoing channel ID that carried the preimage that completed the circuit.
The total amount (in satoshis) of the incoming HTLC that created half the circuit.
The total amount (in satoshis) of the outgoing HTLC that created the second half of the circuit.
The total fee (in satoshis) that this payment circuit carried.
The total fee (in milli-satoshis) that this payment circuit carried.
The total amount (in milli-satoshis) of the incoming HTLC that created half the circuit.
The total amount (in milli-satoshis) of the outgoing HTLC that created the second half of the circuit.
The number of nanoseconds elapsed since January 1, 1970 UTC when this circuit was completed.
The peer alias of the incoming channel.
The peer alias of the outgoing channel.
Used in:
The funded PSBT that contains all witness data to send the exact channel capacity amount to the PK script returned in the open channel message in a previous step. Cannot be set at the same time as final_raw_tx.
The pending channel ID of the channel to get the PSBT for.
As an alternative to the signed PSBT with all witness data, the final raw wire format transaction can also be specified directly. Cannot be set at the same time as signed_psbt.
Used in:
The funded but not yet signed PSBT that sends the exact channel capacity amount to the PK script returned in the open channel message in a previous step.
The pending channel ID of the channel to get the PSBT for.
Can only be used if the no_publish flag was set to true in the OpenChannel call meaning that the caller is solely responsible for publishing the final funding transaction. If skip_finalize is set to true then lnd will not wait for a FundingPsbtFinalize state step and instead assumes that a transaction with the same TXID as the passed in PSBT will eventually confirm. IT IS ABSOLUTELY IMPERATIVE that the TXID of the transaction that is eventually published does have the _same TXID_ as the verified PSBT. That means no inputs or outputs can change, only signatures can be added. If the TXID changes between this call and the publish step then the channel will never be created and the funds will be in limbo.
Used in:
,A channel shim where the channel point was fully constructed outside of lnd's wallet and the transaction might already be published.
A channel shim that uses a PSBT to fund and sign the channel funding transaction.
Used in:
The pending channel ID of the channel to cancel the funding shim for.
Used as request type in: Lightning.GetTransactions, Lightning.SubscribeTransactions
The height from which to list transactions, inclusive. If this value is greater than end_height, transactions will be read in reverse.
The height until which to list transactions, inclusive. To include unconfirmed transactions, this value should be set to -1, which will return transactions from start_height until the current chain tip and unconfirmed transactions. If no end_height is provided, the call will default to this option.
An optional filter to only include transactions relevant to an account.
The index of a transaction that will be used in a query to determine which transaction should be returned in the response.
The maximal number of transactions returned in the response to this query. This value should be set to 0 to return all transactions.
Used in:
Index identifying the htlc on the channel.
If this HTLC is involved in a forwarding operation, this field indicates the forwarding channel. For an outgoing htlc, it is the incoming channel. For an incoming htlc, it is the outgoing channel. When the htlc originates from this node or this node is the final destination, forwarding_channel will be zero. The forwarding channel will also be zero for htlcs that need to be forwarded but don't have a forwarding decision persisted yet.
Index identifying the htlc on the forwarding channel.
Used as response type in: routerrpc.Router.SendToRouteV2
Used as field type in:
,The unique ID that is used for this attempt.
The status of the HTLC.
The route taken by this HTLC.
The time in UNIX nanoseconds at which this HTLC was sent.
The time in UNIX nanoseconds at which this HTLC was settled or failed. This value will not be set if the HTLC is still IN_FLIGHT.
Detailed htlc failure info.
The preimage that was used to settle the HTLC.
Used in:
Used in:
The unique channel ID for the channel. The first 3 bytes are the block height, the next 3 the index within the block, and the last 2 bytes are the output index for the channel.
An optional public key of the hop. If the public key is given, the payment can be executed without relying on a copy of the channel graph.
If set to true, then this hop will be encoded using the new variable length TLV format. Note that if any custom tlv_records below are specified, then this field MUST be set to true for them to be encoded properly.
An optional TLV record that signals the use of an MPP payment. If present, the receiver will enforce that the same mpp_record is included in the final hop payload of all non-zero payments in the HTLC set. If empty, a regular single-shot payment is or was attempted.
An optional TLV record that signals the use of an AMP payment. If present, the receiver will treat all received payments including the same (payment_addr, set_id) pair as being part of one logical payment. The payment will be settled by XORing the root_share's together and deriving the child hashes and preimages according to BOLT XX. Must be used in conjunction with mpp_record.
An optional set of key-value TLV records. This is useful within the context of the SendToRoute call as it allows callers to specify arbitrary K-V pairs to drop off at each hop within the onion.
The payment metadata to send along with the payment to the payee.
Blinding point is an optional blinding point included for introduction nodes in blinded paths. This field is mandatory for hops that represents the introduction point in a blinded path.
Encrypted data is a receiver-produced blob of data that provides hops in a blinded route with forwarding data. As this data is encrypted by the recipient, we will not be able to parse it - it is essentially an arbitrary blob of data from our node's perspective. This field is mandatory for all hops in a blinded path, including the introduction node.
The total amount that is sent to the recipient (possibly across multiple HTLCs), as specified by the sender when making a payment to a blinded path. This value is only set in the final hop payload of a blinded payment. This value is analogous to the MPPRecord that is used for regular (non-blinded) MPP payments.
Used in:
The public key of the node at the start of the channel.
The unique identifier of the channel.
The base fee of the channel denominated in millisatoshis.
The fee rate of the channel for sending one satoshi across it denominated in millionths of a satoshi.
The time-lock delta of the channel.
Used in:
The inbound base fee charged regardless of the number of milli-satoshis received in the channel. By default, only negative values are accepted.
The effective inbound fee rate in micro-satoshis (parts per million). By default, only negative values are accepted.
Used in:
,Used in:
The number of pending HTLCs that are currently active on the channel. These HTLCs need to be resolved before the channel can be closed cooperatively.
Used in:
The error to return to the user. If this is non-empty, the incoming gRPC stream/request is aborted and the error is returned to the gRPC client. If this value is empty, it means the middleware accepts the stream/request/ response and the processing of it can continue.
A boolean indicating that the gRPC message should be replaced/overwritten. This boolean is needed because in protobuf an empty message is serialized as a 0-length or nil byte slice and we wouldn't be able to distinguish between an empty replacement message and the "don't replace anything" case.
If the replace_response field is set to true, this field must contain the binary serialized gRPC message in the protobuf format.
Used as request type in: Lightning.AddInvoice
Used as response type in: invoicesrpc.Invoices.LookupInvoiceV2, invoicesrpc.Invoices.SubscribeSingleInvoice, Lightning.LookupInvoice, Lightning.SubscribeInvoices
Used as field type in:
,An optional memo to attach along with the invoice. Used for record keeping purposes for the invoice's creator, and will also be set in the description field of the encoded payment request if the description_hash field is not being used.
The hex-encoded preimage (32 byte) which will allow settling an incoming HTLC payable to this preimage. When using REST, this field must be encoded as base64.
The hash of the preimage. When using REST, this field must be encoded as base64. Note: Output only, don't specify for creating an invoice.
The value of this invoice in satoshis The fields value and value_msat are mutually exclusive.
The value of this invoice in millisatoshis The fields value and value_msat are mutually exclusive.
Whether this invoice has been fulfilled. The field is deprecated. Use the state field instead (compare to SETTLED).
When this invoice was created. Measured in seconds since the unix epoch. Note: Output only, don't specify for creating an invoice.
When this invoice was settled. Measured in seconds since the unix epoch. Note: Output only, don't specify for creating an invoice.
A bare-bones invoice for a payment within the Lightning Network. With the details of the invoice, the sender has all the data necessary to send a payment to the recipient. Note: Output only, don't specify for creating an invoice.
Hash (SHA-256) of a description of the payment. Used if the description of payment (memo) is too long to naturally fit within the description field of an encoded payment request. When using REST, this field must be encoded as base64.
Payment request expiry time in seconds. Default is 86400 (24 hours).
Fallback on-chain address.
Delta to use for the time-lock of the CLTV extended to the final hop.
Route hints that can each be individually used to assist in reaching the invoice's destination.
Whether this invoice should include routing hints for private channels. Note: When enabled, if value and value_msat are zero, a large number of hints with these channels can be included, which might not be desirable.
The "add" index of this invoice. Each newly created invoice will increment this index making it monotonically increasing. Callers to the SubscribeInvoices call can use this to instantly get notified of all added invoices with an add_index greater than this one. Note: Output only, don't specify for creating an invoice.
The "settle" index of this invoice. Each newly settled invoice will increment this index making it monotonically increasing. Callers to the SubscribeInvoices call can use this to instantly get notified of all settled invoices with an settle_index greater than this one. Note: Output only, don't specify for creating an invoice.
Deprecated, use amt_paid_sat or amt_paid_msat.
The amount that was accepted for this invoice, in satoshis. This will ONLY be set if this invoice has been settled or accepted. We provide this field as if the invoice was created with a zero value, then we need to record what amount was ultimately accepted. Additionally, it's possible that the sender paid MORE that was specified in the original invoice. So we'll record that here as well. Note: Output only, don't specify for creating an invoice.
The amount that was accepted for this invoice, in millisatoshis. This will ONLY be set if this invoice has been settled or accepted. We provide this field as if the invoice was created with a zero value, then we need to record what amount was ultimately accepted. Additionally, it's possible that the sender paid MORE that was specified in the original invoice. So we'll record that here as well. Note: Output only, don't specify for creating an invoice.
The state the invoice is in. Note: Output only, don't specify for creating an invoice.
List of HTLCs paying to this invoice [EXPERIMENTAL]. Note: Output only, don't specify for creating an invoice.
List of features advertised on the invoice. Note: Output only, don't specify for creating an invoice.
Indicates if this invoice was a spontaneous payment that arrived via keysend [EXPERIMENTAL]. Note: Output only, don't specify for creating an invoice.
The payment address of this invoice. This is also called payment secret in specifications (e.g. BOLT 11). This value will be used in MPP payments, and also for newer invoices that always require the MPP payload for added end-to-end security. Note: Output only, don't specify for creating an invoice.
Signals whether or not this is an AMP invoice.
[EXPERIMENTAL]: Maps a 32-byte hex-encoded set ID to the sub-invoice AMP state for the given set ID. This field is always populated for AMP invoices, and can be used along side LookupInvoice to obtain the HTLC information related to a given sub-invoice. Note: Output only, don't specify for creating an invoice.
Signals that the invoice should include blinded paths to hide the true identity of the recipient.
Config values to use when creating blinded paths for this invoice. These can be used to override the defaults config values provided in by the global config. This field is only used if is_blinded is true.
Used in:
Details of an HTLC that paid to an invoice
Used in:
Short channel id over which the htlc was received.
Index identifying the htlc on the channel.
The amount of the htlc in msat.
Block height at which this htlc was accepted.
Time at which this htlc was accepted.
Time at which this htlc was settled or canceled.
Block height at which this htlc expires.
Current state the htlc is in.
Custom tlv records.
The total amount of the mpp payment in msat.
Details relevant to AMP HTLCs, only populated if this is an AMP HTLC.
Custom channel data that might be populated in custom channels.
Used in:
,Used in:
The raw bytes of the key being identified.
The key locator that identifies which key to use for signing.
Used in:
The family of key being identified.
The precise index of the key being identified.
Used in:
The identity pubkey of the Lightning node.
The network location of the lightning node, e.g. `69.69.69.69:1337` or `localhost:10011`.
An individual vertex/node within the channel graph. A node is connected to other nodes by one or more channel edges emanating from it. As the graph is directed, a node will also have an incoming edge attached to it for each outgoing edge.
Used in:
,Custom node announcement tlv records.
Used in:
A unique, random identifier used to authenticate the sender as the intended payer of a multi-path payment. The payment_addr must be the same for all subpayments, and match the payment_addr provided in the receiver's invoice. The same payment_addr must be used on all subpayments. This is also called payment secret in specifications (e.g. BOLT 11).
The total amount in milli-satoshis being sent as part of a larger multi-path payment. The caller is responsible for ensuring subpayments to the same node and payment_hash sum exactly to total_amt_msat. The same total_amt_msat must be used on all subpayments.
Used in:
, ,The entity a permission grants access to.
The action that is granted.
Used in:
A list of macaroon permissions.
Used in:
The name of the middleware to register. The name should be as informative as possible and is logged on registration.
The name of the custom macaroon caveat that this middleware is responsible for. Only requests/responses that contain a macaroon with the registered custom caveat are forwarded for interception to the middleware. The exception being the read-only mode: All requests/responses are forwarded to a middleware that requests read-only access but such a middleware won't be allowed to _alter_ responses. As a security measure, _no_ middleware can change responses to requests made with _unencumbered_ macaroons! NOTE: Cannot be used at the same time as read_only_mode.
Instead of defining a custom macaroon caveat name a middleware can register itself for read-only access only. In that mode all requests/responses are forwarded to the middleware but the middleware isn't allowed to alter any of the responses. NOTE: Cannot be used at the same time as custom_macaroon_caveat_name.
Used in:
Is the set of all channels that are included in this multi-channel backup.
A single encrypted blob containing all the static channel backups of the channel listed above. This can be stored as a single file or blob, and safely be replaced with any prior/future versions. When using REST, this field must be encoded as base64.
Used in:
,Used in:
Used in:
The sending node of the pair. When using REST, this field must be encoded as base64.
The receiving node of the pair. When using REST, this field must be encoded as base64.
Used in:
Deprecated, use node_addresses.
Deprecated, use features.
Features that the node has advertised in the init message, node announcements and invoices.
Used in:
,Used as request type in: Lightning.OpenChannel, Lightning.OpenChannelSync
A manual fee rate set in sat/vbyte that should be used when crafting the funding transaction.
The pubkey of the node to open a channel with. When using REST, this field must be encoded as base64.
The hex encoded pubkey of the node to open a channel with. Deprecated now that the REST gateway supports base64 encoding of bytes fields.
The number of satoshis the wallet should commit to the channel
The number of satoshis to push to the remote side as part of the initial commitment state
The target number of blocks that the funding transaction should be confirmed by.
Deprecated, use sat_per_vbyte. A manual fee rate set in sat/vbyte that should be used when crafting the funding transaction.
Whether this channel should be private, not announced to the greater network.
The minimum value in millisatoshi we will require for incoming HTLCs on the channel.
The delay we require on the remote's commitment transaction. If this is not set, it will be scaled automatically with the channel size.
The minimum number of confirmations each one of your outputs used for the funding transaction must satisfy.
Whether unconfirmed outputs should be used as inputs for the funding transaction.
Close address is an optional address which specifies the address to which funds should be paid out to upon cooperative close. This field may only be set if the peer supports the option upfront feature bit (call listpeers to check). The remote peer will only accept cooperative closes to this address if it is set. Note: If this value is set on channel creation, you will *not* be able to cooperatively close out to a different address.
Funding shims are an optional argument that allow the caller to intercept certain funding functionality. For example, a shim can be provided to use a particular key for the commitment key (ideally cold) rather than use one that is generated by the wallet as normal, or signal that signing will be carried out in an interactive manner (PSBT based).
The maximum amount of coins in millisatoshi that can be pending within the channel. It only applies to the remote party.
The maximum number of concurrent HTLCs we will allow the remote party to add to the commitment transaction.
Max local csv is the maximum csv delay we will allow for our own commitment transaction.
The explicit commitment type to use. Note this field will only be used if the remote peer supports explicit channel negotiation.
If this is true, then a zero-conf channel open will be attempted.
If this is true, then an option-scid-alias channel-type open will be attempted.
The base fee charged regardless of the number of milli-satoshis sent.
The fee rate in ppm (parts per million) that will be charged in proportion of the value of each forwarded HTLC.
If use_base_fee is true the open channel announcement will update the channel base fee with the value specified in base_fee. In the case of a base_fee of 0 use_base_fee is needed downstream to distinguish whether to use the default base fee value specified in the config or 0.
If use_fee_rate is true the open channel announcement will update the channel fee rate with the value specified in fee_rate. In the case of a fee_rate of 0 use_fee_rate is needed downstream to distinguish whether to use the default fee rate value specified in the config or 0.
The number of satoshis we require the remote peer to reserve. This value, if specified, must be above the dust limit and below 20% of the channel capacity.
If set, then lnd will attempt to commit all the coins under control of the internal wallet to open the channel, and the LocalFundingAmount field must be zero and is ignored.
An optional note-to-self to go along with the channel containing some useful information. This is only ever stored locally and in no way impacts the channel's operation.
A list of selected outpoints that are allocated for channel funding.
Used in:
, , , , , , , , , ,Raw bytes representing the transaction id.
Reversed, hex-encoded string representing the transaction id.
The index of the output on the transaction.
Used in:
The type of the output
The address
The pkscript in hex
The output index used in the raw transaction
The value of the output coin in satoshis
Denotes if the output is controlled by the internal wallet
Used in:
Used as response type in: routerrpc.Router.SendPaymentV2, routerrpc.Router.TrackPaymentV2, routerrpc.Router.TrackPayments
Used as field type in:
The payment hash
Deprecated, use value_sat or value_msat.
Deprecated, use creation_time_ns
Deprecated, use fee_sat or fee_msat.
The payment preimage
The value of the payment in satoshis
The value of the payment in milli-satoshis
The optional payment request being fulfilled.
The status of the payment.
The fee paid for this payment in satoshis
The fee paid for this payment in milli-satoshis
The time in UNIX nanoseconds at which the payment was created.
The HTLCs made in attempt to settle the payment.
The creation index of this payment. Each payment can be uniquely identified by this index, which may not strictly increment by 1 for payments made in older versions of lnd.
The custom TLV records that were sent to the first hop as part of the HTLC wire message for this payment.
Used in:
Deprecated. This status will never be returned.
Payment has inflight HTLCs.
Payment is settled.
Payment is failed.
Payment is created and has not attempted any HTLCs.
Used in:
,Payment isn't failed (yet).
There are more routes to try, but the payment timeout was exceeded.
All possible routes were tried and failed permanently. Or were no routes to the destination at all.
A non-recoverable error has occured.
Payment details incorrect (unknown hash, invalid amt or invalid final cltv delta)
Insufficient local balance.
The payment was canceled.
Used in:
The identity pubkey of the peer
Network address of the peer; eg `127.0.0.1:10011`
Bytes of data transmitted to this peer
Bytes of data transmitted from this peer
Satoshis sent to this peer
Satoshis received from this peer
A channel is inbound if the counterparty initiated the channel
Ping time to this peer
The type of sync we are currently performing with this peer.
Features advertised by the remote peer in their init message.
The latest errors received from our peer with timestamps, limited to the 10 most recent errors. These errors are tracked across peer connections, but are not persisted across lnd restarts. Note that these errors are only stored for peers that we have channels open with, to prevent peers from spamming us with errors at no cost.
The number of times we have recorded this peer going offline or coming online, recorded across restarts. Note that this value is decreased over time if the peer has not recently flapped, so that we can forgive peers with historically high flap counts.
The timestamp of the last flap we observed for this peer. If this value is zero, we have not observed any flaps for this peer.
The last ping payload the peer has sent to us.
Used in:
Denotes that we cannot determine the peer's current sync type.
Denotes that we are actively receiving new graph updates from the peer.
Denotes that we are not receiving new graph updates from the peer.
Denotes that this peer is pinned into an active sync.
Used in:
Used in:
The pending channel to be closed
The transaction id of the closing transaction
Used in:
Hash of the local version of the commitment tx.
Hash of the remote version of the commitment tx.
Hash of the remote pending version of the commitment tx.
The amount in satoshis calculated to be paid in fees for the local commitment.
The amount in satoshis calculated to be paid in fees for the remote commitment.
The amount in satoshis calculated to be paid in fees for the remote pending commitment.
Used in:
The pending channel to be force closed
The transaction id of the closing transaction
The balance in satoshis encumbered in this pending channel
The height at which funds can be swept into the wallet
Remaining # of blocks until the commitment output can be swept. Negative values indicate how many blocks have passed since becoming mature.
The total value of funds successfully recovered from this channel
There are three resolution states for the anchor: limbo, lost and recovered. Derive the current state from the limbo and recovered balances.
Used in:
The recovered_balance is zero and limbo_balance is non-zero.
The recovered_balance is non-zero.
A state that is neither LIMBO nor RECOVERED.
Used in:
, , ,The minimum satoshis this node is required to reserve in its balance.
The minimum satoshis the other node is required to reserve in its balance.
The party that initiated opening the channel.
The commitment type used by this channel.
Total number of forwarding packages created in this channel.
A set of flags showing the current state of the channel.
Whether this channel is advertised to the network or not.
An optional note-to-self to go along with the channel containing some useful information. This is only ever stored locally and in no way impacts the channel's operation.
Custom channel data that might be populated in custom channels.
Used in:
The pending channel
The amount calculated to be paid in fees for the current set of commitment transactions. The fee amount is persisted with the channel in order to allow the fee amount to be removed and recalculated with each channel state update, including updates that happen after a system restart.
The weight of the commitment transaction
The required number of satoshis per kilo-weight that the requester will pay at all times, for both the funding transaction and commitment transaction. This value can later be updated once the channel is open.
The number of blocks until the funding transaction is considered expired. If this value gets close to zero, there is a risk that the channel funding will be canceled by the channel responder. The channel should be fee bumped using CPFP (see walletrpc.BumpFee) to ensure that the channel confirms in time. Otherwise a force-close will be necessary if the channel confirms after the funding transaction expires. A negative value means the channel responder has very likely canceled the funding and the channel will never become fully operational.
Used in:
The pending channel waiting for closing tx to confirm
The balance in satoshis encumbered in this channel
A list of valid commitment transactions. Any of these can confirm at this point.
The transaction id of the closing transaction
The raw hex encoded bytes of the closing transaction. Included if include_raw_tx in the request is true.
Used in:
The direction within the channel that the htlc was sent
The total value of the htlc
The final output to be swept back to the user's wallet
The next block height at which we can spend the current stage
The number of blocks remaining until the current stage can be swept. Negative values indicate how many blocks have passed since becoming mature.
Indicates whether the htlc is in its first or second stage of recovery
Used in:
, , ,Used in:
The outpoint in format txid:n.
Denotes if the outpoint is controlled by the internal wallet. The flag will only detect p2wkh, np2wkh and p2tr inputs as its own.
Used in:
A unique identifier of 32 random bytes that will be used as the pending channel ID to identify the PSBT state machine when interacting with it and on the wire protocol to initiate the funding request.
An optional base PSBT the new channel output will be added to. If this is non-empty, it must be a binary serialized PSBT.
If a channel should be part of a batch (multiple channel openings in one transaction), it can be dangerous if the whole batch transaction is published too early before all channel opening negotiations are completed. This flag prevents this particular channel from broadcasting the transaction after the negotiation with the remote peer. In a batch of channel openings this flag should be set to true for every channel but the very last.
Used in:
The full URI (in the format /<rpcpackage>.<ServiceName>/MethodName, for example /lnrpc.Lightning/GetInfo) of the RPC method the message was sent to/from.
Indicates whether the message was sent over a streaming RPC method or not.
The full canonical gRPC name of the message type (in the format <rpcpackage>.TypeName, for example lnrpc.GetInfoRequest). In case of an error being returned from lnd, this simply contains the string "error".
The full content of the gRPC message, serialized in the binary protobuf format.
Indicates that the response from lnd was an error, not a gRPC response. If this is set to true then the type_name contains the string "error" and serialized contains the error string.
Used in:
The P2WSH address of the channel funding multisig address that the below specified amount in satoshis needs to be sent to.
The exact amount in satoshis that needs to be sent to the above address to fund the pending channel.
A raw PSBT that contains the pending channel output. If a base PSBT was provided in the PsbtShim, this is the base PSBT with one additional output. If no base PSBT was specified, this is an otherwise empty PSBT with exactly one output.
Used in:
The type of output we are resolving.
The outcome of our on chain action that resolved the outpoint.
The outpoint that was spent by the resolution.
The amount that was claimed by the resolution.
The hex-encoded transaction ID of the sweep transaction that spent the output.
Used in:
Outcome unknown.
An output was claimed on chain.
An output was left unclaimed on chain.
ResolverOutcomeAbandoned indicates that an output that we did not claim on chain, for example an anchor that we did not sweep and a third party claimed on chain, or a htlc that we could not decode so left unclaimed.
If we force closed our channel, our htlcs need to be claimed in two stages. This outcome represents the broadcast of a timeout or success transaction for this two stage htlc claim.
A htlc was timed out on chain.
Used in:
We resolved an anchor output.
We are resolving an incoming htlc on chain. This if this htlc is claimed, we swept the incoming htlc with the preimage. If it is timed out, our peer swept the timeout path.
We are resolving an outgoing htlc on chain. If this htlc is claimed, the remote party swept the htlc with the preimage. If it is timed out, we swept it with the timeout path.
We force closed and need to sweep our time locked commitment output.
A path through the channel graph which runs over one or more channels in succession. This struct carries all the information required to craft the Sphinx onion packet, and send the payment along the first hop in the path. A route is only selected as valid if all the channels have sufficient capacity to carry the initial payment amount after fees are accounted for.
Used in:
, , , , ,The cumulative (final) time lock across the entire route. This is the CLTV value that should be extended to the first hop in the route. All other hops will decrement the time-lock as advertised, leaving enough time for all hops to wait for or present the payment preimage to complete the payment.
The sum of the fees paid at each hop within the final route. In the case of a one-hop payment, this value will be zero as we don't need to pay a fee to ourselves.
The total amount of funds required to complete a payment over this route. This value includes the cumulative fees at each hop. As a result, the HTLC extended to the first-hop in the route will need to have at least this many satoshis, otherwise the route will fail at an intermediate node due to an insufficient amount of fees.
Contains details concerning the specific forwarding details at each hop.
The total fees in millisatoshis.
The total amount in millisatoshis.
The actual on-chain amount that was sent out to the first hop. This value is only different from the total_amt_msat field if this is a custom channel payment and the value transported in the HTLC is different from the BTC amount in the HTLC. If this value is zero, then this is an old payment that didn't have this value yet and can be ignored.
Custom channel data that might be populated in custom channels.
Used in:
, , , ,A list of hop hints that when chained together can assist in reaching a specific destination.
Used in:
,Custom channel update tlv records.
Used as request type in: Lightning.SendPayment, Lightning.SendPaymentSync
The identity pubkey of the payment recipient. When using REST, this field must be encoded as base64.
The hex-encoded identity pubkey of the payment recipient. Deprecated now that the REST gateway supports base64 encoding of bytes fields.
The amount to send expressed in satoshis. The fields amt and amt_msat are mutually exclusive.
The amount to send expressed in millisatoshis. The fields amt and amt_msat are mutually exclusive.
The hash to use within the payment's HTLC. When using REST, this field must be encoded as base64.
The hex-encoded hash to use within the payment's HTLC. Deprecated now that the REST gateway supports base64 encoding of bytes fields.
A bare-bones invoice for a payment within the Lightning Network. With the details of the invoice, the sender has all the data necessary to send a payment to the recipient.
The CLTV delta from the current height that should be used to set the timelock for the final hop.
The maximum number of satoshis that will be paid as a fee of the payment. This value can be represented either as a percentage of the amount being sent, or as a fixed amount of the maximum fee the user is willing the pay to send the payment. If not specified, lnd will use a default value of 100% fees for small amounts (<=1k sat) or 5% fees for larger amounts.
The channel id of the channel that must be taken to the first hop. If zero, any channel may be used.
The pubkey of the last hop of the route. If empty, any hop may be used.
An optional maximum total time lock for the route. This should not exceed lnd's `--max-cltv-expiry` setting. If zero, then the value of `--max-cltv-expiry` is enforced.
An optional field that can be used to pass an arbitrary set of TLV records to a peer which understands the new records. This can be used to pass application specific data during the payment attempt. Record types are required to be in the custom range >= 65536. When using REST, the values must be encoded as base64.
If set, circular payments to self are permitted.
Features assumed to be supported by the final node. All transitive feature dependencies must also be set properly. For a given feature bit pair, either optional or remote may be set, but not both. If this field is nil or empty, the router will try to load destination features from the graph as a fallback.
The payment address of the generated invoice. This is also called payment secret in specifications (e.g. BOLT 11).
Used as response type in: Lightning.SendPayment, Lightning.SendPaymentSync, Lightning.SendToRoute, Lightning.SendToRouteSync
Used as request type in: Lightning.SendToRoute, Lightning.SendToRouteSync
The payment hash to use for the HTLC. When using REST, this field must be encoded as base64.
An optional hex-encoded payment hash to be used for the HTLC. Deprecated now that the REST gateway supports base64 encoding of bytes fields.
Route that should be used to attempt to complete the payment.
Used in:
The full URI (in the format /<rpcpackage>.<ServiceName>/MethodName, for example /lnrpc.Lightning/GetInfo) of the streaming RPC method that was just established.
Used in:
The unix timestamp in seconds when the error occurred.
The string representation of the error sent by our peer.
Used as response type in: Lightning.SubscribeTransactions, walletrpc.WalletKit.GetTransaction
Used as field type in:
The transaction hash
The transaction amount, denominated in satoshis
The number of confirmations
The hash of the block this transaction was included in
The height of the block this transaction was included in
Timestamp of this transaction
Fees paid for this transaction
Addresses that received funds for this transaction. Deprecated as it is now incorporated in the output_details field.
Outputs that received funds for this transaction
The raw transaction hex.
A label that was optionally set on transaction broadcast.
PreviousOutpoints/Inputs of this transaction.
Used as response type in: Lightning.GetTransactions
Used as field type in:
The list of transactions relevant to the wallet.
The index of the last item in the set of returned transactions. This can be used to seek further, pagination style.
The index of the last item in the set of returned transactions. This can be used to seek backwards, pagination style.
Used in:
Used in:
,The type of address
The address
The value of the unspent coin in satoshis
The pkscript in hex
The outpoint in format txid:n
The number of confirmations for the Utxo
Used in:
The confirmed balance of the account (with >= 1 confirmations).
The unconfirmed balance of the account (with 0 confirmations).
Used in:
,NON_EXISTING means that the wallet has not yet been initialized.
LOCKED means that the wallet is locked and requires a password to unlock.
UNLOCKED means that the wallet was unlocked successfully, but RPC server isn't ready.
RPC_ACTIVE means that the lnd server is active but not fully ready for calls.
SERVER_ACTIVE means that the lnd server is ready to accept calls.
WAITING_TO_START means that node is waiting to become the leader in a cluster and is not started yet.
Used in:
The unix timestamp in seconds of when the master key was created. lnd will only start scanning for funds in blocks that are after the birthday which can speed up the process significantly. If the birthday is not known, this should be left at its default value of 0 in which case lnd will start scanning from the first SegWit block (481824 on mainnet).
The fingerprint of the root key (also known as the key with derivation path m/) from which the account public keys were derived from. This may be required by some hardware wallets for proper identification and signing. The bytes must be in big-endian order.
The list of accounts to import. There _must_ be an account for all of lnd's main key scopes: BIP49/BIP84 (m/49'/0'/0', m/84'/0'/0', note that the coin type is always 0, even for testnet/regtest) and lnd's internal key scope (m/1017'/<coin_type>'/<account>'), where account is the key family as defined in `keychain/derivation.go` (currently indices 0 to 9).
Used in:
Purpose is the first number in the derivation path, must be either 49, 84 or 1017.
Coin type is the second number in the derivation path, this is _always_ 0 for purposes 49 and 84. It only needs to be set to 1 for purpose 1017 on testnet or regtest.
Account is the third number in the derivation path. For purposes 49 and 84 at least the default account (index 0) needs to be created but optional additional accounts are allowed. For purpose 1017 there needs to be exactly one account for each of the key families defined in `keychain/derivation.go` (currently indices 0 to 9)
The extended public key at depth 3 for the given account.