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.
(message has no fields)
The balance of the wallet
The confirmed balance of a wallet(with >= 1 confirmations)
The unconfirmed balance of a wallet(with 0 confirmations)
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.
lncli: `listchaintxns` GetTransactions returns a list describing all the known transactions relevant to the wallet.
The list of 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 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, then the amount field will be ignored, and lnd will attempt to send all the coins under control of the internal wallet 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 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 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.
The signature for the given message
lncli: `verifymessage` VerifyMessage verifies a signature over a msg. 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, in the format `<pubkey>@host`
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.
(message has no fields)
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
(message has no fields)
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
The URIs of the current node.
Features that our node has advertised in our init message, node announcements and invoices.
* 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.
(message has no fields)
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.
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.
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.
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.
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.
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.
(message has no fields)
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.
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.
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 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.
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, the 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).
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.
DeleteAllPayments deletes all outgoing payments from DB.
Only delete failed payments.
Only delete failed HTLCs from payments, not the payment itself.
(message has no fields)
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.
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.
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.
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 recrods, and 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.
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 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)
(message has no fields)
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 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.
(message has no fields)
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. If no time-range is specified, then the first chunk of the past 24 hrs of forwarding history are returned. 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.
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)
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.
(message has no fields)
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.
(message has no fields)
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.
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.
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:
`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)
Used in:
,Used in:
Value denominated in satoshis.
Value denominated in milli-satoshis.
Used in:
The blockchain the node is on (eg bitcoin, litecoin)
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
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.
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.
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.
Used in:
Used in:
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.
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.
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 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:
,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.
Returned when the commitment type isn't known or unavailable.
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:
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.
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.
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.
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 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.
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:
,Used as request type in: Lightning.AddInvoice
Used as response type in: 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.
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
When this invoice was created
When this invoice was settled
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.
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 3600 (1 hour).
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.
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 "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.
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. 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.
The amount that was accepted for this invoice, in millisatoshis. This will ONLY be set if this invoice has been settled. 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.
The state the invoice is in.
List of HTLCs paying to this invoice [EXPERIMENTAL].
List of features advertised on the invoice.
Indicates if this invoice was a spontaneous payment that arrived via keysend [EXPERIMENTAL].
The payment address of this invoice. This value will be used in MPP payments, and also for newer invoies that always require the MPP paylaod for added end-to-end security.
Signals whether or not this is an AMP invoice.
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.
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:
,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.
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:
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.
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 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.
Used in:
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.
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.
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
Used in:
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.
Used in:
The pending channel
The height at which this channel will be confirmed
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.
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.
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:
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 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.
Used in:
, ,A list of hop hints that when chained together can assist in reaching a specific destination.
Used in:
,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.
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.
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 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
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
The raw transaction hex.
A label that was optionally set on transaction broadcast.
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).