2015-12-30 23:19:09 +03:00
|
|
|
syntax = "proto3";
|
|
|
|
|
|
|
|
package lnrpc;
|
2018-12-11 13:42:43 +03:00
|
|
|
|
|
|
|
option go_package = "github.com/lightningnetwork/lnd/lnrpc";
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2017-07-28 02:39:49 +03:00
|
|
|
* Comments in this file will be directly parsed into the API
|
|
|
|
* Documentation as descriptions of the associated method, message, or field.
|
|
|
|
* These descriptions should go right above the definition of the object, and
|
2020-05-06 17:51:14 +03:00
|
|
|
* can be in either block or // comment format.
|
2020-03-02 17:35:25 +03:00
|
|
|
*
|
2017-07-28 02:39:49 +03:00
|
|
|
* An RPC method can be matched to an lncli command by placing a line in the
|
|
|
|
* beginning of the description in exactly the following format:
|
|
|
|
* lncli: `methodname`
|
2020-03-02 17:35:25 +03:00
|
|
|
*
|
2017-07-28 02:39:49 +03:00
|
|
|
* Failure to specify the exact name of the command will cause documentation
|
|
|
|
* generation to fail.
|
2020-03-02 17:35:25 +03:00
|
|
|
*
|
2017-07-28 02:39:49 +03:00
|
|
|
* More information on how exactly the gRPC documentation is generated from
|
|
|
|
* this proto file can be found here:
|
2018-08-29 03:11:49 +03:00
|
|
|
* https://github.com/lightninglabs/lightning-api
|
2017-07-28 02:39:49 +03:00
|
|
|
*/
|
2015-12-30 23:19:09 +03:00
|
|
|
|
2020-04-02 13:07:05 +03:00
|
|
|
// Lightning is the main RPC server of the daemon.
|
2015-12-30 23:19:09 +03:00
|
|
|
service Lightning {
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `walletbalance`
|
2018-02-02 07:16:40 +03:00
|
|
|
WalletBalance returns total unspent outputs(confirmed and unconfirmed), all
|
|
|
|
confirmed unspent outputs and all unconfirmed unspent outputs under control
|
2019-01-24 16:51:05 +03:00
|
|
|
of the wallet.
|
2017-07-28 02:39:49 +03:00
|
|
|
*/
|
2020-05-28 14:07:31 +03:00
|
|
|
rpc WalletBalance (WalletBalanceRequest) returns (WalletBalanceResponse);
|
2017-07-28 02:39:49 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `channelbalance`
|
2020-08-06 13:01:31 +03:00
|
|
|
ChannelBalance returns a report on the total funds across all open channels,
|
|
|
|
categorized in local/remote, pending local/remote and unsettled local/remote
|
|
|
|
balances.
|
2017-07-28 02:39:49 +03:00
|
|
|
*/
|
2020-05-28 14:07:31 +03:00
|
|
|
rpc ChannelBalance (ChannelBalanceRequest) returns (ChannelBalanceResponse);
|
2016-10-16 00:38:47 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `listchaintxns`
|
2017-07-28 02:39:49 +03:00
|
|
|
GetTransactions returns a list describing all the known transactions
|
|
|
|
relevant to the wallet.
|
|
|
|
*/
|
2020-05-28 14:07:31 +03:00
|
|
|
rpc GetTransactions (GetTransactionsRequest) returns (TransactionDetails);
|
2017-07-28 02:39:49 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `estimatefee`
|
2019-03-05 16:22:30 +03:00
|
|
|
EstimateFee asks the chain backend to estimate the fee rate and total fees
|
|
|
|
for a transaction that pays to multiple specified outputs.
|
2020-06-03 18:35:19 +03:00
|
|
|
|
|
|
|
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.
|
2019-03-05 16:22:30 +03:00
|
|
|
*/
|
2020-05-28 14:07:31 +03:00
|
|
|
rpc EstimateFee (EstimateFeeRequest) returns (EstimateFeeResponse);
|
2019-03-05 16:22:30 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `sendcoins`
|
2017-07-28 02:39:49 +03:00
|
|
|
SendCoins executes a request to send coins to a particular address. Unlike
|
2017-11-23 08:36:27 +03:00
|
|
|
SendMany, this RPC call only allows creating a single output at a time. If
|
2021-03-11 03:29:50 +03:00
|
|
|
neither target_conf, or sat_per_vbyte are set, then the internal wallet will
|
2017-11-23 08:36:27 +03:00
|
|
|
consult its fee model to determine a fee for the default confirmation
|
|
|
|
target.
|
2017-07-28 02:39:49 +03:00
|
|
|
*/
|
2020-05-28 14:07:31 +03:00
|
|
|
rpc SendCoins (SendCoinsRequest) returns (SendCoinsResponse);
|
2017-07-28 02:39:49 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `listunspent`
|
2020-05-21 02:14:20 +03:00
|
|
|
Deprecated, use walletrpc.ListUnspent instead.
|
|
|
|
|
2018-09-27 16:49:44 +03:00
|
|
|
ListUnspent returns a list of all utxos spendable by the wallet with a
|
2020-05-21 02:14:20 +03:00
|
|
|
number of confirmations between the specified minimum and maximum.
|
2018-09-27 16:49:44 +03:00
|
|
|
*/
|
2020-05-28 14:07:31 +03:00
|
|
|
rpc ListUnspent (ListUnspentRequest) returns (ListUnspentResponse);
|
2018-09-27 16:49:44 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2017-07-28 02:39:49 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-03-02 17:35:25 +03:00
|
|
|
rpc SubscribeTransactions (GetTransactionsRequest)
|
|
|
|
returns (stream Transaction);
|
2016-09-15 21:59:51 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `sendmany`
|
2017-07-28 02:39:49 +03:00
|
|
|
SendMany handles a request for a transaction that creates multiple specified
|
2021-03-11 03:29:50 +03:00
|
|
|
outputs in parallel. If neither target_conf, or sat_per_vbyte are set, then
|
2017-11-23 08:36:27 +03:00
|
|
|
the internal wallet will consult its fee model to determine a fee for the
|
|
|
|
default confirmation target.
|
2017-07-28 02:39:49 +03:00
|
|
|
*/
|
2017-04-12 00:49:39 +03:00
|
|
|
rpc SendMany (SendManyRequest) returns (SendManyResponse);
|
2015-12-31 06:02:24 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `newaddress`
|
2017-07-28 02:39:49 +03:00
|
|
|
NewAddress creates a new address under control of the local wallet.
|
|
|
|
*/
|
2020-05-28 14:07:31 +03:00
|
|
|
rpc NewAddress (NewAddressRequest) returns (NewAddressResponse);
|
2016-06-21 21:52:09 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `signmessage`
|
2017-07-28 02:39:49 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-05-28 14:07:31 +03:00
|
|
|
rpc SignMessage (SignMessageRequest) returns (SignMessageResponse);
|
2017-07-28 02:39:49 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `verifymessage`
|
2017-07-28 02:39:49 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-05-28 14:07:31 +03:00
|
|
|
rpc VerifyMessage (VerifyMessageRequest) returns (VerifyMessageResponse);
|
2017-04-20 05:28:10 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `connect`
|
2017-07-28 02:39:49 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-05-28 14:07:31 +03:00
|
|
|
rpc ConnectPeer (ConnectPeerRequest) returns (ConnectPeerResponse);
|
2017-04-12 00:49:39 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `disconnect`
|
2017-07-28 02:39:49 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-05-28 14:07:31 +03:00
|
|
|
rpc DisconnectPeer (DisconnectPeerRequest) returns (DisconnectPeerResponse);
|
2017-04-12 00:49:39 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `listpeers`
|
2017-07-28 02:39:49 +03:00
|
|
|
ListPeers returns a verbose listing of all currently active peers.
|
|
|
|
*/
|
2020-05-28 14:07:31 +03:00
|
|
|
rpc ListPeers (ListPeersRequest) returns (ListPeersResponse);
|
2017-07-28 02:39:49 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-08-12 20:13:12 +03:00
|
|
|
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.
|
|
|
|
*/
|
|
|
|
rpc SubscribePeerEvents (PeerEventSubscription) returns (stream PeerEvent);
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `getinfo`
|
2017-07-28 02:39:49 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-05-28 14:07:31 +03:00
|
|
|
rpc GetInfo (GetInfoRequest) returns (GetInfoResponse);
|
2016-09-26 06:02:33 +03:00
|
|
|
|
2020-06-09 09:47:17 +03:00
|
|
|
/** 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.
|
|
|
|
*/
|
|
|
|
rpc GetRecoveryInfo (GetRecoveryInfoRequest)
|
|
|
|
returns (GetRecoveryInfoResponse);
|
|
|
|
|
2016-10-16 00:38:47 +03:00
|
|
|
// TODO(roasbeef): merge with below with bool?
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `pendingchannels`
|
2017-07-28 02:39:49 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-03-02 17:35:25 +03:00
|
|
|
rpc PendingChannels (PendingChannelsRequest)
|
2020-05-28 14:07:31 +03:00
|
|
|
returns (PendingChannelsResponse);
|
2017-07-28 02:39:49 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `listchannels`
|
2017-07-28 02:39:49 +03:00
|
|
|
ListChannels returns a description of all the open channels that this node
|
|
|
|
is a participant in.
|
|
|
|
*/
|
2020-05-28 14:07:31 +03:00
|
|
|
rpc ListChannels (ListChannelsRequest) returns (ListChannelsResponse);
|
2017-07-28 02:39:49 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-01-23 05:28:27 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-03-02 17:35:25 +03:00
|
|
|
rpc SubscribeChannelEvents (ChannelEventSubscription)
|
|
|
|
returns (stream ChannelEventUpdate);
|
2019-01-23 05:28:27 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `closedchannels`
|
2019-01-24 16:51:05 +03:00
|
|
|
ClosedChannels returns a description of all the closed channels that
|
2018-05-24 12:36:35 +03:00
|
|
|
this node was a participant in.
|
|
|
|
*/
|
2020-05-28 14:07:31 +03:00
|
|
|
rpc ClosedChannels (ClosedChannelsRequest) returns (ClosedChannelsResponse);
|
2018-05-24 12:36:35 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2017-07-28 02:39:49 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-05-28 14:07:31 +03:00
|
|
|
rpc OpenChannelSync (OpenChannelRequest) returns (ChannelPoint);
|
2016-11-11 04:33:24 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `openchannel`
|
2017-07-28 02:39:49 +03:00
|
|
|
OpenChannel attempts to open a singly funded channel specified in the
|
2017-11-23 08:36:27 +03:00
|
|
|
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
|
lnrpc: add ability to provide chan point shims for funding, new funding modifiers
In this commit, we start to expose some of the new external funding
functionality over the RPC interface.
First, we add a new `funding_shim` field to the regular `OpenChannel`
method. This can be used by a caller to express that certain parameters
of the funding flow have already been negotiated outside the protocol,
and should be used instead. For example, a shim can be provided to use a
particular key for the commitment key (ideally cold) rather than use one
this is generated by the wallet as normal, or signal that signing will
be carried out in an interactive manner (PSBT based).
Next, we add a brand new method: `FundingStateStep`. 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 new transition methods (funding state machine modifiers) in this
commit allow a party to register a funding intent that should be used
for a specified incoming pending channel ID. The "responder" to the
external channel flow should use this to prep lnd to be able to handle
the channel flow properly.
2019-11-14 07:54:34 +03:00
|
|
|
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.
|
2017-07-28 02:39:49 +03:00
|
|
|
*/
|
2017-04-12 00:49:39 +03:00
|
|
|
rpc OpenChannel (OpenChannelRequest) returns (stream OpenStatusUpdate);
|
2016-11-11 04:33:24 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
lnrpc: add ability to provide chan point shims for funding, new funding modifiers
In this commit, we start to expose some of the new external funding
functionality over the RPC interface.
First, we add a new `funding_shim` field to the regular `OpenChannel`
method. This can be used by a caller to express that certain parameters
of the funding flow have already been negotiated outside the protocol,
and should be used instead. For example, a shim can be provided to use a
particular key for the commitment key (ideally cold) rather than use one
this is generated by the wallet as normal, or signal that signing will
be carried out in an interactive manner (PSBT based).
Next, we add a brand new method: `FundingStateStep`. 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 new transition methods (funding state machine modifiers) in this
commit allow a party to register a funding intent that should be used
for a specified incoming pending channel ID. The "responder" to the
external channel flow should use this to prep lnd to be able to handle
the channel flow properly.
2019-11-14 07:54:34 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
rpc FundingStateStep (FundingTransitionMsg) returns (FundingStateStepResp);
|
lnrpc: add ability to provide chan point shims for funding, new funding modifiers
In this commit, we start to expose some of the new external funding
functionality over the RPC interface.
First, we add a new `funding_shim` field to the regular `OpenChannel`
method. This can be used by a caller to express that certain parameters
of the funding flow have already been negotiated outside the protocol,
and should be used instead. For example, a shim can be provided to use a
particular key for the commitment key (ideally cold) rather than use one
this is generated by the wallet as normal, or signal that signing will
be carried out in an interactive manner (PSBT based).
Next, we add a brand new method: `FundingStateStep`. 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 new transition methods (funding state machine modifiers) in this
commit allow a party to register a funding intent that should be used
for a specified incoming pending channel ID. The "responder" to the
external channel flow should use this to prep lnd to be able to handle
the channel flow properly.
2019-11-14 07:54:34 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-08-08 05:14:53 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-03-02 17:35:25 +03:00
|
|
|
rpc ChannelAcceptor (stream ChannelAcceptResponse)
|
|
|
|
returns (stream ChannelAcceptRequest);
|
2019-08-08 05:14:53 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `closechannel`
|
2017-07-28 02:39:49 +03:00
|
|
|
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
|
2017-11-23 08:36:27 +03:00
|
|
|
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.
|
2017-07-28 02:39:49 +03:00
|
|
|
*/
|
2020-05-28 14:07:31 +03:00
|
|
|
rpc CloseChannel (CloseChannelRequest) returns (stream CloseStatusUpdate);
|
2016-07-13 03:36:34 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `abandonchannel`
|
2018-05-29 12:26:47 +03:00
|
|
|
AbandonChannel removes all channel state from the database except for a
|
|
|
|
close summary. This method can be used to get rid of permanently unusable
|
2020-08-21 14:08:36 +03:00
|
|
|
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.
|
2018-05-29 12:26:47 +03:00
|
|
|
*/
|
2020-05-28 14:07:31 +03:00
|
|
|
rpc AbandonChannel (AbandonChannelRequest) returns (AbandonChannelResponse);
|
2018-05-29 12:26:47 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `sendpayment`
|
2020-05-12 09:52:07 +03:00
|
|
|
Deprecated, use routerrpc.SendPaymentV2. SendPayment dispatches a
|
2020-03-30 16:50:41 +03:00
|
|
|
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.
|
|
|
|
*/
|
|
|
|
rpc SendPayment (stream SendRequest) returns (stream SendResponse) {
|
|
|
|
option deprecated = true;
|
|
|
|
}
|
2016-11-11 04:33:24 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2017-07-28 02:39:49 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-05-28 14:07:31 +03:00
|
|
|
rpc SendPaymentSync (SendRequest) returns (SendResponse);
|
2016-09-19 21:52:23 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `sendtoroute`
|
2020-05-12 09:51:26 +03:00
|
|
|
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.
|
2018-01-25 08:08:46 +03:00
|
|
|
*/
|
2020-05-12 09:51:26 +03:00
|
|
|
rpc SendToRoute (stream SendToRouteRequest) returns (stream SendResponse) {
|
|
|
|
option deprecated = true;
|
|
|
|
}
|
2018-01-25 08:08:46 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2018-06-07 06:29:42 +03:00
|
|
|
SendToRouteSync is a synchronous version of SendToRoute. It Will block
|
|
|
|
until the payment either fails or succeeds.
|
2018-01-25 08:08:46 +03:00
|
|
|
*/
|
2020-05-28 14:07:31 +03:00
|
|
|
rpc SendToRouteSync (SendToRouteRequest) returns (SendResponse);
|
2018-01-25 08:08:46 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `addinvoice`
|
2017-07-28 02:39:49 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-05-28 14:07:31 +03:00
|
|
|
rpc AddInvoice (Invoice) returns (AddInvoiceResponse);
|
2017-07-28 02:39:49 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `listinvoices`
|
2017-07-28 02:39:49 +03:00
|
|
|
ListInvoices returns a list of all the invoices currently stored within the
|
2018-09-14 00:50:58 +03:00
|
|
|
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
|
2019-01-23 05:23:39 +03:00
|
|
|
next request. By default, the first 100 invoices created will be returned.
|
|
|
|
Backwards pagination is also supported through the Reversed flag.
|
2017-07-28 02:39:49 +03:00
|
|
|
*/
|
2020-05-28 14:07:31 +03:00
|
|
|
rpc ListInvoices (ListInvoiceRequest) returns (ListInvoiceResponse);
|
2017-07-28 02:39:49 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `lookupinvoice`
|
2018-02-07 06:11:11 +03:00
|
|
|
LookupInvoice attempts to look up an invoice according to its payment hash.
|
2017-07-28 02:39:49 +03:00
|
|
|
The passed payment hash *must* be exactly 32 bytes, if not, an error is
|
|
|
|
returned.
|
|
|
|
*/
|
2020-05-28 14:07:31 +03:00
|
|
|
rpc LookupInvoice (PaymentHash) returns (Invoice);
|
2017-07-28 02:39:49 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2018-04-18 08:22:55 +03:00
|
|
|
SubscribeInvoices returns a uni-directional stream (server -> client) for
|
2018-04-25 06:41:22 +03:00
|
|
|
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
|
2019-11-01 11:45:02 +03:00
|
|
|
invoices with an add_index greater than the specified value. If the
|
2018-04-25 06:41:22 +03:00
|
|
|
settle_index is specified, the next, we'll send out all settle events for
|
2019-11-01 11:45:02 +03:00
|
|
|
invoices with a settle_index greater than the specified value. One or both
|
2018-04-25 06:41:22 +03:00
|
|
|
of these fields can be set. If no fields are set, then we'll only send out
|
|
|
|
the latest add/settle events.
|
2017-07-28 02:39:49 +03:00
|
|
|
*/
|
2020-05-28 14:07:31 +03:00
|
|
|
rpc SubscribeInvoices (InvoiceSubscription) returns (stream Invoice);
|
2017-07-28 02:39:49 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `decodepayreq`
|
2017-07-28 02:39:49 +03:00
|
|
|
DecodePayReq takes an encoded payment request string and attempts to decode
|
|
|
|
it, returning a full description of the conditions encoded within the
|
|
|
|
payment request.
|
|
|
|
*/
|
2020-05-28 14:07:31 +03:00
|
|
|
rpc DecodePayReq (PayReqString) returns (PayReq);
|
2016-09-19 21:52:23 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `listpayments`
|
2017-07-28 02:39:49 +03:00
|
|
|
ListPayments returns a list of all outgoing payments.
|
|
|
|
*/
|
2020-05-28 14:07:31 +03:00
|
|
|
rpc ListPayments (ListPaymentsRequest) returns (ListPaymentsResponse);
|
2016-12-05 14:59:36 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2017-07-28 02:39:49 +03:00
|
|
|
DeleteAllPayments deletes all outgoing payments from DB.
|
|
|
|
*/
|
2020-03-02 17:35:25 +03:00
|
|
|
rpc DeleteAllPayments (DeleteAllPaymentsRequest)
|
2020-05-28 14:07:31 +03:00
|
|
|
returns (DeleteAllPaymentsResponse);
|
2016-07-13 03:36:34 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `describegraph`
|
2017-07-28 02:39:49 +03:00
|
|
|
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
|
2019-11-01 11:45:02 +03:00
|
|
|
vertexes themselves. As this is a directed graph, the edges also contain
|
2017-07-28 02:39:49 +03:00
|
|
|
the node directional specific routing policy which includes: the time lock
|
|
|
|
delta, fee information, etc.
|
|
|
|
*/
|
2020-05-28 14:07:31 +03:00
|
|
|
rpc DescribeGraph (ChannelGraphRequest) returns (ChannelGraph);
|
2016-12-27 08:44:44 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `getnodemetrics`
|
2020-03-19 13:14:28 +03:00
|
|
|
GetNodeMetrics returns node metrics calculated from the graph. Currently
|
|
|
|
the only supported metric is betweenness centrality of individual nodes.
|
|
|
|
*/
|
2020-05-28 14:07:31 +03:00
|
|
|
rpc GetNodeMetrics (NodeMetricsRequest) returns (NodeMetricsResponse);
|
2020-03-19 13:14:28 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `getchaninfo`
|
2017-07-28 02:39:49 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-05-28 14:07:31 +03:00
|
|
|
rpc GetChanInfo (ChanInfoRequest) returns (ChannelEdge);
|
2016-12-27 08:44:44 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `getnodeinfo`
|
2017-07-28 02:39:49 +03:00
|
|
|
GetNodeInfo returns the latest advertised, aggregated, and authenticated
|
|
|
|
channel information for the specified node identified by its public key.
|
|
|
|
*/
|
2020-05-28 14:07:31 +03:00
|
|
|
rpc GetNodeInfo (NodeInfoRequest) returns (NodeInfo);
|
2016-12-27 08:44:44 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `queryroutes`
|
2017-07-28 02:39:49 +03:00
|
|
|
QueryRoutes attempts to query the daemon's Channel Router for a possible
|
|
|
|
route to a target destination capable of carrying a specific amount of
|
2019-05-14 00:31:32 +03:00
|
|
|
satoshis. The returned route contains the full details required to craft and
|
2017-07-28 02:39:49 +03:00
|
|
|
send an HTLC, also including the necessary information that should be
|
2018-02-07 06:11:11 +03:00
|
|
|
present within the Sphinx packet encapsulated within the HTLC.
|
2020-06-03 18:35:19 +03:00
|
|
|
|
|
|
|
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.
|
2017-07-28 02:39:49 +03:00
|
|
|
*/
|
2020-05-28 14:07:31 +03:00
|
|
|
rpc QueryRoutes (QueryRoutesRequest) returns (QueryRoutesResponse);
|
2016-12-27 08:44:44 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `getnetworkinfo`
|
2017-07-28 02:39:49 +03:00
|
|
|
GetNetworkInfo returns some basic stats about the known channel graph from
|
|
|
|
the point of view of the node.
|
|
|
|
*/
|
2020-05-28 14:07:31 +03:00
|
|
|
rpc GetNetworkInfo (NetworkInfoRequest) returns (NetworkInfo);
|
2016-12-27 08:44:44 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `stop`
|
2017-07-28 02:39:49 +03:00
|
|
|
StopDaemon will send a shutdown request to the interrupt handler, triggering
|
|
|
|
a graceful shutdown of the daemon.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
rpc StopDaemon (StopRequest) returns (StopResponse);
|
2017-05-12 00:55:56 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2017-07-28 02:39:49 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-03-02 17:35:25 +03:00
|
|
|
rpc SubscribeChannelGraph (GraphTopologySubscription)
|
|
|
|
returns (stream GraphTopologyUpdate);
|
2017-03-14 06:37:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `debuglevel`
|
2017-07-28 02:39:49 +03:00
|
|
|
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.
|
|
|
|
*/
|
2017-04-12 00:49:39 +03:00
|
|
|
rpc DebugLevel (DebugLevelRequest) returns (DebugLevelResponse);
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `feereport`
|
2017-08-22 10:07:25 +03:00
|
|
|
FeeReport allows the caller to obtain a report detailing the current fee
|
|
|
|
schedule enforced by the node globally for each channel.
|
|
|
|
*/
|
2020-05-28 14:07:31 +03:00
|
|
|
rpc FeeReport (FeeReportRequest) returns (FeeReportResponse);
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `updatechanpolicy`
|
2017-12-16 00:11:23 +03:00
|
|
|
UpdateChannelPolicy allows the caller to update the fee schedule and
|
|
|
|
channel policies for all channels globally, or a particular channel.
|
2017-08-22 10:07:25 +03:00
|
|
|
*/
|
2020-03-02 17:35:25 +03:00
|
|
|
rpc UpdateChannelPolicy (PolicyUpdateRequest)
|
2020-05-28 14:07:31 +03:00
|
|
|
returns (PolicyUpdateResponse);
|
2018-02-28 09:22:06 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `fwdinghistory`
|
2018-02-28 09:22:06 +03:00
|
|
|
ForwardingHistory allows the caller to query the htlcswitch for a record of
|
2018-12-10 06:57:57 +03:00
|
|
|
all HTLCs forwarded within the target time range, and integer offset
|
2021-06-11 00:55:00 +03:00
|
|
|
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.
|
2018-02-28 09:22:06 +03:00
|
|
|
|
|
|
|
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.
|
2019-11-01 11:45:02 +03:00
|
|
|
As a result each message can only contain 50k entries. Each response has
|
2018-02-28 09:22:06 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-03-02 17:35:25 +03:00
|
|
|
rpc ForwardingHistory (ForwardingHistoryRequest)
|
2020-05-28 14:07:31 +03:00
|
|
|
returns (ForwardingHistoryResponse);
|
2018-12-10 06:57:57 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `exportchanbackup`
|
2018-12-10 06:57:57 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-03-02 17:35:25 +03:00
|
|
|
rpc ExportChannelBackup (ExportChannelBackupRequest)
|
2020-05-28 14:07:31 +03:00
|
|
|
returns (ChannelBackup);
|
2018-12-10 06:57:57 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2018-12-10 06:57:57 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-03-02 17:35:25 +03:00
|
|
|
rpc ExportAllChannelBackups (ChanBackupExportRequest)
|
2020-05-28 14:07:31 +03:00
|
|
|
returns (ChanBackupSnapshot);
|
2018-12-10 06:57:57 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-04-05 01:52:31 +03:00
|
|
|
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.
|
2019-03-11 03:53:53 +03:00
|
|
|
*/
|
2020-03-02 17:35:25 +03:00
|
|
|
rpc VerifyChanBackup (ChanBackupSnapshot)
|
2020-05-28 14:07:31 +03:00
|
|
|
returns (VerifyChanBackupResponse);
|
2019-03-11 03:53:53 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `restorechanbackup`
|
2018-12-10 06:57:57 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-03-02 17:35:25 +03:00
|
|
|
rpc RestoreChannelBackups (RestoreChanBackupRequest)
|
2020-05-28 14:07:31 +03:00
|
|
|
returns (RestoreBackupResponse);
|
2018-12-10 06:57:57 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2018-12-10 06:57:57 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-03-02 17:35:25 +03:00
|
|
|
rpc SubscribeChannelBackups (ChannelBackupSubscription)
|
2020-05-28 14:07:31 +03:00
|
|
|
returns (stream ChanBackupSnapshot);
|
2019-10-23 14:28:17 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* lncli: `bakemacaroon`
|
2019-10-23 14:28:17 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-05-28 14:07:31 +03:00
|
|
|
rpc BakeMacaroon (BakeMacaroonRequest) returns (BakeMacaroonResponse);
|
2020-07-23 19:36:42 +03:00
|
|
|
|
|
|
|
/* lncli: `listmacaroonids`
|
|
|
|
ListMacaroonIDs returns all root key IDs that are in use.
|
|
|
|
*/
|
|
|
|
rpc ListMacaroonIDs (ListMacaroonIDsRequest)
|
|
|
|
returns (ListMacaroonIDsResponse);
|
|
|
|
|
|
|
|
/* lncli: `deletemacaroonid`
|
|
|
|
DeleteMacaroonID deletes the specified macaroon ID and invalidates all
|
|
|
|
macaroons derived from that ID.
|
|
|
|
*/
|
|
|
|
rpc DeleteMacaroonID (DeleteMacaroonIDRequest)
|
|
|
|
returns (DeleteMacaroonIDResponse);
|
2020-09-04 10:22:38 +03:00
|
|
|
|
|
|
|
/* lncli: `listpermissions`
|
|
|
|
ListPermissions lists all RPC method URIs and their required macaroon
|
|
|
|
permissions to access them.
|
|
|
|
*/
|
|
|
|
rpc ListPermissions (ListPermissionsRequest)
|
|
|
|
returns (ListPermissionsResponse);
|
2016-12-27 08:44:44 +03:00
|
|
|
}
|
2016-10-16 00:38:47 +03:00
|
|
|
|
2018-09-27 16:49:44 +03:00
|
|
|
message Utxo {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The type of address
|
2020-02-12 18:13:07 +03:00
|
|
|
AddressType address_type = 1;
|
2018-09-27 16:49:44 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The address
|
2020-02-11 15:53:39 +03:00
|
|
|
string address = 2;
|
2018-09-27 16:49:44 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The value of the unspent coin in satoshis
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 amount_sat = 3;
|
2018-09-27 16:49:44 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The pkscript in hex
|
2020-02-11 15:53:39 +03:00
|
|
|
string pk_script = 4;
|
2018-09-27 16:49:44 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The outpoint in format txid:n
|
2020-02-11 15:53:39 +03:00
|
|
|
OutPoint outpoint = 5;
|
2018-09-27 16:49:44 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The number of confirmations for the Utxo
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 confirmations = 6;
|
2018-09-27 16:49:44 +03:00
|
|
|
}
|
|
|
|
|
2016-10-16 00:38:47 +03:00
|
|
|
message Transaction {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The transaction hash
|
2020-02-11 15:53:39 +03:00
|
|
|
string tx_hash = 1;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The transaction amount, denominated in satoshis
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 amount = 2;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The number of confirmations
|
2020-02-11 15:53:39 +03:00
|
|
|
int32 num_confirmations = 3;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The hash of the block this transaction was included in
|
2020-02-11 15:53:39 +03:00
|
|
|
string block_hash = 4;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The height of the block this transaction was included in
|
2020-02-11 15:53:39 +03:00
|
|
|
int32 block_height = 5;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Timestamp of this transaction
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 time_stamp = 6;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Fees paid for this transaction
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 total_fees = 7;
|
2017-12-06 20:19:07 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Addresses that received funds for this transaction
|
2020-02-11 15:53:39 +03:00
|
|
|
repeated string dest_addresses = 8;
|
2019-06-07 17:37:28 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The raw transaction hex.
|
2020-02-11 15:53:39 +03:00
|
|
|
string raw_tx_hex = 9;
|
2020-05-18 15:13:24 +03:00
|
|
|
|
|
|
|
// A label that was optionally set on transaction broadcast.
|
|
|
|
string label = 10;
|
2016-10-16 00:38:47 +03:00
|
|
|
}
|
|
|
|
message GetTransactionsRequest {
|
2020-05-05 22:10:06 +03:00
|
|
|
/*
|
|
|
|
The height from which to list transactions, inclusive. If this value is
|
|
|
|
greater than end_height, transactions will be read in reverse.
|
|
|
|
*/
|
|
|
|
int32 start_height = 1;
|
|
|
|
|
|
|
|
/*
|
|
|
|
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.
|
|
|
|
*/
|
|
|
|
int32 end_height = 2;
|
2021-02-20 04:41:53 +03:00
|
|
|
|
|
|
|
// An optional filter to only include transactions relevant to an account.
|
|
|
|
string account = 3;
|
2016-10-16 00:38:47 +03:00
|
|
|
}
|
2020-05-05 22:10:06 +03:00
|
|
|
|
2016-10-16 00:38:47 +03:00
|
|
|
message TransactionDetails {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The list of transactions relevant to the wallet.
|
2020-02-11 15:53:39 +03:00
|
|
|
repeated Transaction transactions = 1;
|
2016-10-16 00:38:47 +03:00
|
|
|
}
|
|
|
|
|
2018-04-19 01:13:55 +03:00
|
|
|
message FeeLimit {
|
|
|
|
oneof limit {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-11 18:44:08 +03:00
|
|
|
The fee limit expressed as a fixed amount of satoshis.
|
|
|
|
|
|
|
|
The fields fixed and fixed_msat are mutually exclusive.
|
|
|
|
*/
|
2018-04-19 01:13:55 +03:00
|
|
|
int64 fixed = 1;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-11 18:44:08 +03:00
|
|
|
The fee limit expressed as a fixed amount of millisatoshis.
|
|
|
|
|
|
|
|
The fields fixed and fixed_msat are mutually exclusive.
|
|
|
|
*/
|
|
|
|
int64 fixed_msat = 3;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The fee limit expressed as a percentage of the payment amount.
|
2018-04-19 01:13:55 +03:00
|
|
|
int64 percent = 2;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-07-13 03:36:34 +03:00
|
|
|
message SendRequest {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-01 11:45:02 +03:00
|
|
|
The identity pubkey of the payment recipient. When using REST, this field
|
|
|
|
must be encoded as base64.
|
|
|
|
*/
|
2016-07-13 03:36:34 +03:00
|
|
|
bytes dest = 1;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-01 11:45:02 +03:00
|
|
|
The hex-encoded identity pubkey of the payment recipient. Deprecated now
|
|
|
|
that the REST gateway supports base64 encoding of bytes fields.
|
|
|
|
*/
|
|
|
|
string dest_string = 2 [deprecated = true];
|
2016-11-11 04:33:24 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-11 18:44:08 +03:00
|
|
|
The amount to send expressed in satoshis.
|
|
|
|
|
|
|
|
The fields amt and amt_msat are mutually exclusive.
|
|
|
|
*/
|
2016-11-11 04:33:24 +03:00
|
|
|
int64 amt = 3;
|
2016-07-13 03:36:34 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-11 18:44:08 +03:00
|
|
|
The amount to send expressed in millisatoshis.
|
|
|
|
|
|
|
|
The fields amt and amt_msat are mutually exclusive.
|
|
|
|
*/
|
|
|
|
int64 amt_msat = 12;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-01 11:45:02 +03:00
|
|
|
The hash to use within the payment's HTLC. When using REST, this field
|
|
|
|
must be encoded as base64.
|
|
|
|
*/
|
2016-11-11 04:33:24 +03:00
|
|
|
bytes payment_hash = 4;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-01 11:45:02 +03:00
|
|
|
The hex-encoded hash to use within the payment's HTLC. Deprecated now
|
|
|
|
that the REST gateway supports base64 encoding of bytes fields.
|
|
|
|
*/
|
|
|
|
string payment_hash_string = 5 [deprecated = true];
|
2016-11-11 04:33:24 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-01 11:45:02 +03:00
|
|
|
A bare-bones invoice for a payment within the Lightning Network. With the
|
2017-07-28 02:39:49 +03:00
|
|
|
details of the invoice, the sender has all the data necessary to send a
|
|
|
|
payment to the recipient.
|
|
|
|
*/
|
2017-01-03 02:31:38 +03:00
|
|
|
string payment_request = 6;
|
2018-01-17 07:20:34 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2018-04-19 01:13:55 +03:00
|
|
|
The CLTV delta from the current height that should be used to set the
|
|
|
|
timelock for the final hop.
|
|
|
|
*/
|
2018-01-17 07:20:34 +03:00
|
|
|
int32 final_cltv_delta = 7;
|
2018-02-01 01:36:10 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2018-04-19 01:13:55 +03:00
|
|
|
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.
|
|
|
|
*/
|
|
|
|
FeeLimit fee_limit = 8;
|
2019-02-01 15:53:27 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-02-01 15:53:27 +03:00
|
|
|
The channel id of the channel that must be taken to the first hop. If zero,
|
|
|
|
any channel may be used.
|
|
|
|
*/
|
2018-12-19 23:49:41 +03:00
|
|
|
uint64 outgoing_chan_id = 9 [jstype = JS_STRING];
|
2018-11-04 13:11:48 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-18 14:08:42 +03:00
|
|
|
The pubkey of the last hop of the route. If empty, any hop may be used.
|
|
|
|
*/
|
|
|
|
bytes last_hop_pubkey = 13;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-10-11 22:46:10 +03:00
|
|
|
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.
|
2018-11-04 13:11:48 +03:00
|
|
|
*/
|
|
|
|
uint32 cltv_limit = 10;
|
2019-07-31 07:44:02 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-07-31 07:44:02 +03:00
|
|
|
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
|
2019-11-20 14:00:25 +03:00
|
|
|
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.
|
2019-07-31 07:44:02 +03:00
|
|
|
*/
|
2019-11-20 14:00:25 +03:00
|
|
|
map<uint64, bytes> dest_custom_records = 11;
|
2019-11-25 16:13:21 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// If set, circular payments to self are permitted.
|
2019-11-25 16:13:21 +03:00
|
|
|
bool allow_self_payment = 14;
|
2019-12-19 10:57:23 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-12-19 10:57:23 +03:00
|
|
|
Features assumed to be supported by the final node. All transitive feature
|
2020-01-18 00:12:02 +03:00
|
|
|
dependencies must also be set properly. For a given feature bit pair, either
|
2019-12-20 03:25:59 +03:00
|
|
|
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.
|
2019-12-19 10:57:23 +03:00
|
|
|
*/
|
|
|
|
repeated FeatureBit dest_features = 15;
|
2021-03-15 11:30:25 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
The payment address of the generated invoice.
|
|
|
|
*/
|
|
|
|
bytes payment_addr = 16;
|
2016-07-13 03:36:34 +03:00
|
|
|
}
|
2018-11-04 13:11:48 +03:00
|
|
|
|
2016-10-16 00:38:47 +03:00
|
|
|
message SendResponse {
|
2020-02-11 15:53:39 +03:00
|
|
|
string payment_error = 1;
|
|
|
|
bytes payment_preimage = 2;
|
|
|
|
Route payment_route = 3;
|
|
|
|
bytes payment_hash = 4;
|
2015-12-30 23:19:09 +03:00
|
|
|
}
|
|
|
|
|
2018-01-25 08:08:46 +03:00
|
|
|
message SendToRouteRequest {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-01 11:45:02 +03:00
|
|
|
The payment hash to use for the HTLC. When using REST, this field must be
|
|
|
|
encoded as base64.
|
|
|
|
*/
|
2018-01-25 08:08:46 +03:00
|
|
|
bytes payment_hash = 1;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-01 11:45:02 +03:00
|
|
|
An optional hex-encoded payment hash to be used for the HTLC. Deprecated now
|
|
|
|
that the REST gateway supports base64 encoding of bytes fields.
|
|
|
|
*/
|
|
|
|
string payment_hash_string = 2 [deprecated = true];
|
2018-01-25 08:08:46 +03:00
|
|
|
|
2018-08-08 12:09:30 +03:00
|
|
|
reserved 3;
|
2019-01-21 14:54:08 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Route that should be used to attempt to complete the payment.
|
2019-01-21 14:54:08 +03:00
|
|
|
Route route = 4;
|
2018-01-25 08:08:46 +03:00
|
|
|
}
|
|
|
|
|
2019-08-08 05:14:53 +03:00
|
|
|
message ChannelAcceptRequest {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The pubkey of the node that wishes to open an inbound channel.
|
2019-08-08 05:14:53 +03:00
|
|
|
bytes node_pubkey = 1;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The hash of the genesis block that the proposed channel resides in.
|
2019-08-08 05:14:53 +03:00
|
|
|
bytes chain_hash = 2;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The pending channel id.
|
2019-08-08 05:14:53 +03:00
|
|
|
bytes pending_chan_id = 3;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The funding amount in satoshis that initiator wishes to use in the
|
|
|
|
// channel.
|
2019-08-08 05:14:53 +03:00
|
|
|
uint64 funding_amt = 4;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The push amount of the proposed channel in millisatoshis.
|
2019-08-08 05:14:53 +03:00
|
|
|
uint64 push_amt = 5;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The dust limit of the initiator's commitment tx.
|
2019-08-08 05:14:53 +03:00
|
|
|
uint64 dust_limit = 6;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The maximum amount of coins in millisatoshis that can be pending in this
|
|
|
|
// channel.
|
2019-08-08 05:14:53 +03:00
|
|
|
uint64 max_value_in_flight = 7;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The minimum amount of satoshis the initiator requires us to have at all
|
|
|
|
// times.
|
2019-08-08 05:14:53 +03:00
|
|
|
uint64 channel_reserve = 8;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The smallest HTLC in millisatoshis that the initiator will accept.
|
2019-08-08 05:14:53 +03:00
|
|
|
uint64 min_htlc = 9;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The initial fee rate that the initiator suggests for both commitment
|
|
|
|
// transactions.
|
2019-08-08 05:14:53 +03:00
|
|
|
uint64 fee_per_kw = 10;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-03-02 17:35:25 +03:00
|
|
|
The number of blocks to use for the relative time lock in the pay-to-self
|
|
|
|
output of both commitment transactions.
|
2019-08-08 05:14:53 +03:00
|
|
|
*/
|
|
|
|
uint32 csv_delay = 11;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The total number of incoming HTLC's that the initiator will accept.
|
2019-08-08 05:14:53 +03:00
|
|
|
uint32 max_accepted_htlcs = 12;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// A bit-field which the initiator uses to specify proposed channel
|
|
|
|
// behavior.
|
2019-08-08 05:14:53 +03:00
|
|
|
uint32 channel_flags = 13;
|
|
|
|
}
|
|
|
|
|
|
|
|
message ChannelAcceptResponse {
|
2020-05-06 17:51:14 +03:00
|
|
|
// Whether or not the client accepts the channel.
|
2019-08-08 05:14:53 +03:00
|
|
|
bool accept = 1;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The pending channel id to which this response applies.
|
2019-08-08 05:14:53 +03:00
|
|
|
bytes pending_chan_id = 2;
|
2020-11-09 10:34:50 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
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.
|
|
|
|
*/
|
|
|
|
string error = 3;
|
2020-11-09 10:34:52 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
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.
|
|
|
|
*/
|
|
|
|
string upfront_shutdown = 4;
|
|
|
|
|
|
|
|
/*
|
|
|
|
The csv delay (in blocks) that we require for the remote party.
|
|
|
|
*/
|
|
|
|
uint32 csv_delay = 5;
|
|
|
|
|
|
|
|
/*
|
|
|
|
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).
|
|
|
|
*/
|
|
|
|
uint64 reserve_sat = 6;
|
|
|
|
|
|
|
|
/*
|
|
|
|
The maximum amount of funds in millisatoshis that we allow the remote peer
|
|
|
|
to have in outstanding htlcs.
|
|
|
|
*/
|
|
|
|
uint64 in_flight_max_msat = 7;
|
|
|
|
|
|
|
|
/*
|
|
|
|
The maximum number of htlcs that the remote peer can offer us.
|
|
|
|
*/
|
|
|
|
uint32 max_htlc_count = 8;
|
|
|
|
|
|
|
|
/*
|
|
|
|
The minimum value in millisatoshis for incoming htlcs on the channel.
|
|
|
|
*/
|
|
|
|
uint64 min_htlc_in = 9;
|
|
|
|
|
|
|
|
/*
|
|
|
|
The number of confirmations we require before we consider the channel open.
|
|
|
|
*/
|
|
|
|
uint32 min_accept_depth = 10;
|
2019-08-08 05:14:53 +03:00
|
|
|
}
|
|
|
|
|
2016-06-21 21:52:09 +03:00
|
|
|
message ChannelPoint {
|
2018-01-11 07:17:18 +03:00
|
|
|
oneof funding_txid {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-01 11:45:02 +03:00
|
|
|
Txid of the funding transaction. When using REST, this field must be
|
|
|
|
encoded as base64.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
bytes funding_txid_bytes = 1;
|
2017-07-28 02:39:49 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-01 11:45:02 +03:00
|
|
|
Hex-encoded string representing the byte-reversed hash of the funding
|
|
|
|
transaction.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
string funding_txid_str = 2;
|
2018-01-11 07:17:18 +03:00
|
|
|
}
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The index of the output of the funding transaction
|
2020-02-11 15:53:39 +03:00
|
|
|
uint32 output_index = 3;
|
2016-06-21 21:52:09 +03:00
|
|
|
}
|
|
|
|
|
2019-02-02 05:01:51 +03:00
|
|
|
message OutPoint {
|
2020-05-06 17:51:14 +03:00
|
|
|
// Raw bytes representing the transaction id.
|
2020-02-11 15:53:39 +03:00
|
|
|
bytes txid_bytes = 1;
|
2019-02-02 05:01:51 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Reversed, hex-encoded string representing the transaction id.
|
2020-02-11 15:53:39 +03:00
|
|
|
string txid_str = 2;
|
2019-02-02 05:01:51 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The index of the output on the transaction.
|
2020-02-11 15:53:39 +03:00
|
|
|
uint32 output_index = 3;
|
2019-02-02 05:01:51 +03:00
|
|
|
}
|
|
|
|
|
2016-06-21 21:52:09 +03:00
|
|
|
message LightningAddress {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The identity pubkey of the Lightning node
|
2020-02-11 15:53:39 +03:00
|
|
|
string pubkey = 1;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The network location of the lightning node, e.g. `69.69.69.69:1337` or
|
|
|
|
// `localhost:10011`
|
2020-02-11 15:53:39 +03:00
|
|
|
string host = 2;
|
2016-06-21 21:52:09 +03:00
|
|
|
}
|
|
|
|
|
2019-03-05 16:22:30 +03:00
|
|
|
message EstimateFeeRequest {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The map from addresses to amounts for the transaction.
|
2019-03-05 16:22:30 +03:00
|
|
|
map<string, int64> AddrToAmount = 1;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The target number of blocks that this transaction should be confirmed
|
|
|
|
// by.
|
2019-03-05 16:22:30 +03:00
|
|
|
int32 target_conf = 2;
|
2021-04-22 20:25:50 +03:00
|
|
|
|
|
|
|
// The minimum number of confirmations each one of your outputs used for
|
|
|
|
// the transaction must satisfy.
|
|
|
|
int32 min_confs = 3;
|
|
|
|
|
|
|
|
// Whether unconfirmed outputs should be used as inputs for the transaction.
|
|
|
|
bool spend_unconfirmed = 4;
|
2019-03-05 16:22:30 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
message EstimateFeeResponse {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The total fee in satoshis.
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 fee_sat = 1;
|
2019-03-05 16:22:30 +03:00
|
|
|
|
2021-03-11 03:29:50 +03:00
|
|
|
// Deprecated, use sat_per_vbyte.
|
2020-10-20 05:22:36 +03:00
|
|
|
// The fee rate in satoshi/vbyte.
|
2021-03-11 03:29:50 +03:00
|
|
|
int64 feerate_sat_per_byte = 2 [deprecated = true];
|
|
|
|
|
|
|
|
// The fee rate in satoshi/vbyte.
|
|
|
|
uint64 sat_per_vbyte = 3;
|
2019-03-05 16:22:30 +03:00
|
|
|
}
|
|
|
|
|
2015-12-30 23:19:09 +03:00
|
|
|
message SendManyRequest {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The map from addresses to amounts
|
2015-12-30 23:19:09 +03:00
|
|
|
map<string, int64> AddrToAmount = 1;
|
2017-11-23 08:36:27 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The target number of blocks that this transaction should be confirmed
|
|
|
|
// by.
|
2017-11-23 08:36:27 +03:00
|
|
|
int32 target_conf = 3;
|
|
|
|
|
2020-10-20 05:22:36 +03:00
|
|
|
// A manual fee rate set in sat/vbyte that should be used when crafting the
|
2020-05-06 17:51:14 +03:00
|
|
|
// transaction.
|
2021-03-11 03:29:50 +03:00
|
|
|
uint64 sat_per_vbyte = 4;
|
|
|
|
|
|
|
|
// Deprecated, use sat_per_vbyte.
|
|
|
|
// A manual fee rate set in sat/vbyte that should be used when crafting the
|
|
|
|
// transaction.
|
|
|
|
int64 sat_per_byte = 5 [deprecated = true];
|
2020-05-18 15:13:24 +03:00
|
|
|
|
|
|
|
// An optional label for the transaction, limited to 500 characters.
|
|
|
|
string label = 6;
|
2020-09-27 18:48:15 +03:00
|
|
|
|
|
|
|
// The minimum number of confirmations each one of your outputs used for
|
|
|
|
// the transaction must satisfy.
|
|
|
|
int32 min_confs = 7;
|
|
|
|
|
|
|
|
// Whether unconfirmed outputs should be used as inputs for the transaction.
|
|
|
|
bool spend_unconfirmed = 8;
|
2015-12-30 23:19:09 +03:00
|
|
|
}
|
|
|
|
message SendManyResponse {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The id of the transaction
|
2020-02-11 15:53:39 +03:00
|
|
|
string txid = 1;
|
2015-12-30 23:19:09 +03:00
|
|
|
}
|
|
|
|
|
2016-06-29 21:28:10 +03:00
|
|
|
message SendCoinsRequest {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The address to send coins to
|
2016-06-29 21:28:10 +03:00
|
|
|
string addr = 1;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The amount in satoshis to send
|
2016-06-29 21:28:10 +03:00
|
|
|
int64 amount = 2;
|
2017-11-23 08:36:27 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The target number of blocks that this transaction should be confirmed
|
|
|
|
// by.
|
2017-11-23 08:36:27 +03:00
|
|
|
int32 target_conf = 3;
|
|
|
|
|
2020-10-20 05:22:36 +03:00
|
|
|
// A manual fee rate set in sat/vbyte that should be used when crafting the
|
2020-05-06 17:51:14 +03:00
|
|
|
// transaction.
|
2021-03-11 03:29:50 +03:00
|
|
|
uint64 sat_per_vbyte = 4;
|
|
|
|
|
|
|
|
// Deprecated, use sat_per_vbyte.
|
|
|
|
// A manual fee rate set in sat/vbyte that should be used when crafting the
|
|
|
|
// transaction.
|
|
|
|
int64 sat_per_byte = 5 [deprecated = true];
|
2018-11-18 08:07:48 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2018-11-18 08:07:48 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
bool send_all = 6;
|
2020-05-18 15:13:24 +03:00
|
|
|
|
|
|
|
// An optional label for the transaction, limited to 500 characters.
|
|
|
|
string label = 7;
|
2020-09-27 18:48:15 +03:00
|
|
|
|
|
|
|
// The minimum number of confirmations each one of your outputs used for
|
|
|
|
// the transaction must satisfy.
|
|
|
|
int32 min_confs = 8;
|
|
|
|
|
|
|
|
// Whether unconfirmed outputs should be used as inputs for the transaction.
|
|
|
|
bool spend_unconfirmed = 9;
|
2016-06-29 21:28:10 +03:00
|
|
|
}
|
|
|
|
message SendCoinsResponse {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The transaction ID of the transaction
|
2020-02-11 15:53:39 +03:00
|
|
|
string txid = 1;
|
2016-06-29 21:28:10 +03:00
|
|
|
}
|
|
|
|
|
2018-09-27 16:49:44 +03:00
|
|
|
message ListUnspentRequest {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The minimum number of confirmations to be included.
|
2019-02-12 00:01:49 +03:00
|
|
|
int32 min_confs = 1;
|
2018-09-27 16:49:44 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The maximum number of confirmations to be included.
|
2019-02-12 00:01:49 +03:00
|
|
|
int32 max_confs = 2;
|
2021-02-20 04:41:53 +03:00
|
|
|
|
|
|
|
// An optional filter to only include outputs belonging to an account.
|
|
|
|
string account = 3;
|
2018-09-27 16:49:44 +03:00
|
|
|
}
|
|
|
|
message ListUnspentResponse {
|
2020-05-06 17:51:14 +03:00
|
|
|
// A list of utxos
|
2020-02-11 15:53:39 +03:00
|
|
|
repeated Utxo utxos = 1;
|
2018-09-27 16:49:44 +03:00
|
|
|
}
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2017-07-28 02:39:49 +03:00
|
|
|
`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)
|
|
|
|
*/
|
2018-09-27 16:49:44 +03:00
|
|
|
enum AddressType {
|
2020-02-11 15:53:39 +03:00
|
|
|
WITNESS_PUBKEY_HASH = 0;
|
|
|
|
NESTED_PUBKEY_HASH = 1;
|
|
|
|
UNUSED_WITNESS_PUBKEY_HASH = 2;
|
|
|
|
UNUSED_NESTED_PUBKEY_HASH = 3;
|
2018-09-27 16:49:44 +03:00
|
|
|
}
|
2017-07-28 02:39:49 +03:00
|
|
|
|
2018-09-27 16:49:44 +03:00
|
|
|
message NewAddressRequest {
|
2021-02-20 04:41:53 +03:00
|
|
|
// The type of address to generate.
|
2016-04-25 06:26:32 +03:00
|
|
|
AddressType type = 1;
|
2021-02-20 04:41:53 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
The name of the account to generate a new address for. If empty, the
|
|
|
|
default wallet account is used.
|
|
|
|
*/
|
|
|
|
string account = 2;
|
2016-04-25 06:26:32 +03:00
|
|
|
}
|
2015-12-30 23:19:09 +03:00
|
|
|
message NewAddressResponse {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The newly generated wallet address
|
2020-02-11 15:53:39 +03:00
|
|
|
string address = 1;
|
2015-12-30 23:19:09 +03:00
|
|
|
}
|
2015-12-31 05:58:15 +03:00
|
|
|
|
2017-04-20 05:28:10 +03:00
|
|
|
message SignMessageRequest {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-01 11:45:02 +03:00
|
|
|
The message to be signed. When using REST, this field must be encoded as
|
|
|
|
base64.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
bytes msg = 1;
|
2017-04-20 05:28:10 +03:00
|
|
|
}
|
|
|
|
message SignMessageResponse {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The signature for the given message
|
2020-02-11 15:53:39 +03:00
|
|
|
string signature = 1;
|
2017-04-20 05:28:10 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
message VerifyMessageRequest {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-01 11:45:02 +03:00
|
|
|
The message over which the signature is to be verified. When using REST,
|
|
|
|
this field must be encoded as base64.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
bytes msg = 1;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The signature to be verified over the given message
|
2020-02-11 15:53:39 +03:00
|
|
|
string signature = 2;
|
2017-04-20 05:28:10 +03:00
|
|
|
}
|
|
|
|
message VerifyMessageResponse {
|
2020-05-06 17:51:14 +03:00
|
|
|
// Whether the signature was valid over the given message
|
2020-02-11 15:53:39 +03:00
|
|
|
bool valid = 1;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The pubkey recovered from the signature
|
2020-02-11 15:53:39 +03:00
|
|
|
string pubkey = 2;
|
2017-04-20 05:28:10 +03:00
|
|
|
}
|
|
|
|
|
2016-01-17 06:03:47 +03:00
|
|
|
message ConnectPeerRequest {
|
2020-05-06 17:51:14 +03:00
|
|
|
// Lightning address of the peer, in the format `<pubkey>@host`
|
2016-06-21 21:52:09 +03:00
|
|
|
LightningAddress addr = 1;
|
2017-07-28 02:39:49 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/* If set, the daemon will attempt to persistently connect to the target
|
2019-11-01 11:45:02 +03:00
|
|
|
* peer. Otherwise, the call will be synchronous. */
|
2017-01-10 05:58:21 +03:00
|
|
|
bool perm = 2;
|
2020-08-25 07:54:31 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
The connection timeout value (in seconds) for this request. It won't affect
|
|
|
|
other requests.
|
|
|
|
*/
|
|
|
|
uint64 timeout = 3;
|
2015-12-31 05:58:15 +03:00
|
|
|
}
|
2016-01-17 06:03:47 +03:00
|
|
|
message ConnectPeerResponse {
|
2017-04-12 00:49:39 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
message DisconnectPeerRequest {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The pubkey of the node to disconnect from
|
2020-02-11 15:53:39 +03:00
|
|
|
string pub_key = 1;
|
2017-04-12 00:49:39 +03:00
|
|
|
}
|
|
|
|
message DisconnectPeerResponse {
|
2016-06-21 21:52:09 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
message HTLC {
|
2020-02-11 15:53:39 +03:00
|
|
|
bool incoming = 1;
|
|
|
|
int64 amount = 2;
|
|
|
|
bytes hash_lock = 3;
|
|
|
|
uint32 expiration_height = 4;
|
2020-10-14 17:50:24 +03:00
|
|
|
|
|
|
|
// Index identifying the htlc on the channel.
|
|
|
|
uint64 htlc_index = 5;
|
2020-10-14 18:44:18 +03:00
|
|
|
|
|
|
|
// 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.
|
|
|
|
uint64 forwarding_channel = 6;
|
|
|
|
|
|
|
|
// Index identifying the htlc on the forwarding channel.
|
|
|
|
uint64 forwarding_htlc_index = 7;
|
2016-06-21 21:52:09 +03:00
|
|
|
}
|
|
|
|
|
2020-03-04 15:21:28 +03:00
|
|
|
enum CommitmentType {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-03-04 15:21:28 +03:00
|
|
|
A channel using the legacy commitment format having tweaked to_remote
|
|
|
|
keys.
|
|
|
|
*/
|
|
|
|
LEGACY = 0;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-03-04 15:21:28 +03:00
|
|
|
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.
|
|
|
|
*/
|
|
|
|
STATIC_REMOTE_KEY = 1;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-03-04 15:21:28 +03:00
|
|
|
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.
|
|
|
|
*/
|
|
|
|
ANCHORS = 2;
|
2020-03-30 21:36:38 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-03-30 21:36:38 +03:00
|
|
|
Returned when the commitment type isn't known or unavailable.
|
|
|
|
*/
|
|
|
|
UNKNOWN_COMMITMENT_TYPE = 999;
|
2020-03-04 15:21:28 +03:00
|
|
|
}
|
|
|
|
|
2020-06-10 15:21:13 +03:00
|
|
|
message ChannelConstraints {
|
|
|
|
/*
|
|
|
|
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.
|
|
|
|
*/
|
|
|
|
uint32 csv_delay = 1;
|
|
|
|
|
|
|
|
// The minimum satoshis this node is required to reserve in its balance.
|
|
|
|
uint64 chan_reserve_sat = 2;
|
|
|
|
|
|
|
|
// The dust limit (in satoshis) of the initiator's commitment tx.
|
|
|
|
uint64 dust_limit_sat = 3;
|
|
|
|
|
|
|
|
// The maximum amount of coins in millisatoshis that can be pending in this
|
|
|
|
// channel.
|
|
|
|
uint64 max_pending_amt_msat = 4;
|
|
|
|
|
|
|
|
// The smallest HTLC in millisatoshis that the initiator will accept.
|
|
|
|
uint64 min_htlc_msat = 5;
|
|
|
|
|
|
|
|
// The total number of incoming HTLC's that the initiator will accept.
|
|
|
|
uint32 max_accepted_htlcs = 6;
|
|
|
|
}
|
|
|
|
|
2018-03-13 22:11:09 +03:00
|
|
|
message Channel {
|
2020-05-06 17:51:14 +03:00
|
|
|
// Whether this channel is active or not
|
2020-02-11 15:53:39 +03:00
|
|
|
bool active = 1;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The identity pubkey of the remote node
|
2020-02-11 15:53:39 +03:00
|
|
|
string remote_pubkey = 2;
|
2017-07-28 02:39:49 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2017-07-28 02:39:49 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
string channel_point = 3;
|
2017-07-28 02:39:49 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2017-07-28 02:39:49 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 chan_id = 4 [jstype = JS_STRING];
|
2016-06-21 21:52:09 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The total amount of funds held in this channel
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 capacity = 5;
|
2017-07-28 02:39:49 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// This node's current balance in this channel
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 local_balance = 6;
|
2017-07-28 02:39:49 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The counterparty's current balance in this channel
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 remote_balance = 7;
|
2016-06-21 21:52:09 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2017-07-28 02:39:49 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 commit_fee = 8;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The weight of the commitment transaction
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 commit_weight = 9;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2017-07-28 02:39:49 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 fee_per_kw = 10;
|
2016-06-21 21:52:09 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The unsettled balance in this channel
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 unsettled_balance = 11;
|
2017-07-28 02:39:49 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2017-07-28 02:39:49 +03:00
|
|
|
The total number of satoshis we've sent within this channel.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 total_satoshis_sent = 12;
|
2017-07-28 02:39:49 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2017-07-28 02:39:49 +03:00
|
|
|
The total number of satoshis we've received within this channel.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 total_satoshis_received = 13;
|
2017-07-28 02:39:49 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2017-07-28 02:39:49 +03:00
|
|
|
The total number of updates conducted within this channel.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 num_updates = 14;
|
2017-05-17 05:13:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2017-07-28 02:39:49 +03:00
|
|
|
The list of active, uncleared HTLCs currently pending within the channel.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
repeated HTLC pending_htlcs = 15;
|
2017-12-06 04:27:30 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-06-10 15:21:13 +03:00
|
|
|
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.
|
2017-12-06 04:27:30 +03:00
|
|
|
*/
|
2020-06-10 15:21:13 +03:00
|
|
|
uint32 csv_delay = 16 [deprecated = true];
|
2018-03-13 22:11:09 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Whether this channel is advertised to the network or not.
|
2020-02-11 15:53:39 +03:00
|
|
|
bool private = 17;
|
2019-01-15 04:26:22 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// True if we were the ones that created the channel.
|
2020-02-11 15:53:39 +03:00
|
|
|
bool initiator = 18;
|
2018-12-10 06:57:57 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// A set of flags showing the current state of the channel.
|
2020-02-11 15:53:39 +03:00
|
|
|
string chan_status_flags = 19;
|
2019-06-23 13:06:09 +03:00
|
|
|
|
2020-06-10 15:21:13 +03:00
|
|
|
// Deprecated. The minimum satoshis this node is required to reserve in its
|
|
|
|
// balance.
|
|
|
|
int64 local_chan_reserve_sat = 20 [deprecated = true];
|
2019-06-23 13:06:09 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-06-10 15:21:13 +03:00
|
|
|
Deprecated. The minimum satoshis the other node is required to reserve in
|
|
|
|
its balance.
|
2019-06-23 13:06:09 +03:00
|
|
|
*/
|
2020-06-10 15:21:13 +03:00
|
|
|
int64 remote_chan_reserve_sat = 21 [deprecated = true];
|
2019-09-11 15:45:27 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Deprecated. Use commitment_type.
|
2020-03-04 15:21:28 +03:00
|
|
|
bool static_remote_key = 22 [deprecated = true];
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The commitment type used by this channel.
|
2020-03-04 15:21:28 +03:00
|
|
|
CommitmentType commitment_type = 26;
|
2019-10-10 16:51:09 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-10-10 16:51:09 +03:00
|
|
|
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].
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 lifetime = 23;
|
2019-10-10 16:51:09 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-10-10 16:51:09 +03:00
|
|
|
The number of seconds that the remote peer has been observed as being online
|
2020-03-02 17:35:25 +03:00
|
|
|
by the channel scoring system over the lifetime of the channel
|
|
|
|
[EXPERIMENTAL].
|
2019-10-10 16:51:09 +03:00
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 uptime = 24;
|
2019-12-16 08:38:08 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-12-16 08:38:08 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
string close_address = 25;
|
2020-03-18 11:52:43 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
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.
|
|
|
|
*/
|
|
|
|
uint64 push_amount_sat = 27;
|
2020-03-14 02:49:40 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-03-14 02:49:40 +03:00
|
|
|
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
|
2020-07-02 03:45:59 +03:00
|
|
|
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.
|
2020-03-14 02:49:40 +03:00
|
|
|
*/
|
|
|
|
uint32 thaw_height = 28;
|
2020-06-10 15:21:13 +03:00
|
|
|
|
|
|
|
// List constraints for the local node.
|
|
|
|
ChannelConstraints local_constraints = 29;
|
|
|
|
|
|
|
|
// List constraints for the remote node.
|
|
|
|
ChannelConstraints remote_constraints = 30;
|
2016-06-21 21:52:09 +03:00
|
|
|
}
|
|
|
|
|
2017-04-12 00:49:39 +03:00
|
|
|
message ListChannelsRequest {
|
2018-03-13 22:11:09 +03:00
|
|
|
bool active_only = 1;
|
|
|
|
bool inactive_only = 2;
|
|
|
|
bool public_only = 3;
|
|
|
|
bool private_only = 4;
|
2020-03-03 16:11:33 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-03-03 16:11:33 +03:00
|
|
|
Filters the response for channels with a target peer's pubkey. If peer is
|
|
|
|
empty, all channels will be returned.
|
|
|
|
*/
|
|
|
|
bytes peer = 5;
|
2017-04-12 00:49:39 +03:00
|
|
|
}
|
2016-09-26 06:02:33 +03:00
|
|
|
message ListChannelsResponse {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The list of active channels
|
2020-02-11 15:53:39 +03:00
|
|
|
repeated Channel channels = 11;
|
2016-09-26 06:02:33 +03:00
|
|
|
}
|
|
|
|
|
2020-04-03 10:09:39 +03:00
|
|
|
enum Initiator {
|
|
|
|
INITIATOR_UNKNOWN = 0;
|
|
|
|
INITIATOR_LOCAL = 1;
|
|
|
|
INITIATOR_REMOTE = 2;
|
|
|
|
INITIATOR_BOTH = 3;
|
|
|
|
}
|
|
|
|
|
2018-05-24 12:36:35 +03:00
|
|
|
message ChannelCloseSummary {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The outpoint (txid:index) of the funding transaction.
|
2020-02-11 15:53:39 +03:00
|
|
|
string channel_point = 1;
|
2018-05-24 12:36:35 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The unique channel ID for the channel.
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 chan_id = 2 [jstype = JS_STRING];
|
2018-05-24 12:36:35 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The hash of the genesis block that this channel resides within.
|
2020-02-11 15:53:39 +03:00
|
|
|
string chain_hash = 3;
|
2018-05-24 12:36:35 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The txid of the transaction which ultimately closed this channel.
|
2020-02-11 15:53:39 +03:00
|
|
|
string closing_tx_hash = 4;
|
2018-05-24 12:36:35 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Public key of the remote peer that we formerly had a channel with.
|
2020-02-11 15:53:39 +03:00
|
|
|
string remote_pubkey = 5;
|
2018-05-24 12:36:35 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Total capacity of the channel.
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 capacity = 6;
|
2018-05-24 12:36:35 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Height at which the funding transaction was spent.
|
2020-02-11 15:53:39 +03:00
|
|
|
uint32 close_height = 7;
|
2018-05-24 12:36:35 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Settled balance at the time of channel closure
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 settled_balance = 8;
|
2018-05-24 12:36:35 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The sum of all the time-locked outputs at the time of channel closure
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 time_locked_balance = 9;
|
2018-05-24 12:36:35 +03:00
|
|
|
|
|
|
|
enum ClosureType {
|
|
|
|
COOPERATIVE_CLOSE = 0;
|
|
|
|
LOCAL_FORCE_CLOSE = 1;
|
|
|
|
REMOTE_FORCE_CLOSE = 2;
|
|
|
|
BREACH_CLOSE = 3;
|
|
|
|
FUNDING_CANCELED = 4;
|
2018-05-29 12:26:47 +03:00
|
|
|
ABANDONED = 5;
|
2018-05-24 12:36:35 +03:00
|
|
|
}
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Details on how the channel was closed.
|
2020-02-11 15:53:39 +03:00
|
|
|
ClosureType close_type = 10;
|
2020-02-21 14:24:24 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-02-21 14:24:24 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
Initiator open_initiator = 11;
|
2020-02-21 14:24:24 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-02-21 14:24:24 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
Initiator close_initiator = 12;
|
2020-07-07 11:32:12 +03:00
|
|
|
|
|
|
|
repeated Resolution resolutions = 13;
|
|
|
|
}
|
|
|
|
|
2020-07-14 13:30:46 +03:00
|
|
|
enum ResolutionType {
|
2020-07-07 11:32:12 +03:00
|
|
|
TYPE_UNKNOWN = 0;
|
|
|
|
|
|
|
|
// We resolved an anchor output.
|
|
|
|
ANCHOR = 1;
|
|
|
|
|
|
|
|
/*
|
|
|
|
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.
|
|
|
|
*/
|
|
|
|
INCOMING_HTLC = 2;
|
|
|
|
|
|
|
|
/*
|
|
|
|
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.
|
|
|
|
*/
|
|
|
|
OUTGOING_HTLC = 3;
|
|
|
|
|
|
|
|
// We force closed and need to sweep our time locked commitment output.
|
|
|
|
COMMIT = 4;
|
|
|
|
}
|
|
|
|
|
|
|
|
enum ResolutionOutcome {
|
|
|
|
// Outcome unknown.
|
|
|
|
OUTCOME_UNKNOWN = 0;
|
|
|
|
|
|
|
|
// An output was claimed on chain.
|
|
|
|
CLAIMED = 1;
|
|
|
|
|
|
|
|
// An output was left unclaimed on chain.
|
|
|
|
UNCLAIMED = 2;
|
|
|
|
|
|
|
|
/*
|
|
|
|
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.
|
|
|
|
*/
|
|
|
|
ABANDONED = 3;
|
|
|
|
|
|
|
|
/*
|
|
|
|
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.
|
|
|
|
*/
|
|
|
|
FIRST_STAGE = 4;
|
|
|
|
|
|
|
|
// A htlc was timed out on chain.
|
|
|
|
TIMEOUT = 5;
|
|
|
|
}
|
|
|
|
|
|
|
|
message Resolution {
|
|
|
|
// The type of output we are resolving.
|
|
|
|
ResolutionType resolution_type = 1;
|
|
|
|
|
|
|
|
// The outcome of our on chain action that resolved the outpoint.
|
|
|
|
ResolutionOutcome outcome = 2;
|
|
|
|
|
|
|
|
// The outpoint that was spent by the resolution.
|
|
|
|
OutPoint outpoint = 3;
|
|
|
|
|
|
|
|
// The amount that was claimed by the resolution.
|
|
|
|
uint64 amount_sat = 4;
|
|
|
|
|
|
|
|
// The hex-encoded transaction ID of the sweep transaction that spent the
|
|
|
|
// output.
|
|
|
|
string sweep_txid = 5;
|
2018-05-24 12:36:35 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
message ClosedChannelsRequest {
|
|
|
|
bool cooperative = 1;
|
|
|
|
bool local_force = 2;
|
|
|
|
bool remote_force = 3;
|
|
|
|
bool breach = 4;
|
|
|
|
bool funding_canceled = 5;
|
2018-05-29 12:26:47 +03:00
|
|
|
bool abandoned = 6;
|
2018-05-24 12:36:35 +03:00
|
|
|
}
|
|
|
|
|
2020-02-11 15:53:39 +03:00
|
|
|
message ClosedChannelsResponse {
|
|
|
|
repeated ChannelCloseSummary channels = 1;
|
2018-05-24 12:36:35 +03:00
|
|
|
}
|
|
|
|
|
2016-06-21 21:52:09 +03:00
|
|
|
message Peer {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The identity pubkey of the peer
|
2020-02-11 15:53:39 +03:00
|
|
|
string pub_key = 1;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Network address of the peer; eg `127.0.0.1:10011`
|
2020-02-11 15:53:39 +03:00
|
|
|
string address = 3;
|
2016-06-21 21:52:09 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Bytes of data transmitted to this peer
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 bytes_sent = 4;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Bytes of data transmitted from this peer
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 bytes_recv = 5;
|
2016-06-21 21:52:09 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Satoshis sent to this peer
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 sat_sent = 6;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Satoshis received from this peer
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 sat_recv = 7;
|
2016-06-21 21:52:09 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// A channel is inbound if the counterparty initiated the channel
|
2020-02-11 15:53:39 +03:00
|
|
|
bool inbound = 8;
|
2017-01-26 05:16:28 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Ping time to this peer
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 ping_time = 9;
|
2019-03-23 05:57:03 +03:00
|
|
|
|
|
|
|
enum SyncType {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-03-23 05:57:03 +03:00
|
|
|
Denotes that we cannot determine the peer's current sync type.
|
|
|
|
*/
|
|
|
|
UNKNOWN_SYNC = 0;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-03-23 05:57:03 +03:00
|
|
|
Denotes that we are actively receiving new graph updates from the peer.
|
|
|
|
*/
|
|
|
|
ACTIVE_SYNC = 1;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-03-23 05:57:03 +03:00
|
|
|
Denotes that we are not receiving new graph updates from the peer.
|
|
|
|
*/
|
|
|
|
PASSIVE_SYNC = 2;
|
2021-01-29 11:14:07 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
Denotes that this peer is pinned into an active sync.
|
|
|
|
*/
|
|
|
|
PINNED_SYNC = 3;
|
2019-03-23 05:57:03 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
// The type of sync we are currently performing with this peer.
|
2020-02-11 15:53:39 +03:00
|
|
|
SyncType sync_type = 10;
|
2019-12-14 18:05:07 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Features advertised by the remote peer in their init message.
|
2020-02-11 15:53:39 +03:00
|
|
|
map<uint32, Feature> features = 11;
|
2020-03-13 10:15:49 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
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.
|
|
|
|
*/
|
|
|
|
repeated TimestampedError errors = 12;
|
2020-08-27 10:20:46 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
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.
|
|
|
|
*/
|
|
|
|
int32 flap_count = 13;
|
|
|
|
|
|
|
|
/*
|
|
|
|
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.
|
|
|
|
*/
|
|
|
|
int64 last_flap_ns = 14;
|
2020-03-13 10:15:49 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
message TimestampedError {
|
|
|
|
// The unix timestamp in seconds when the error occurred.
|
|
|
|
uint64 timestamp = 1;
|
|
|
|
|
|
|
|
// The string representation of the error sent by our peer.
|
|
|
|
string error = 2;
|
2016-06-21 21:52:09 +03:00
|
|
|
}
|
|
|
|
|
2017-04-12 00:49:39 +03:00
|
|
|
message ListPeersRequest {
|
2020-03-13 10:15:49 +03:00
|
|
|
/*
|
|
|
|
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.
|
|
|
|
*/
|
|
|
|
bool latest_error = 1;
|
2017-04-12 00:49:39 +03:00
|
|
|
}
|
2016-06-21 21:52:09 +03:00
|
|
|
message ListPeersResponse {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The list of currently connected peers
|
2020-02-11 15:53:39 +03:00
|
|
|
repeated Peer peers = 1;
|
2016-06-21 21:52:09 +03:00
|
|
|
}
|
2016-06-21 22:32:32 +03:00
|
|
|
|
2019-08-12 20:13:12 +03:00
|
|
|
message PeerEventSubscription {
|
|
|
|
}
|
|
|
|
|
|
|
|
message PeerEvent {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The identity pubkey of the peer.
|
2020-02-11 15:53:39 +03:00
|
|
|
string pub_key = 1;
|
2019-08-12 20:13:12 +03:00
|
|
|
|
|
|
|
enum EventType {
|
|
|
|
PEER_ONLINE = 0;
|
|
|
|
PEER_OFFLINE = 1;
|
|
|
|
}
|
|
|
|
|
2020-02-11 15:53:39 +03:00
|
|
|
EventType type = 2;
|
2019-08-12 20:13:12 +03:00
|
|
|
}
|
|
|
|
|
2017-04-12 00:49:39 +03:00
|
|
|
message GetInfoRequest {
|
|
|
|
}
|
2016-07-06 04:52:05 +03:00
|
|
|
message GetInfoResponse {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The version of the LND software that the node is running.
|
2020-02-11 15:53:39 +03:00
|
|
|
string version = 14;
|
2019-12-20 12:05:27 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The SHA1 commit hash that the daemon is compiled with.
|
2020-04-10 03:06:37 +03:00
|
|
|
string commit_hash = 20;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The identity pubkey of the current node.
|
2020-02-11 15:53:39 +03:00
|
|
|
string identity_pubkey = 1;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// If applicable, the alias of the current node, e.g. "bob"
|
2020-02-11 15:53:39 +03:00
|
|
|
string alias = 2;
|
2016-07-06 04:52:05 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The color of the current node in hex code format
|
2020-02-11 15:53:39 +03:00
|
|
|
string color = 17;
|
2019-12-20 12:05:27 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Number of pending channels
|
2020-02-11 15:53:39 +03:00
|
|
|
uint32 num_pending_channels = 3;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Number of active channels
|
2020-02-11 15:53:39 +03:00
|
|
|
uint32 num_active_channels = 4;
|
2016-07-06 04:52:05 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Number of inactive channels
|
2020-02-11 15:53:39 +03:00
|
|
|
uint32 num_inactive_channels = 15;
|
2019-12-20 12:05:27 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Number of peers
|
2020-02-11 15:53:39 +03:00
|
|
|
uint32 num_peers = 5;
|
2016-11-15 02:54:47 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The node's current view of the height of the best block
|
2020-02-11 15:53:39 +03:00
|
|
|
uint32 block_height = 6;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The node's current view of the hash of the best block
|
2020-02-11 15:53:39 +03:00
|
|
|
string block_hash = 8;
|
2016-12-13 02:34:20 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Timestamp of the block best known to the wallet
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 best_header_timestamp = 13;
|
2019-12-20 12:05:27 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Whether the wallet's view is synced to the main chain
|
2020-02-11 15:53:39 +03:00
|
|
|
bool synced_to_chain = 9;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2019-12-20 12:05:27 +03:00
|
|
|
// Whether we consider ourselves synced with the public channel graph.
|
2020-02-11 15:53:39 +03:00
|
|
|
bool synced_to_graph = 18;
|
2019-12-20 12:05:27 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-03-02 17:35:25 +03:00
|
|
|
Whether the current node is connected to testnet. This field is
|
|
|
|
deprecated and the network field should be used instead
|
2019-01-02 18:10:12 +03:00
|
|
|
**/
|
2020-02-11 15:53:39 +03:00
|
|
|
bool testnet = 10 [deprecated = true];
|
2017-05-03 05:49:41 +03:00
|
|
|
|
2019-01-02 18:10:12 +03:00
|
|
|
reserved 11;
|
2018-01-07 08:50:30 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// A list of active chains the node is connected to
|
2020-02-11 15:53:39 +03:00
|
|
|
repeated Chain chains = 16;
|
2018-12-21 19:29:24 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The URIs of the current node.
|
2020-02-11 15:53:39 +03:00
|
|
|
repeated string uris = 12;
|
2019-12-17 22:58:28 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
Features that our node has advertised in our init message, node
|
|
|
|
announcements and invoices.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
map<uint32, Feature> features = 19;
|
2019-01-02 18:10:12 +03:00
|
|
|
}
|
|
|
|
|
2020-06-09 09:47:17 +03:00
|
|
|
message GetRecoveryInfoRequest {
|
|
|
|
}
|
|
|
|
message GetRecoveryInfoResponse {
|
|
|
|
// Whether the wallet is in recovery mode
|
|
|
|
bool recovery_mode = 1;
|
|
|
|
|
|
|
|
// Whether the wallet recovery progress is finished
|
|
|
|
bool recovery_finished = 2;
|
|
|
|
|
|
|
|
// The recovery progress, ranging from 0 to 1.
|
|
|
|
double progress = 3;
|
|
|
|
}
|
|
|
|
|
2019-01-02 18:10:12 +03:00
|
|
|
message Chain {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The blockchain the node is on (eg bitcoin, litecoin)
|
2020-02-11 15:53:39 +03:00
|
|
|
string chain = 1;
|
2019-01-02 18:10:12 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The network the node is on (eg regtest, testnet, mainnet)
|
2020-02-11 15:53:39 +03:00
|
|
|
string network = 2;
|
2016-07-06 04:52:05 +03:00
|
|
|
}
|
|
|
|
|
2016-07-08 01:23:29 +03:00
|
|
|
message ConfirmationUpdate {
|
|
|
|
bytes block_sha = 1;
|
|
|
|
int32 block_height = 2;
|
|
|
|
|
|
|
|
uint32 num_confs_left = 3;
|
|
|
|
}
|
|
|
|
|
|
|
|
message ChannelOpenUpdate {
|
2020-02-11 15:53:39 +03:00
|
|
|
ChannelPoint channel_point = 1;
|
2016-07-08 01:23:29 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
message ChannelCloseUpdate {
|
2020-02-11 15:53:39 +03:00
|
|
|
bytes closing_txid = 1;
|
2016-07-08 01:23:29 +03:00
|
|
|
|
2020-02-11 15:53:39 +03:00
|
|
|
bool success = 2;
|
2016-07-08 01:23:29 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
message CloseChannelRequest {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2017-07-28 02:39:49 +03:00
|
|
|
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.
|
|
|
|
*/
|
2016-07-08 01:23:29 +03:00
|
|
|
ChannelPoint channel_point = 1;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// If true, then the channel will be closed forcibly. This means the
|
|
|
|
// current commitment transaction will be signed and broadcast.
|
2017-08-22 10:07:25 +03:00
|
|
|
bool force = 2;
|
2017-11-23 08:36:27 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The target number of blocks that the closure transaction should be
|
|
|
|
// confirmed by.
|
2017-11-23 08:36:27 +03:00
|
|
|
int32 target_conf = 3;
|
|
|
|
|
2021-03-11 03:29:50 +03:00
|
|
|
// Deprecated, use sat_per_vbyte.
|
2020-10-20 05:22:36 +03:00
|
|
|
// A manual fee rate set in sat/vbyte that should be used when crafting the
|
2020-05-06 17:51:14 +03:00
|
|
|
// closure transaction.
|
2021-03-11 03:29:50 +03:00
|
|
|
int64 sat_per_byte = 4 [deprecated = true];
|
2019-12-09 16:43:59 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
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.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
string delivery_address = 5;
|
2021-03-11 03:29:50 +03:00
|
|
|
|
|
|
|
// A manual fee rate set in sat/vbyte that should be used when crafting the
|
|
|
|
// closure transaction.
|
|
|
|
uint64 sat_per_vbyte = 6;
|
2016-07-08 01:23:29 +03:00
|
|
|
}
|
2018-01-11 07:17:18 +03:00
|
|
|
|
2016-07-08 01:23:29 +03:00
|
|
|
message CloseStatusUpdate {
|
|
|
|
oneof update {
|
2020-02-11 15:53:39 +03:00
|
|
|
PendingUpdate close_pending = 1;
|
|
|
|
ChannelCloseUpdate chan_close = 3;
|
2016-07-08 01:23:29 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-08-31 02:42:23 +03:00
|
|
|
message PendingUpdate {
|
2020-02-11 15:53:39 +03:00
|
|
|
bytes txid = 1;
|
|
|
|
uint32 output_index = 2;
|
2016-08-31 02:42:23 +03:00
|
|
|
}
|
|
|
|
|
2020-03-31 10:13:13 +03:00
|
|
|
message ReadyForPsbtFunding {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-03-31 10:13:13 +03:00
|
|
|
The P2WSH address of the channel funding multisig address that the below
|
|
|
|
specified amount in satoshis needs to be sent to.
|
|
|
|
*/
|
|
|
|
string funding_address = 1;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-03-31 10:13:13 +03:00
|
|
|
The exact amount in satoshis that needs to be sent to the above address to
|
|
|
|
fund the pending channel.
|
|
|
|
*/
|
|
|
|
int64 funding_amount = 2;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-03-31 10:13:13 +03:00
|
|
|
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.
|
|
|
|
*/
|
|
|
|
bytes psbt = 3;
|
|
|
|
}
|
|
|
|
|
2016-06-21 22:32:32 +03:00
|
|
|
message OpenChannelRequest {
|
2021-03-11 03:29:50 +03:00
|
|
|
// A manual fee rate set in sat/vbyte that should be used when crafting the
|
|
|
|
// funding transaction.
|
|
|
|
uint64 sat_per_vbyte = 1;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-01 11:45:02 +03:00
|
|
|
The pubkey of the node to open a channel with. When using REST, this field
|
|
|
|
must be encoded as base64.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
bytes node_pubkey = 2;
|
2017-07-28 02:39:49 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-01 11:45:02 +03:00
|
|
|
The hex encoded pubkey of the node to open a channel with. Deprecated now
|
|
|
|
that the REST gateway supports base64 encoding of bytes fields.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
string node_pubkey_string = 3 [deprecated = true];
|
2016-11-11 04:33:24 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The number of satoshis the wallet should commit to the channel
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 local_funding_amount = 4;
|
2017-07-28 02:39:49 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The number of satoshis to push to the remote side as part of the initial
|
|
|
|
// commitment state
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 push_sat = 5;
|
2017-11-23 08:36:27 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The target number of blocks that the funding transaction should be
|
|
|
|
// confirmed by.
|
2017-11-23 08:36:27 +03:00
|
|
|
int32 target_conf = 6;
|
|
|
|
|
2021-03-11 03:29:50 +03:00
|
|
|
// Deprecated, use sat_per_vbyte.
|
2020-10-20 05:22:36 +03:00
|
|
|
// A manual fee rate set in sat/vbyte that should be used when crafting the
|
2020-05-06 17:51:14 +03:00
|
|
|
// funding transaction.
|
2021-03-11 03:29:50 +03:00
|
|
|
int64 sat_per_byte = 7 [deprecated = true];
|
2017-11-14 02:47:33 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Whether this channel should be private, not announced to the greater
|
|
|
|
// network.
|
2020-02-11 15:53:39 +03:00
|
|
|
bool private = 8;
|
2017-12-17 01:58:08 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The minimum value in millisatoshi we will require for incoming HTLCs on
|
|
|
|
// the channel.
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 min_htlc_msat = 9;
|
2018-03-14 16:12:24 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The delay we require on the remote's commitment transaction. If this is
|
|
|
|
// not set, it will be scaled automatically with the channel size.
|
2020-02-11 15:53:39 +03:00
|
|
|
uint32 remote_csv_delay = 10;
|
2018-08-10 05:37:32 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The minimum number of confirmations each one of your outputs used for
|
|
|
|
// the funding transaction must satisfy.
|
2020-02-11 15:53:39 +03:00
|
|
|
int32 min_confs = 11;
|
2018-10-17 02:44:26 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Whether unconfirmed outputs should be used as inputs for the funding
|
|
|
|
// transaction.
|
2020-02-11 15:53:39 +03:00
|
|
|
bool spend_unconfirmed = 12;
|
2019-12-17 22:58:28 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
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.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
string close_address = 13;
|
lnrpc: add ability to provide chan point shims for funding, new funding modifiers
In this commit, we start to expose some of the new external funding
functionality over the RPC interface.
First, we add a new `funding_shim` field to the regular `OpenChannel`
method. This can be used by a caller to express that certain parameters
of the funding flow have already been negotiated outside the protocol,
and should be used instead. For example, a shim can be provided to use a
particular key for the commitment key (ideally cold) rather than use one
this is generated by the wallet as normal, or signal that signing will
be carried out in an interactive manner (PSBT based).
Next, we add a brand new method: `FundingStateStep`. 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 new transition methods (funding state machine modifiers) in this
commit allow a party to register a funding intent that should be used
for a specified incoming pending channel ID. The "responder" to the
external channel flow should use this to prep lnd to be able to handle
the channel flow properly.
2019-11-14 07:54:34 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
lnrpc: add ability to provide chan point shims for funding, new funding modifiers
In this commit, we start to expose some of the new external funding
functionality over the RPC interface.
First, we add a new `funding_shim` field to the regular `OpenChannel`
method. This can be used by a caller to express that certain parameters
of the funding flow have already been negotiated outside the protocol,
and should be used instead. For example, a shim can be provided to use a
particular key for the commitment key (ideally cold) rather than use one
this is generated by the wallet as normal, or signal that signing will
be carried out in an interactive manner (PSBT based).
Next, we add a brand new method: `FundingStateStep`. 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 new transition methods (funding state machine modifiers) in this
commit allow a party to register a funding intent that should be used
for a specified incoming pending channel ID. The "responder" to the
external channel flow should use this to prep lnd to be able to handle
the channel flow properly.
2019-11-14 07:54:34 +03:00
|
|
|
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).
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
FundingShim funding_shim = 14;
|
2018-08-30 00:43:13 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
The maximum amount of coins in millisatoshi that can be pending within
|
|
|
|
the channel. It only applies to the remote party.
|
|
|
|
*/
|
|
|
|
uint64 remote_max_value_in_flight_msat = 15;
|
2020-08-13 01:46:08 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
The maximum number of concurrent HTLCs we will allow the remote party to add
|
|
|
|
to the commitment transaction.
|
|
|
|
*/
|
|
|
|
uint32 remote_max_htlcs = 16;
|
2020-10-29 12:48:43 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
Max local csv is the maximum csv delay we will allow for our own commitment
|
|
|
|
transaction.
|
|
|
|
*/
|
|
|
|
uint32 max_local_csv = 17;
|
2016-06-21 22:32:32 +03:00
|
|
|
}
|
2016-07-08 01:23:29 +03:00
|
|
|
message OpenStatusUpdate {
|
|
|
|
oneof update {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-03-31 10:13:13 +03:00
|
|
|
Signals that the channel is now fully negotiated and the funding
|
|
|
|
transaction published.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
PendingUpdate chan_pending = 1;
|
2020-03-31 10:13:13 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-03-31 10:13:13 +03:00
|
|
|
Signals that the channel's funding transaction has now reached the
|
|
|
|
required number of confirmations on chain and can be used.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
ChannelOpenUpdate chan_open = 3;
|
2020-03-31 10:13:13 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-03-31 10:13:13 +03:00
|
|
|
Signals that the funding process has been suspended and the construction
|
|
|
|
of a PSBT that funds the channel PK script is now required.
|
|
|
|
*/
|
|
|
|
ReadyForPsbtFunding psbt_fund = 5;
|
2020-02-11 15:53:39 +03:00
|
|
|
}
|
lnrpc: add ability to provide chan point shims for funding, new funding modifiers
In this commit, we start to expose some of the new external funding
functionality over the RPC interface.
First, we add a new `funding_shim` field to the regular `OpenChannel`
method. This can be used by a caller to express that certain parameters
of the funding flow have already been negotiated outside the protocol,
and should be used instead. For example, a shim can be provided to use a
particular key for the commitment key (ideally cold) rather than use one
this is generated by the wallet as normal, or signal that signing will
be carried out in an interactive manner (PSBT based).
Next, we add a brand new method: `FundingStateStep`. 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 new transition methods (funding state machine modifiers) in this
commit allow a party to register a funding intent that should be used
for a specified incoming pending channel ID. The "responder" to the
external channel flow should use this to prep lnd to be able to handle
the channel flow properly.
2019-11-14 07:54:34 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
lnrpc: add ability to provide chan point shims for funding, new funding modifiers
In this commit, we start to expose some of the new external funding
functionality over the RPC interface.
First, we add a new `funding_shim` field to the regular `OpenChannel`
method. This can be used by a caller to express that certain parameters
of the funding flow have already been negotiated outside the protocol,
and should be used instead. For example, a shim can be provided to use a
particular key for the commitment key (ideally cold) rather than use one
this is generated by the wallet as normal, or signal that signing will
be carried out in an interactive manner (PSBT based).
Next, we add a brand new method: `FundingStateStep`. 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 new transition methods (funding state machine modifiers) in this
commit allow a party to register a funding intent that should be used
for a specified incoming pending channel ID. The "responder" to the
external channel flow should use this to prep lnd to be able to handle
the channel flow properly.
2019-11-14 07:54:34 +03:00
|
|
|
The pending channel ID of the created channel. This value may be used to
|
|
|
|
further the funding flow manually via the FundingStateStep method.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
bytes pending_chan_id = 4;
|
lnrpc: add ability to provide chan point shims for funding, new funding modifiers
In this commit, we start to expose some of the new external funding
functionality over the RPC interface.
First, we add a new `funding_shim` field to the regular `OpenChannel`
method. This can be used by a caller to express that certain parameters
of the funding flow have already been negotiated outside the protocol,
and should be used instead. For example, a shim can be provided to use a
particular key for the commitment key (ideally cold) rather than use one
this is generated by the wallet as normal, or signal that signing will
be carried out in an interactive manner (PSBT based).
Next, we add a brand new method: `FundingStateStep`. 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 new transition methods (funding state machine modifiers) in this
commit allow a party to register a funding intent that should be used
for a specified incoming pending channel ID. The "responder" to the
external channel flow should use this to prep lnd to be able to handle
the channel flow properly.
2019-11-14 07:54:34 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
message KeyLocator {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The family of key being identified.
|
lnrpc: add ability to provide chan point shims for funding, new funding modifiers
In this commit, we start to expose some of the new external funding
functionality over the RPC interface.
First, we add a new `funding_shim` field to the regular `OpenChannel`
method. This can be used by a caller to express that certain parameters
of the funding flow have already been negotiated outside the protocol,
and should be used instead. For example, a shim can be provided to use a
particular key for the commitment key (ideally cold) rather than use one
this is generated by the wallet as normal, or signal that signing will
be carried out in an interactive manner (PSBT based).
Next, we add a brand new method: `FundingStateStep`. 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 new transition methods (funding state machine modifiers) in this
commit allow a party to register a funding intent that should be used
for a specified incoming pending channel ID. The "responder" to the
external channel flow should use this to prep lnd to be able to handle
the channel flow properly.
2019-11-14 07:54:34 +03:00
|
|
|
int32 key_family = 1;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The precise index of the key being identified.
|
lnrpc: add ability to provide chan point shims for funding, new funding modifiers
In this commit, we start to expose some of the new external funding
functionality over the RPC interface.
First, we add a new `funding_shim` field to the regular `OpenChannel`
method. This can be used by a caller to express that certain parameters
of the funding flow have already been negotiated outside the protocol,
and should be used instead. For example, a shim can be provided to use a
particular key for the commitment key (ideally cold) rather than use one
this is generated by the wallet as normal, or signal that signing will
be carried out in an interactive manner (PSBT based).
Next, we add a brand new method: `FundingStateStep`. 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 new transition methods (funding state machine modifiers) in this
commit allow a party to register a funding intent that should be used
for a specified incoming pending channel ID. The "responder" to the
external channel flow should use this to prep lnd to be able to handle
the channel flow properly.
2019-11-14 07:54:34 +03:00
|
|
|
int32 key_index = 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
message KeyDescriptor {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-03-02 17:35:25 +03:00
|
|
|
The raw bytes of the key being identified.
|
2020-02-11 15:53:39 +03:00
|
|
|
*/
|
|
|
|
bytes raw_key_bytes = 1;
|
lnrpc: add ability to provide chan point shims for funding, new funding modifiers
In this commit, we start to expose some of the new external funding
functionality over the RPC interface.
First, we add a new `funding_shim` field to the regular `OpenChannel`
method. This can be used by a caller to express that certain parameters
of the funding flow have already been negotiated outside the protocol,
and should be used instead. For example, a shim can be provided to use a
particular key for the commitment key (ideally cold) rather than use one
this is generated by the wallet as normal, or signal that signing will
be carried out in an interactive manner (PSBT based).
Next, we add a brand new method: `FundingStateStep`. 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 new transition methods (funding state machine modifiers) in this
commit allow a party to register a funding intent that should be used
for a specified incoming pending channel ID. The "responder" to the
external channel flow should use this to prep lnd to be able to handle
the channel flow properly.
2019-11-14 07:54:34 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-03-02 17:35:25 +03:00
|
|
|
The key locator that identifies which key to use for signing.
|
2020-02-11 15:53:39 +03:00
|
|
|
*/
|
|
|
|
KeyLocator key_loc = 2;
|
lnrpc: add ability to provide chan point shims for funding, new funding modifiers
In this commit, we start to expose some of the new external funding
functionality over the RPC interface.
First, we add a new `funding_shim` field to the regular `OpenChannel`
method. This can be used by a caller to express that certain parameters
of the funding flow have already been negotiated outside the protocol,
and should be used instead. For example, a shim can be provided to use a
particular key for the commitment key (ideally cold) rather than use one
this is generated by the wallet as normal, or signal that signing will
be carried out in an interactive manner (PSBT based).
Next, we add a brand new method: `FundingStateStep`. 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 new transition methods (funding state machine modifiers) in this
commit allow a party to register a funding intent that should be used
for a specified incoming pending channel ID. The "responder" to the
external channel flow should use this to prep lnd to be able to handle
the channel flow properly.
2019-11-14 07:54:34 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
message ChanPointShim {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
lnrpc: add ability to provide chan point shims for funding, new funding modifiers
In this commit, we start to expose some of the new external funding
functionality over the RPC interface.
First, we add a new `funding_shim` field to the regular `OpenChannel`
method. This can be used by a caller to express that certain parameters
of the funding flow have already been negotiated outside the protocol,
and should be used instead. For example, a shim can be provided to use a
particular key for the commitment key (ideally cold) rather than use one
this is generated by the wallet as normal, or signal that signing will
be carried out in an interactive manner (PSBT based).
Next, we add a brand new method: `FundingStateStep`. 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 new transition methods (funding state machine modifiers) in this
commit allow a party to register a funding intent that should be used
for a specified incoming pending channel ID. The "responder" to the
external channel flow should use this to prep lnd to be able to handle
the channel flow properly.
2019-11-14 07:54:34 +03:00
|
|
|
The size of the pre-crafted output to be used as the channel point for this
|
|
|
|
channel funding.
|
|
|
|
*/
|
|
|
|
int64 amt = 1;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The target channel point to refrence in created commitment transactions.
|
lnrpc: add ability to provide chan point shims for funding, new funding modifiers
In this commit, we start to expose some of the new external funding
functionality over the RPC interface.
First, we add a new `funding_shim` field to the regular `OpenChannel`
method. This can be used by a caller to express that certain parameters
of the funding flow have already been negotiated outside the protocol,
and should be used instead. For example, a shim can be provided to use a
particular key for the commitment key (ideally cold) rather than use one
this is generated by the wallet as normal, or signal that signing will
be carried out in an interactive manner (PSBT based).
Next, we add a brand new method: `FundingStateStep`. 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 new transition methods (funding state machine modifiers) in this
commit allow a party to register a funding intent that should be used
for a specified incoming pending channel ID. The "responder" to the
external channel flow should use this to prep lnd to be able to handle
the channel flow properly.
2019-11-14 07:54:34 +03:00
|
|
|
ChannelPoint chan_point = 2;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Our local key to use when creating the multi-sig output.
|
lnrpc: add ability to provide chan point shims for funding, new funding modifiers
In this commit, we start to expose some of the new external funding
functionality over the RPC interface.
First, we add a new `funding_shim` field to the regular `OpenChannel`
method. This can be used by a caller to express that certain parameters
of the funding flow have already been negotiated outside the protocol,
and should be used instead. For example, a shim can be provided to use a
particular key for the commitment key (ideally cold) rather than use one
this is generated by the wallet as normal, or signal that signing will
be carried out in an interactive manner (PSBT based).
Next, we add a brand new method: `FundingStateStep`. 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 new transition methods (funding state machine modifiers) in this
commit allow a party to register a funding intent that should be used
for a specified incoming pending channel ID. The "responder" to the
external channel flow should use this to prep lnd to be able to handle
the channel flow properly.
2019-11-14 07:54:34 +03:00
|
|
|
KeyDescriptor local_key = 3;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The key of the remote party to use when creating the multi-sig output.
|
lnrpc: add ability to provide chan point shims for funding, new funding modifiers
In this commit, we start to expose some of the new external funding
functionality over the RPC interface.
First, we add a new `funding_shim` field to the regular `OpenChannel`
method. This can be used by a caller to express that certain parameters
of the funding flow have already been negotiated outside the protocol,
and should be used instead. For example, a shim can be provided to use a
particular key for the commitment key (ideally cold) rather than use one
this is generated by the wallet as normal, or signal that signing will
be carried out in an interactive manner (PSBT based).
Next, we add a brand new method: `FundingStateStep`. 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 new transition methods (funding state machine modifiers) in this
commit allow a party to register a funding intent that should be used
for a specified incoming pending channel ID. The "responder" to the
external channel flow should use this to prep lnd to be able to handle
the channel flow properly.
2019-11-14 07:54:34 +03:00
|
|
|
bytes remote_key = 4;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
lnrpc: add ability to provide chan point shims for funding, new funding modifiers
In this commit, we start to expose some of the new external funding
functionality over the RPC interface.
First, we add a new `funding_shim` field to the regular `OpenChannel`
method. This can be used by a caller to express that certain parameters
of the funding flow have already been negotiated outside the protocol,
and should be used instead. For example, a shim can be provided to use a
particular key for the commitment key (ideally cold) rather than use one
this is generated by the wallet as normal, or signal that signing will
be carried out in an interactive manner (PSBT based).
Next, we add a brand new method: `FundingStateStep`. 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 new transition methods (funding state machine modifiers) in this
commit allow a party to register a funding intent that should be used
for a specified incoming pending channel ID. The "responder" to the
external channel flow should use this to prep lnd to be able to handle
the channel flow properly.
2019-11-14 07:54:34 +03:00
|
|
|
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.
|
|
|
|
*/
|
|
|
|
bytes pending_chan_id = 5;
|
2020-03-14 02:49:40 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-07-02 03:45:59 +03:00
|
|
|
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.
|
2020-03-14 02:49:40 +03:00
|
|
|
*/
|
|
|
|
uint32 thaw_height = 6;
|
lnrpc: add ability to provide chan point shims for funding, new funding modifiers
In this commit, we start to expose some of the new external funding
functionality over the RPC interface.
First, we add a new `funding_shim` field to the regular `OpenChannel`
method. This can be used by a caller to express that certain parameters
of the funding flow have already been negotiated outside the protocol,
and should be used instead. For example, a shim can be provided to use a
particular key for the commitment key (ideally cold) rather than use one
this is generated by the wallet as normal, or signal that signing will
be carried out in an interactive manner (PSBT based).
Next, we add a brand new method: `FundingStateStep`. 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 new transition methods (funding state machine modifiers) in this
commit allow a party to register a funding intent that should be used
for a specified incoming pending channel ID. The "responder" to the
external channel flow should use this to prep lnd to be able to handle
the channel flow properly.
2019-11-14 07:54:34 +03:00
|
|
|
}
|
|
|
|
|
2020-03-31 10:13:13 +03:00
|
|
|
message PsbtShim {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-03-31 10:13:13 +03:00
|
|
|
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.
|
|
|
|
*/
|
|
|
|
bytes pending_chan_id = 1;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-03-31 10:13:13 +03:00
|
|
|
An optional base PSBT the new channel output will be added to. If this is
|
|
|
|
non-empty, it must be a binary serialized PSBT.
|
|
|
|
*/
|
|
|
|
bytes base_psbt = 2;
|
2020-07-09 03:12:41 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
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.
|
|
|
|
*/
|
|
|
|
bool no_publish = 3;
|
2020-03-31 10:13:13 +03:00
|
|
|
}
|
|
|
|
|
lnrpc: add ability to provide chan point shims for funding, new funding modifiers
In this commit, we start to expose some of the new external funding
functionality over the RPC interface.
First, we add a new `funding_shim` field to the regular `OpenChannel`
method. This can be used by a caller to express that certain parameters
of the funding flow have already been negotiated outside the protocol,
and should be used instead. For example, a shim can be provided to use a
particular key for the commitment key (ideally cold) rather than use one
this is generated by the wallet as normal, or signal that signing will
be carried out in an interactive manner (PSBT based).
Next, we add a brand new method: `FundingStateStep`. 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 new transition methods (funding state machine modifiers) in this
commit allow a party to register a funding intent that should be used
for a specified incoming pending channel ID. The "responder" to the
external channel flow should use this to prep lnd to be able to handle
the channel flow properly.
2019-11-14 07:54:34 +03:00
|
|
|
message FundingShim {
|
|
|
|
oneof shim {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-03-31 10:13:13 +03:00
|
|
|
A channel shim where the channel point was fully constructed outside
|
|
|
|
of lnd's wallet and the transaction might already be published.
|
|
|
|
*/
|
lnrpc: add ability to provide chan point shims for funding, new funding modifiers
In this commit, we start to expose some of the new external funding
functionality over the RPC interface.
First, we add a new `funding_shim` field to the regular `OpenChannel`
method. This can be used by a caller to express that certain parameters
of the funding flow have already been negotiated outside the protocol,
and should be used instead. For example, a shim can be provided to use a
particular key for the commitment key (ideally cold) rather than use one
this is generated by the wallet as normal, or signal that signing will
be carried out in an interactive manner (PSBT based).
Next, we add a brand new method: `FundingStateStep`. 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 new transition methods (funding state machine modifiers) in this
commit allow a party to register a funding intent that should be used
for a specified incoming pending channel ID. The "responder" to the
external channel flow should use this to prep lnd to be able to handle
the channel flow properly.
2019-11-14 07:54:34 +03:00
|
|
|
ChanPointShim chan_point_shim = 1;
|
2020-03-31 10:13:13 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-03-31 10:13:13 +03:00
|
|
|
A channel shim that uses a PSBT to fund and sign the channel funding
|
|
|
|
transaction.
|
|
|
|
*/
|
|
|
|
PsbtShim psbt_shim = 2;
|
lnrpc: add ability to provide chan point shims for funding, new funding modifiers
In this commit, we start to expose some of the new external funding
functionality over the RPC interface.
First, we add a new `funding_shim` field to the regular `OpenChannel`
method. This can be used by a caller to express that certain parameters
of the funding flow have already been negotiated outside the protocol,
and should be used instead. For example, a shim can be provided to use a
particular key for the commitment key (ideally cold) rather than use one
this is generated by the wallet as normal, or signal that signing will
be carried out in an interactive manner (PSBT based).
Next, we add a brand new method: `FundingStateStep`. 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 new transition methods (funding state machine modifiers) in this
commit allow a party to register a funding intent that should be used
for a specified incoming pending channel ID. The "responder" to the
external channel flow should use this to prep lnd to be able to handle
the channel flow properly.
2019-11-14 07:54:34 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
message FundingShimCancel {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The pending channel ID of the channel to cancel the funding shim for.
|
lnrpc: add ability to provide chan point shims for funding, new funding modifiers
In this commit, we start to expose some of the new external funding
functionality over the RPC interface.
First, we add a new `funding_shim` field to the regular `OpenChannel`
method. This can be used by a caller to express that certain parameters
of the funding flow have already been negotiated outside the protocol,
and should be used instead. For example, a shim can be provided to use a
particular key for the commitment key (ideally cold) rather than use one
this is generated by the wallet as normal, or signal that signing will
be carried out in an interactive manner (PSBT based).
Next, we add a brand new method: `FundingStateStep`. 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 new transition methods (funding state machine modifiers) in this
commit allow a party to register a funding intent that should be used
for a specified incoming pending channel ID. The "responder" to the
external channel flow should use this to prep lnd to be able to handle
the channel flow properly.
2019-11-14 07:54:34 +03:00
|
|
|
bytes pending_chan_id = 1;
|
|
|
|
}
|
|
|
|
|
2020-03-31 10:13:13 +03:00
|
|
|
message FundingPsbtVerify {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-03-31 10:13:13 +03:00
|
|
|
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.
|
|
|
|
*/
|
|
|
|
bytes funded_psbt = 1;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The pending channel ID of the channel to get the PSBT for.
|
2020-03-31 10:13:13 +03:00
|
|
|
bytes pending_chan_id = 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
message FundingPsbtFinalize {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-03-31 10:13:13 +03:00
|
|
|
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
|
2020-09-07 19:02:40 +03:00
|
|
|
previous step. Cannot be set at the same time as final_raw_tx.
|
2020-03-31 10:13:13 +03:00
|
|
|
*/
|
|
|
|
bytes signed_psbt = 1;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The pending channel ID of the channel to get the PSBT for.
|
2020-03-31 10:13:13 +03:00
|
|
|
bytes pending_chan_id = 2;
|
2020-09-07 19:02:40 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
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.
|
|
|
|
*/
|
|
|
|
bytes final_raw_tx = 3;
|
2020-03-31 10:13:13 +03:00
|
|
|
}
|
|
|
|
|
lnrpc: add ability to provide chan point shims for funding, new funding modifiers
In this commit, we start to expose some of the new external funding
functionality over the RPC interface.
First, we add a new `funding_shim` field to the regular `OpenChannel`
method. This can be used by a caller to express that certain parameters
of the funding flow have already been negotiated outside the protocol,
and should be used instead. For example, a shim can be provided to use a
particular key for the commitment key (ideally cold) rather than use one
this is generated by the wallet as normal, or signal that signing will
be carried out in an interactive manner (PSBT based).
Next, we add a brand new method: `FundingStateStep`. 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 new transition methods (funding state machine modifiers) in this
commit allow a party to register a funding intent that should be used
for a specified incoming pending channel ID. The "responder" to the
external channel flow should use this to prep lnd to be able to handle
the channel flow properly.
2019-11-14 07:54:34 +03:00
|
|
|
message FundingTransitionMsg {
|
|
|
|
oneof trigger {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-03-31 10:13:13 +03:00
|
|
|
The funding shim to register. This should be used before any
|
lnrpc: add ability to provide chan point shims for funding, new funding modifiers
In this commit, we start to expose some of the new external funding
functionality over the RPC interface.
First, we add a new `funding_shim` field to the regular `OpenChannel`
method. This can be used by a caller to express that certain parameters
of the funding flow have already been negotiated outside the protocol,
and should be used instead. For example, a shim can be provided to use a
particular key for the commitment key (ideally cold) rather than use one
this is generated by the wallet as normal, or signal that signing will
be carried out in an interactive manner (PSBT based).
Next, we add a brand new method: `FundingStateStep`. 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 new transition methods (funding state machine modifiers) in this
commit allow a party to register a funding intent that should be used
for a specified incoming pending channel ID. The "responder" to the
external channel flow should use this to prep lnd to be able to handle
the channel flow properly.
2019-11-14 07:54:34 +03:00
|
|
|
channel funding has began by the remote party, as it is intended as a
|
2020-03-31 10:13:13 +03:00
|
|
|
preparatory step for the full channel funding.
|
lnrpc: add ability to provide chan point shims for funding, new funding modifiers
In this commit, we start to expose some of the new external funding
functionality over the RPC interface.
First, we add a new `funding_shim` field to the regular `OpenChannel`
method. This can be used by a caller to express that certain parameters
of the funding flow have already been negotiated outside the protocol,
and should be used instead. For example, a shim can be provided to use a
particular key for the commitment key (ideally cold) rather than use one
this is generated by the wallet as normal, or signal that signing will
be carried out in an interactive manner (PSBT based).
Next, we add a brand new method: `FundingStateStep`. 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 new transition methods (funding state machine modifiers) in this
commit allow a party to register a funding intent that should be used
for a specified incoming pending channel ID. The "responder" to the
external channel flow should use this to prep lnd to be able to handle
the channel flow properly.
2019-11-14 07:54:34 +03:00
|
|
|
*/
|
|
|
|
FundingShim shim_register = 1;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Used to cancel an existing registered funding shim.
|
lnrpc: add ability to provide chan point shims for funding, new funding modifiers
In this commit, we start to expose some of the new external funding
functionality over the RPC interface.
First, we add a new `funding_shim` field to the regular `OpenChannel`
method. This can be used by a caller to express that certain parameters
of the funding flow have already been negotiated outside the protocol,
and should be used instead. For example, a shim can be provided to use a
particular key for the commitment key (ideally cold) rather than use one
this is generated by the wallet as normal, or signal that signing will
be carried out in an interactive manner (PSBT based).
Next, we add a brand new method: `FundingStateStep`. 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 new transition methods (funding state machine modifiers) in this
commit allow a party to register a funding intent that should be used
for a specified incoming pending channel ID. The "responder" to the
external channel flow should use this to prep lnd to be able to handle
the channel flow properly.
2019-11-14 07:54:34 +03:00
|
|
|
FundingShimCancel shim_cancel = 2;
|
2020-03-31 10:13:13 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-03-31 10:13:13 +03:00
|
|
|
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.
|
|
|
|
*/
|
|
|
|
FundingPsbtVerify psbt_verify = 3;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-03-31 10:13:13 +03:00
|
|
|
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.
|
|
|
|
*/
|
|
|
|
FundingPsbtFinalize psbt_finalize = 4;
|
2016-07-08 01:23:29 +03:00
|
|
|
}
|
2016-06-21 22:32:32 +03:00
|
|
|
}
|
|
|
|
|
lnrpc: add ability to provide chan point shims for funding, new funding modifiers
In this commit, we start to expose some of the new external funding
functionality over the RPC interface.
First, we add a new `funding_shim` field to the regular `OpenChannel`
method. This can be used by a caller to express that certain parameters
of the funding flow have already been negotiated outside the protocol,
and should be used instead. For example, a shim can be provided to use a
particular key for the commitment key (ideally cold) rather than use one
this is generated by the wallet as normal, or signal that signing will
be carried out in an interactive manner (PSBT based).
Next, we add a brand new method: `FundingStateStep`. 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 new transition methods (funding state machine modifiers) in this
commit allow a party to register a funding intent that should be used
for a specified incoming pending channel ID. The "responder" to the
external channel flow should use this to prep lnd to be able to handle
the channel flow properly.
2019-11-14 07:54:34 +03:00
|
|
|
message FundingStateStepResp {
|
|
|
|
}
|
|
|
|
|
2017-11-09 06:27:45 +03:00
|
|
|
message PendingHTLC {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The direction within the channel that the htlc was sent
|
2020-02-11 15:53:39 +03:00
|
|
|
bool incoming = 1;
|
2017-11-09 06:27:45 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The total value of the htlc
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 amount = 2;
|
2017-11-09 06:27:45 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The final output to be swept back to the user's wallet
|
2020-02-11 15:53:39 +03:00
|
|
|
string outpoint = 3;
|
2017-11-09 06:27:45 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The next block height at which we can spend the current stage
|
2020-02-11 15:53:39 +03:00
|
|
|
uint32 maturity_height = 4;
|
2017-11-09 06:27:45 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2017-11-09 06:27:45 +03:00
|
|
|
The number of blocks remaining until the current stage can be swept.
|
|
|
|
Negative values indicate how many blocks have passed since becoming
|
|
|
|
mature.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
int32 blocks_til_maturity = 5;
|
2017-11-09 06:27:45 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Indicates whether the htlc is in its first or second stage of recovery
|
2020-02-11 15:53:39 +03:00
|
|
|
uint32 stage = 6;
|
2017-11-09 06:27:45 +03:00
|
|
|
}
|
|
|
|
|
2020-02-11 15:53:39 +03:00
|
|
|
message PendingChannelsRequest {
|
|
|
|
}
|
2018-01-04 23:20:25 +03:00
|
|
|
message PendingChannelsResponse {
|
2016-07-08 01:24:52 +03:00
|
|
|
message PendingChannel {
|
2020-02-11 15:53:39 +03:00
|
|
|
string remote_node_pub = 1;
|
|
|
|
string channel_point = 2;
|
|
|
|
|
|
|
|
int64 capacity = 3;
|
2016-07-08 01:24:52 +03:00
|
|
|
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 local_balance = 4;
|
|
|
|
int64 remote_balance = 5;
|
2017-05-05 01:34:02 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The minimum satoshis this node is required to reserve in its
|
|
|
|
// balance.
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 local_chan_reserve_sat = 6;
|
2019-06-23 13:06:09 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-06-23 13:06:09 +03:00
|
|
|
The minimum satoshis the other node is required to reserve in its
|
|
|
|
balance.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 remote_chan_reserve_sat = 7;
|
2020-03-25 09:40:44 +03:00
|
|
|
|
2020-04-03 10:13:53 +03:00
|
|
|
// The party that initiated opening the channel.
|
|
|
|
Initiator initiator = 8;
|
2020-03-30 21:36:38 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The commitment type used by this channel.
|
2020-03-30 21:36:38 +03:00
|
|
|
CommitmentType commitment_type = 9;
|
2017-05-05 01:34:02 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
message PendingOpenChannel {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The pending channel
|
2020-02-11 15:53:39 +03:00
|
|
|
PendingChannel channel = 1;
|
2017-05-05 01:34:02 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The height at which this channel will be confirmed
|
2020-02-11 15:53:39 +03:00
|
|
|
uint32 confirmation_height = 2;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2017-07-28 02:39:49 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 commit_fee = 4;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The weight of the commitment transaction
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 commit_weight = 5;
|
2017-07-28 02:39:49 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2017-07-28 02:39:49 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 fee_per_kw = 6;
|
2017-05-05 01:34:02 +03:00
|
|
|
}
|
|
|
|
|
2018-04-12 13:58:21 +03:00
|
|
|
message WaitingCloseChannel {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The pending channel waiting for closing tx to confirm
|
2018-04-12 13:58:21 +03:00
|
|
|
PendingChannel channel = 1;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The balance in satoshis encumbered in this channel
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 limbo_balance = 2;
|
2020-03-11 18:48:45 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-03-11 18:48:45 +03:00
|
|
|
A list of valid commitment transactions. Any of these can confirm at
|
|
|
|
this point.
|
|
|
|
*/
|
|
|
|
Commitments commitments = 3;
|
|
|
|
}
|
|
|
|
|
|
|
|
message Commitments {
|
2020-05-06 17:51:14 +03:00
|
|
|
// Hash of the local version of the commitment tx.
|
2020-03-11 18:48:45 +03:00
|
|
|
string local_txid = 1;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Hash of the remote version of the commitment tx.
|
2020-03-11 18:48:45 +03:00
|
|
|
string remote_txid = 2;
|
2020-03-20 12:11:45 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Hash of the remote pending version of the commitment tx.
|
2020-03-11 18:48:45 +03:00
|
|
|
string remote_pending_txid = 3;
|
2020-03-25 09:41:00 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
The amount in satoshis calculated to be paid in fees for the local
|
|
|
|
commitment.
|
|
|
|
*/
|
|
|
|
uint64 local_commit_fee_sat = 4;
|
|
|
|
|
|
|
|
/*
|
|
|
|
The amount in satoshis calculated to be paid in fees for the remote
|
|
|
|
commitment.
|
|
|
|
*/
|
|
|
|
uint64 remote_commit_fee_sat = 5;
|
|
|
|
|
|
|
|
/*
|
|
|
|
The amount in satoshis calculated to be paid in fees for the remote
|
|
|
|
pending commitment.
|
|
|
|
*/
|
|
|
|
uint64 remote_pending_commit_fee_sat = 6;
|
2018-04-12 13:58:21 +03:00
|
|
|
}
|
|
|
|
|
2017-05-05 01:34:02 +03:00
|
|
|
message ClosedChannel {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The pending channel to be closed
|
2017-05-05 01:34:02 +03:00
|
|
|
PendingChannel channel = 1;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The transaction id of the closing transaction
|
2020-02-11 15:53:39 +03:00
|
|
|
string closing_txid = 2;
|
2017-05-05 01:34:02 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
message ForceClosedChannel {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The pending channel to be force closed
|
2020-02-11 15:53:39 +03:00
|
|
|
PendingChannel channel = 1;
|
2017-05-05 01:34:02 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The transaction id of the closing transaction
|
2020-02-11 15:53:39 +03:00
|
|
|
string closing_txid = 2;
|
2016-07-08 01:24:52 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The balance in satoshis encumbered in this pending channel
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 limbo_balance = 3;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The height at which funds can be swept into the wallet
|
2020-02-11 15:53:39 +03:00
|
|
|
uint32 maturity_height = 4;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2017-11-09 06:27:45 +03:00
|
|
|
/*
|
|
|
|
Remaining # of blocks until the commitment output can be swept.
|
|
|
|
Negative values indicate how many blocks have passed since becoming
|
|
|
|
mature.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
int32 blocks_til_maturity = 5;
|
2017-11-09 06:27:45 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The total value of funds successfully recovered from this channel
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 recovered_balance = 6;
|
2017-11-09 06:27:45 +03:00
|
|
|
|
2020-02-11 15:53:39 +03:00
|
|
|
repeated PendingHTLC pending_htlcs = 8;
|
2020-03-10 15:39:01 +03:00
|
|
|
|
|
|
|
enum AnchorState {
|
|
|
|
LIMBO = 0;
|
|
|
|
RECOVERED = 1;
|
|
|
|
LOST = 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
AnchorState anchor = 9;
|
2016-07-08 01:24:52 +03:00
|
|
|
}
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The balance in satoshis encumbered in pending channels
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 total_limbo_balance = 1;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Channels pending opening
|
2020-02-11 15:53:39 +03:00
|
|
|
repeated PendingOpenChannel pending_open_channels = 2;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-03-25 09:41:00 +03:00
|
|
|
/*
|
|
|
|
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.
|
|
|
|
*/
|
|
|
|
repeated ClosedChannel pending_closing_channels = 3 [deprecated = true];
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Channels pending force closing
|
2020-02-11 15:53:39 +03:00
|
|
|
repeated ForceClosedChannel pending_force_closing_channels = 4;
|
2018-04-12 13:58:21 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Channels waiting for closing tx to confirm
|
2020-02-11 15:53:39 +03:00
|
|
|
repeated WaitingCloseChannel waiting_close_channels = 5;
|
2016-06-21 22:32:32 +03:00
|
|
|
}
|
|
|
|
|
2019-01-23 05:28:27 +03:00
|
|
|
message ChannelEventSubscription {
|
|
|
|
}
|
|
|
|
|
|
|
|
message ChannelEventUpdate {
|
|
|
|
oneof channel {
|
2020-02-11 15:53:39 +03:00
|
|
|
Channel open_channel = 1;
|
|
|
|
ChannelCloseSummary closed_channel = 2;
|
|
|
|
ChannelPoint active_channel = 3;
|
|
|
|
ChannelPoint inactive_channel = 4;
|
|
|
|
PendingUpdate pending_open_channel = 6;
|
2019-01-23 05:28:27 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
enum UpdateType {
|
2020-02-11 15:53:39 +03:00
|
|
|
OPEN_CHANNEL = 0;
|
|
|
|
CLOSED_CHANNEL = 1;
|
|
|
|
ACTIVE_CHANNEL = 2;
|
|
|
|
INACTIVE_CHANNEL = 3;
|
|
|
|
PENDING_OPEN_CHANNEL = 4;
|
2019-01-23 05:28:27 +03:00
|
|
|
}
|
|
|
|
|
2020-02-11 15:53:39 +03:00
|
|
|
UpdateType type = 5;
|
2019-01-23 05:28:27 +03:00
|
|
|
}
|
|
|
|
|
2021-02-20 04:42:16 +03:00
|
|
|
message WalletAccountBalance {
|
|
|
|
// The confirmed balance of the account (with >= 1 confirmations).
|
|
|
|
int64 confirmed_balance = 1;
|
|
|
|
|
|
|
|
// The unconfirmed balance of the account (with 0 confirmations).
|
|
|
|
int64 unconfirmed_balance = 2;
|
|
|
|
}
|
|
|
|
|
2016-06-21 21:46:27 +03:00
|
|
|
message WalletBalanceRequest {
|
|
|
|
}
|
2021-02-20 04:42:16 +03:00
|
|
|
|
2016-06-21 21:46:27 +03:00
|
|
|
message WalletBalanceResponse {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The balance of the wallet
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 total_balance = 1;
|
2017-11-26 16:07:55 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The confirmed balance of a wallet(with >= 1 confirmations)
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 confirmed_balance = 2;
|
2017-11-26 16:07:55 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The unconfirmed balance of a wallet(with 0 confirmations)
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 unconfirmed_balance = 3;
|
2021-02-20 04:42:16 +03:00
|
|
|
|
|
|
|
// A mapping of each wallet account's name to its balance.
|
|
|
|
map<string, WalletAccountBalance> account_balance = 4;
|
2015-12-31 05:58:15 +03:00
|
|
|
}
|
2016-07-15 14:02:59 +03:00
|
|
|
|
2020-08-06 13:01:31 +03:00
|
|
|
message Amount {
|
|
|
|
// Value denominated in satoshis.
|
|
|
|
uint64 sat = 1;
|
|
|
|
|
|
|
|
// Value denominated in milli-satoshis.
|
|
|
|
uint64 msat = 2;
|
|
|
|
}
|
|
|
|
|
2016-09-15 21:59:51 +03:00
|
|
|
message ChannelBalanceRequest {
|
|
|
|
}
|
|
|
|
message ChannelBalanceResponse {
|
2020-08-06 13:01:31 +03:00
|
|
|
// Deprecated. Sum of channels balances denominated in satoshis
|
|
|
|
int64 balance = 1 [deprecated = true];
|
|
|
|
|
|
|
|
// Deprecated. Sum of channels pending balances denominated in satoshis
|
|
|
|
int64 pending_open_balance = 2 [deprecated = true];
|
|
|
|
|
|
|
|
// Sum of channels local balances.
|
|
|
|
Amount local_balance = 3;
|
|
|
|
|
|
|
|
// Sum of channels remote balances.
|
|
|
|
Amount remote_balance = 4;
|
|
|
|
|
|
|
|
// Sum of channels local unsettled balances.
|
|
|
|
Amount unsettled_local_balance = 5;
|
|
|
|
|
|
|
|
// Sum of channels remote unsettled balances.
|
|
|
|
Amount unsettled_remote_balance = 6;
|
|
|
|
|
|
|
|
// Sum of channels pending local balances.
|
|
|
|
Amount pending_open_local_balance = 7;
|
2018-04-01 02:38:04 +03:00
|
|
|
|
2020-08-06 13:01:31 +03:00
|
|
|
// Sum of channels pending remote balances.
|
|
|
|
Amount pending_open_remote_balance = 8;
|
2016-09-15 21:59:51 +03:00
|
|
|
}
|
|
|
|
|
2017-03-21 05:01:32 +03:00
|
|
|
message QueryRoutesRequest {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The 33-byte hex-encoded public key for the payment destination
|
2016-12-27 08:44:44 +03:00
|
|
|
string pub_key = 1;
|
2017-07-28 02:39:49 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-11 18:44:08 +03:00
|
|
|
The amount to send expressed in satoshis.
|
|
|
|
|
|
|
|
The fields amt and amt_msat are mutually exclusive.
|
|
|
|
*/
|
2016-12-27 08:44:44 +03:00
|
|
|
int64 amt = 2;
|
2018-02-13 03:28:39 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-11 18:44:08 +03:00
|
|
|
The amount to send expressed in millisatoshis.
|
|
|
|
|
|
|
|
The fields amt and amt_msat are mutually exclusive.
|
|
|
|
*/
|
|
|
|
int64 amt_msat = 12;
|
|
|
|
|
2019-05-07 18:01:01 +03:00
|
|
|
reserved 3;
|
2018-02-15 15:01:57 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-12-16 15:37:50 +03:00
|
|
|
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.
|
|
|
|
*/
|
2018-02-15 15:01:57 +03:00
|
|
|
int32 final_cltv_delta = 4;
|
2018-02-01 01:36:10 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2018-04-19 01:13:55 +03:00
|
|
|
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.
|
|
|
|
*/
|
|
|
|
FeeLimit fee_limit = 5;
|
2019-03-05 14:42:29 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-01 11:45:02 +03:00
|
|
|
A list of nodes to ignore during path finding. When using REST, these fields
|
|
|
|
must be encoded as base64.
|
2019-03-05 14:42:29 +03:00
|
|
|
*/
|
|
|
|
repeated bytes ignored_nodes = 6;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-07-29 16:10:58 +03:00
|
|
|
Deprecated. A list of edges to ignore during path finding.
|
2019-03-05 14:42:29 +03:00
|
|
|
*/
|
2019-07-29 16:10:58 +03:00
|
|
|
repeated EdgeLocator ignored_edges = 7 [deprecated = true];
|
2019-03-05 18:49:26 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-03-05 18:49:26 +03:00
|
|
|
The source node where the request route should originated from. If empty,
|
|
|
|
self is assumed.
|
|
|
|
*/
|
|
|
|
string source_pub_key = 8;
|
2019-06-19 09:29:44 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-06-19 09:29:44 +03:00
|
|
|
If set to true, edge probabilities from mission control will be used to get
|
|
|
|
the optimal route.
|
|
|
|
*/
|
|
|
|
bool use_mission_control = 9;
|
2019-07-29 16:10:58 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-07-29 16:10:58 +03:00
|
|
|
A list of directed node pairs that will be ignored during path finding.
|
|
|
|
*/
|
|
|
|
repeated NodePair ignored_pairs = 10;
|
2019-10-11 22:47:15 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-10-11 22:47:15 +03:00
|
|
|
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.
|
|
|
|
*/
|
|
|
|
uint32 cltv_limit = 11;
|
2019-11-20 14:00:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-20 14:00:25 +03:00
|
|
|
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.
|
|
|
|
*/
|
|
|
|
map<uint64, bytes> dest_custom_records = 13;
|
2020-01-14 13:21:24 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-01-14 13:21:24 +03:00
|
|
|
The channel id of the channel that must be taken to the first hop. If zero,
|
|
|
|
any channel may be used.
|
|
|
|
*/
|
|
|
|
uint64 outgoing_chan_id = 14 [jstype = JS_STRING];
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-01-14 13:21:24 +03:00
|
|
|
The pubkey of the last hop of the route. If empty, any hop may be used.
|
|
|
|
*/
|
|
|
|
bytes last_hop_pubkey = 15;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-01-14 13:21:24 +03:00
|
|
|
Optional route hints to reach the destination through private channels.
|
|
|
|
*/
|
|
|
|
repeated lnrpc.RouteHint route_hints = 16;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-01-14 13:21:24 +03:00
|
|
|
Features assumed to be supported by the final node. All transitive feature
|
2020-01-18 00:12:02 +03:00
|
|
|
dependencies must also be set properly. For a given feature bit pair, either
|
2020-01-14 13:21:24 +03:00
|
|
|
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.
|
|
|
|
*/
|
|
|
|
repeated lnrpc.FeatureBit dest_features = 17;
|
2019-07-29 16:10:58 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
message NodePair {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-01 11:45:02 +03:00
|
|
|
The sending node of the pair. When using REST, this field must be encoded as
|
|
|
|
base64.
|
|
|
|
*/
|
2019-07-29 16:10:58 +03:00
|
|
|
bytes from = 1;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-01 11:45:02 +03:00
|
|
|
The receiving node of the pair. When using REST, this field must be encoded
|
|
|
|
as base64.
|
|
|
|
*/
|
2019-07-29 16:10:58 +03:00
|
|
|
bytes to = 2;
|
2016-12-27 08:44:44 +03:00
|
|
|
}
|
2019-03-05 14:42:29 +03:00
|
|
|
|
|
|
|
message EdgeLocator {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The short channel id of this edge.
|
2018-12-19 23:49:41 +03:00
|
|
|
uint64 channel_id = 1 [jstype = JS_STRING];
|
2019-03-05 14:42:29 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-03-05 14:42:29 +03:00
|
|
|
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.
|
|
|
|
*/
|
|
|
|
bool direction_reverse = 2;
|
|
|
|
}
|
|
|
|
|
2017-03-21 05:01:32 +03:00
|
|
|
message QueryRoutesResponse {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-09-03 09:58:14 +03:00
|
|
|
The route that results from the path finding operation. This is still a
|
|
|
|
repeated field to retain backwards compatibility.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
repeated Route routes = 1;
|
2019-09-03 09:58:14 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-09-03 09:58:14 +03:00
|
|
|
The success probability of the returned route based on the current mission
|
|
|
|
control state. [EXPERIMENTAL]
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
double success_prob = 2;
|
2017-03-21 05:01:32 +03:00
|
|
|
}
|
2016-12-27 08:44:44 +03:00
|
|
|
|
|
|
|
message Hop {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2017-07-28 02:39:49 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 chan_id = 1 [jstype = JS_STRING];
|
2021-04-27 17:05:49 +03:00
|
|
|
int64 chan_capacity = 2 [deprecated = true];
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 amt_to_forward = 3 [deprecated = true];
|
|
|
|
int64 fee = 4 [deprecated = true];
|
|
|
|
uint32 expiry = 5;
|
|
|
|
int64 amt_to_forward_msat = 6;
|
|
|
|
int64 fee_msat = 7;
|
2018-08-02 16:18:21 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2018-08-02 16:18:21 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
string pub_key = 8;
|
2019-07-31 07:44:02 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-07-31 07:44:02 +03:00
|
|
|
If set to true, then this hop will be encoded using the new variable length
|
2019-11-20 14:00:25 +03:00
|
|
|
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.
|
2019-07-31 07:44:02 +03:00
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
bool tlv_payload = 9;
|
2019-11-05 02:11:07 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-04-18 13:12:18 +03:00
|
|
|
An optional TLV record that signals the use of an MPP payment. If present,
|
2021-03-25 05:52:56 +03:00
|
|
|
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.
|
2019-11-05 02:11:07 +03:00
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
MPPRecord mpp_record = 10;
|
2019-11-20 14:00:25 +03:00
|
|
|
|
2021-03-25 05:52:56 +03:00
|
|
|
/*
|
|
|
|
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.
|
|
|
|
*/
|
|
|
|
AMPRecord amp_record = 12;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-20 14:00:25 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
map<uint64, bytes> custom_records = 11;
|
2019-11-05 02:11:07 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
message MPPRecord {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-05 02:11:07 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
bytes payment_addr = 11;
|
2019-11-05 02:11:07 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-05 02:11:07 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 total_amt_msat = 10;
|
2016-12-27 08:44:44 +03:00
|
|
|
}
|
|
|
|
|
2021-03-25 05:52:56 +03:00
|
|
|
message AMPRecord {
|
|
|
|
bytes root_share = 1;
|
|
|
|
|
|
|
|
bytes set_id = 2;
|
|
|
|
|
|
|
|
uint32 child_index = 3;
|
|
|
|
}
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2017-07-28 02:39:49 +03:00
|
|
|
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.
|
|
|
|
*/
|
2016-12-27 08:44:44 +03:00
|
|
|
message Route {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-01 11:45:02 +03:00
|
|
|
The cumulative (final) time lock across the entire route. This is the CLTV
|
2017-07-28 02:39:49 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
uint32 total_time_lock = 1;
|
2017-07-28 02:39:49 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-01 11:45:02 +03:00
|
|
|
The sum of the fees paid at each hop within the final route. In the case
|
2017-07-28 02:39:49 +03:00
|
|
|
of a one-hop payment, this value will be zero as we don't need to pay a fee
|
2019-05-14 00:31:32 +03:00
|
|
|
to ourselves.
|
2017-07-28 02:39:49 +03:00
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 total_fees = 2 [deprecated = true];
|
2017-07-28 02:39:49 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2017-07-28 02:39:49 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 total_amt = 3 [deprecated = true];
|
2016-12-27 08:44:44 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2017-07-28 02:39:49 +03:00
|
|
|
Contains details concerning the specific forwarding details at each hop.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
repeated Hop hops = 4;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2018-04-12 11:34:31 +03:00
|
|
|
The total fees in millisatoshis.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 total_fees_msat = 5;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2018-04-12 11:34:31 +03:00
|
|
|
The total amount in millisatoshis.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 total_amt_msat = 6;
|
2016-12-27 08:44:44 +03:00
|
|
|
}
|
|
|
|
|
2017-04-12 00:49:39 +03:00
|
|
|
message NodeInfoRequest {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The 33-byte hex-encoded compressed public of the target node
|
2017-04-12 00:49:39 +03:00
|
|
|
string pub_key = 1;
|
2019-06-17 20:57:45 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// If true, will include all known channels associated with the node.
|
2019-06-17 20:57:45 +03:00
|
|
|
bool include_channels = 2;
|
2016-12-27 08:44:44 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
message NodeInfo {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2017-07-28 02:39:49 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
LightningNode node = 1;
|
2016-12-27 08:44:44 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The total number of channels for the node.
|
2020-02-11 15:53:39 +03:00
|
|
|
uint32 num_channels = 2;
|
2018-12-10 18:37:08 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The sum of all channels capacity for the node, denominated in satoshis.
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 total_capacity = 3;
|
2018-12-10 18:37:08 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// A list of all public channels for the node.
|
2020-02-11 15:53:39 +03:00
|
|
|
repeated ChannelEdge channels = 4;
|
2016-12-27 08:44:44 +03:00
|
|
|
}
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2017-07-28 02:39:49 +03:00
|
|
|
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.
|
|
|
|
*/
|
2016-12-27 08:44:44 +03:00
|
|
|
message LightningNode {
|
2020-02-11 15:53:39 +03:00
|
|
|
uint32 last_update = 1;
|
|
|
|
string pub_key = 2;
|
|
|
|
string alias = 3;
|
|
|
|
repeated NodeAddress addresses = 4;
|
|
|
|
string color = 5;
|
|
|
|
map<uint32, Feature> features = 6;
|
2017-02-17 12:29:23 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
message NodeAddress {
|
2020-02-11 15:53:39 +03:00
|
|
|
string network = 1;
|
|
|
|
string addr = 2;
|
2016-12-27 08:44:44 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
message RoutingPolicy {
|
2020-02-11 15:53:39 +03:00
|
|
|
uint32 time_lock_delta = 1;
|
|
|
|
int64 min_htlc = 2;
|
|
|
|
int64 fee_base_msat = 3;
|
|
|
|
int64 fee_rate_milli_msat = 4;
|
|
|
|
bool disabled = 5;
|
|
|
|
uint64 max_htlc_msat = 6;
|
|
|
|
uint32 last_update = 7;
|
2016-12-27 08:44:44 +03:00
|
|
|
}
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2017-07-28 02:39:49 +03:00
|
|
|
A fully authenticated channel along with all its unique attributes.
|
|
|
|
Once an authenticated channel announcement has been processed on the network,
|
2018-04-18 05:02:04 +03:00
|
|
|
then an instance of ChannelEdgeInfo encapsulating the channels attributes is
|
2017-07-28 02:39:49 +03:00
|
|
|
stored. The other portions relevant to routing policy of a channel are stored
|
|
|
|
within a ChannelEdgePolicy for each direction of the channel.
|
|
|
|
*/
|
2016-12-27 08:44:44 +03:00
|
|
|
message ChannelEdge {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2017-07-28 02:39:49 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 channel_id = 1 [jstype = JS_STRING];
|
|
|
|
string chan_point = 2;
|
2016-12-27 08:44:44 +03:00
|
|
|
|
2020-02-11 15:53:39 +03:00
|
|
|
uint32 last_update = 3 [deprecated = true];
|
2016-12-27 08:44:44 +03:00
|
|
|
|
2020-02-11 15:53:39 +03:00
|
|
|
string node1_pub = 4;
|
|
|
|
string node2_pub = 5;
|
2016-12-27 08:44:44 +03:00
|
|
|
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 capacity = 6;
|
2016-12-27 08:44:44 +03:00
|
|
|
|
2020-02-11 15:53:39 +03:00
|
|
|
RoutingPolicy node1_policy = 7;
|
|
|
|
RoutingPolicy node2_policy = 8;
|
2016-12-27 08:44:44 +03:00
|
|
|
}
|
|
|
|
|
2017-04-12 00:49:39 +03:00
|
|
|
message ChannelGraphRequest {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-02-11 15:53:39 +03:00
|
|
|
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.
|
|
|
|
*/
|
|
|
|
bool include_unannounced = 1;
|
2017-04-12 00:49:39 +03:00
|
|
|
}
|
2016-12-27 08:44:44 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Returns a new instance of the directed channel graph.
|
2016-12-27 08:44:44 +03:00
|
|
|
message ChannelGraph {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The list of `LightningNode`s in this channel graph
|
2020-02-11 15:53:39 +03:00
|
|
|
repeated LightningNode nodes = 1;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The list of `ChannelEdge`s in this channel graph
|
2020-02-11 15:53:39 +03:00
|
|
|
repeated ChannelEdge edges = 2;
|
2016-08-20 23:49:35 +03:00
|
|
|
}
|
|
|
|
|
2020-04-03 10:09:23 +03:00
|
|
|
enum NodeMetricType {
|
2020-03-28 18:14:26 +03:00
|
|
|
UNKNOWN = 0;
|
2020-04-03 10:09:23 +03:00
|
|
|
BETWEENNESS_CENTRALITY = 1;
|
2020-03-19 13:14:28 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
message NodeMetricsRequest {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The requested node metrics.
|
2020-03-28 18:14:26 +03:00
|
|
|
repeated NodeMetricType types = 1;
|
2020-03-19 13:14:28 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
message NodeMetricsResponse {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-03-19 13:14:28 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-03-28 18:14:26 +03:00
|
|
|
map<string, FloatMetric> betweenness_centrality = 1;
|
2020-03-19 13:14:28 +03:00
|
|
|
}
|
|
|
|
|
2020-03-28 18:14:26 +03:00
|
|
|
message FloatMetric {
|
2020-05-06 17:51:14 +03:00
|
|
|
// Arbitrary float value.
|
2020-03-28 18:14:26 +03:00
|
|
|
double value = 1;
|
2020-03-19 13:14:28 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The value normalized to [0,1] or [-1,1].
|
2020-03-28 18:14:26 +03:00
|
|
|
double normalized_value = 2;
|
2020-03-19 13:14:28 +03:00
|
|
|
}
|
|
|
|
|
2016-12-27 08:44:44 +03:00
|
|
|
message ChanInfoRequest {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2017-07-28 02:39:49 +03:00
|
|
|
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.
|
|
|
|
*/
|
2018-12-19 23:49:41 +03:00
|
|
|
uint64 chan_id = 1 [jstype = JS_STRING];
|
2016-07-15 14:02:59 +03:00
|
|
|
}
|
|
|
|
|
2017-04-12 00:49:39 +03:00
|
|
|
message NetworkInfoRequest {
|
|
|
|
}
|
2016-12-27 08:44:44 +03:00
|
|
|
message NetworkInfo {
|
2020-02-11 15:53:39 +03:00
|
|
|
uint32 graph_diameter = 1;
|
|
|
|
double avg_out_degree = 2;
|
|
|
|
uint32 max_out_degree = 3;
|
2016-12-27 08:44:44 +03:00
|
|
|
|
2020-02-11 15:53:39 +03:00
|
|
|
uint32 num_nodes = 4;
|
|
|
|
uint32 num_channels = 5;
|
2016-12-27 08:44:44 +03:00
|
|
|
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 total_network_capacity = 6;
|
2016-12-27 08:44:44 +03:00
|
|
|
|
2020-02-11 15:53:39 +03:00
|
|
|
double avg_channel_size = 7;
|
|
|
|
int64 min_channel_size = 8;
|
|
|
|
int64 max_channel_size = 9;
|
|
|
|
int64 median_channel_size_sat = 10;
|
2016-12-27 08:44:44 +03:00
|
|
|
|
2019-07-16 02:48:59 +03:00
|
|
|
// The number of edges marked as zombies.
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 num_zombie_chans = 11;
|
2019-07-16 02:48:59 +03:00
|
|
|
|
2016-12-27 08:44:44 +03:00
|
|
|
// TODO(roasbeef): fee rate info, expiry
|
|
|
|
// * also additional RPC for tracking fee info once in
|
2016-07-15 14:02:59 +03:00
|
|
|
}
|
2016-09-19 21:52:23 +03:00
|
|
|
|
2020-02-11 15:53:39 +03:00
|
|
|
message StopRequest {
|
|
|
|
}
|
|
|
|
message StopResponse {
|
|
|
|
}
|
2017-05-12 00:55:56 +03:00
|
|
|
|
2020-02-11 15:53:39 +03:00
|
|
|
message GraphTopologySubscription {
|
|
|
|
}
|
2017-03-14 06:37:25 +03:00
|
|
|
message GraphTopologyUpdate {
|
2017-05-12 00:55:56 +03:00
|
|
|
repeated NodeUpdate node_updates = 1;
|
2017-03-14 06:37:25 +03:00
|
|
|
repeated ChannelEdgeUpdate channel_updates = 2;
|
|
|
|
repeated ClosedChannelUpdate closed_chans = 3;
|
|
|
|
}
|
|
|
|
message NodeUpdate {
|
2021-04-09 19:29:22 +03:00
|
|
|
/*
|
|
|
|
Deprecated, use node_addresses.
|
|
|
|
*/
|
|
|
|
repeated string addresses = 1 [deprecated = true];
|
|
|
|
|
2017-03-14 06:37:25 +03:00
|
|
|
string identity_key = 2;
|
2021-04-09 19:29:22 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
Deprecated, use features.
|
|
|
|
*/
|
2020-12-03 18:41:20 +03:00
|
|
|
bytes global_features = 3 [deprecated = true];
|
2021-04-09 19:29:22 +03:00
|
|
|
|
2017-03-14 06:37:25 +03:00
|
|
|
string alias = 4;
|
2018-12-21 19:29:24 +03:00
|
|
|
string color = 5;
|
2021-04-09 19:29:22 +03:00
|
|
|
repeated NodeAddress node_addresses = 7;
|
2020-12-03 18:41:20 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
Features that the node has advertised in the init message, node
|
|
|
|
announcements and invoices.
|
|
|
|
*/
|
|
|
|
map<uint32, Feature> features = 6;
|
2017-03-14 06:37:25 +03:00
|
|
|
}
|
|
|
|
message ChannelEdgeUpdate {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2017-07-28 02:39:49 +03:00
|
|
|
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.
|
|
|
|
*/
|
2018-12-19 23:49:41 +03:00
|
|
|
uint64 chan_id = 1 [jstype = JS_STRING];
|
2017-03-14 06:37:25 +03:00
|
|
|
|
|
|
|
ChannelPoint chan_point = 2;
|
|
|
|
|
|
|
|
int64 capacity = 3;
|
|
|
|
|
2020-02-11 15:53:39 +03:00
|
|
|
RoutingPolicy routing_policy = 4;
|
2017-03-14 06:37:25 +03:00
|
|
|
|
2020-02-11 15:53:39 +03:00
|
|
|
string advertising_node = 5;
|
2017-03-14 06:37:25 +03:00
|
|
|
string connecting_node = 6;
|
|
|
|
}
|
|
|
|
message ClosedChannelUpdate {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2017-07-28 02:39:49 +03:00
|
|
|
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.
|
|
|
|
*/
|
2018-12-19 23:49:41 +03:00
|
|
|
uint64 chan_id = 1 [jstype = JS_STRING];
|
2017-03-14 06:37:25 +03:00
|
|
|
int64 capacity = 2;
|
|
|
|
uint32 closed_height = 3;
|
|
|
|
ChannelPoint chan_point = 4;
|
|
|
|
}
|
|
|
|
|
2018-03-28 06:45:22 +03:00
|
|
|
message HopHint {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The public key of the node at the start of the channel.
|
2020-02-11 15:53:39 +03:00
|
|
|
string node_id = 1;
|
2018-03-28 06:45:22 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The unique identifier of the channel.
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 chan_id = 2 [jstype = JS_STRING];
|
2018-03-28 06:45:22 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The base fee of the channel denominated in millisatoshis.
|
2020-02-11 15:53:39 +03:00
|
|
|
uint32 fee_base_msat = 3;
|
2018-03-28 06:45:22 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2018-03-28 06:45:22 +03:00
|
|
|
The fee rate of the channel for sending one satoshi across it denominated in
|
|
|
|
millionths of a satoshi.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
uint32 fee_proportional_millionths = 4;
|
2018-03-28 06:45:22 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The time-lock delta of the channel.
|
2020-02-11 15:53:39 +03:00
|
|
|
uint32 cltv_expiry_delta = 5;
|
2018-03-28 06:45:22 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
message RouteHint {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2018-03-28 06:45:22 +03:00
|
|
|
A list of hop hints that when chained together can assist in reaching a
|
|
|
|
specific destination.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
repeated HopHint hop_hints = 1;
|
2018-03-28 06:45:22 +03:00
|
|
|
}
|
|
|
|
|
2016-09-19 21:52:23 +03:00
|
|
|
message Invoice {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2017-09-05 19:01:01 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
string memo = 1;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2019-11-22 13:23:24 +03:00
|
|
|
reserved 2;
|
2016-09-19 21:52:23 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2017-07-28 02:39:49 +03:00
|
|
|
The hex-encoded preimage (32 byte) which will allow settling an incoming
|
2019-11-01 11:45:02 +03:00
|
|
|
HTLC payable to this preimage. When using REST, this field must be encoded
|
|
|
|
as base64.
|
2017-07-28 02:39:49 +03:00
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
bytes r_preimage = 3;
|
2017-07-28 02:39:49 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-01 11:45:02 +03:00
|
|
|
The hash of the preimage. When using REST, this field must be encoded as
|
|
|
|
base64.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
bytes r_hash = 4;
|
2016-09-19 21:52:23 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-15 10:59:14 +03:00
|
|
|
The value of this invoice in satoshis
|
|
|
|
|
|
|
|
The fields value and value_msat are mutually exclusive.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 value = 5;
|
2016-09-24 01:06:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-15 10:59:14 +03:00
|
|
|
The value of this invoice in millisatoshis
|
|
|
|
|
|
|
|
The fields value and value_msat are mutually exclusive.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 value_msat = 23;
|
2019-11-15 10:59:14 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Whether this invoice has been fulfilled
|
2020-02-11 15:53:39 +03:00
|
|
|
bool settled = 6 [deprecated = true];
|
2016-11-13 05:03:19 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// When this invoice was created
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 creation_date = 7;
|
2017-07-28 02:39:49 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// When this invoice was settled
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 settle_date = 8;
|
2017-01-13 05:51:41 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-01 11:45:02 +03:00
|
|
|
A bare-bones invoice for a payment within the Lightning Network. With the
|
2017-07-28 02:39:49 +03:00
|
|
|
details of the invoice, the sender has all the data necessary to send a
|
|
|
|
payment to the recipient.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
string payment_request = 9;
|
2017-09-05 19:01:01 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2017-09-05 19:01:01 +03:00
|
|
|
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
|
2019-11-01 11:45:02 +03:00
|
|
|
of an encoded payment request. When using REST, this field must be encoded
|
|
|
|
as base64.
|
2017-09-05 19:01:01 +03:00
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
bytes description_hash = 10;
|
2017-09-05 19:01:01 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Payment request expiry time in seconds. Default is 3600 (1 hour).
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 expiry = 11;
|
2017-09-05 19:01:01 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Fallback on-chain address.
|
2020-02-11 15:53:39 +03:00
|
|
|
string fallback_addr = 12;
|
2017-10-19 08:13:40 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Delta to use for the time-lock of the CLTV extended to the final hop.
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 cltv_expiry = 13;
|
2018-03-28 06:45:22 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2018-03-28 06:45:22 +03:00
|
|
|
Route hints that can each be individually used to assist in reaching the
|
|
|
|
invoice's destination.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
repeated RouteHint route_hints = 14;
|
2018-03-28 07:03:33 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Whether this invoice should include routing hints for private channels.
|
2020-02-11 15:53:39 +03:00
|
|
|
bool private = 15;
|
2018-04-25 06:41:22 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2018-04-25 06:41:22 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 add_index = 16;
|
2018-04-25 06:41:22 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2018-04-25 06:41:22 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 settle_index = 17;
|
2018-04-25 06:41:22 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Deprecated, use amt_paid_sat or amt_paid_msat.
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 amt_paid = 18 [deprecated = true];
|
2018-09-06 09:38:38 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2018-09-06 09:38:38 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 amt_paid_sat = 19;
|
2018-09-06 09:38:38 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2018-09-06 09:38:38 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 amt_paid_msat = 20;
|
2018-12-19 18:03:48 +03:00
|
|
|
|
|
|
|
enum InvoiceState {
|
|
|
|
OPEN = 0;
|
|
|
|
SETTLED = 1;
|
2019-01-11 13:19:16 +03:00
|
|
|
CANCELED = 2;
|
2019-02-11 14:01:05 +03:00
|
|
|
ACCEPTED = 3;
|
2018-12-19 18:03:48 +03:00
|
|
|
}
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2018-12-19 18:03:48 +03:00
|
|
|
The state the invoice is in.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
InvoiceState state = 21;
|
2019-08-09 18:28:08 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// List of HTLCs paying to this invoice [EXPERIMENTAL].
|
2020-02-11 15:53:39 +03:00
|
|
|
repeated InvoiceHTLC htlcs = 22;
|
2019-12-12 03:36:44 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// List of features advertised on the invoice.
|
2020-02-11 15:53:39 +03:00
|
|
|
map<uint32, Feature> features = 24;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-12-12 10:10:15 +03:00
|
|
|
Indicates if this invoice was a spontaneous payment that arrived via keysend
|
|
|
|
[EXPERIMENTAL].
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
bool is_keysend = 25;
|
2020-11-25 06:05:14 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
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.
|
|
|
|
*/
|
|
|
|
bytes payment_addr = 26;
|
2021-05-06 19:15:33 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
Signals whether or not this is an AMP invoice.
|
|
|
|
*/
|
|
|
|
bool is_amp = 27;
|
2019-08-09 18:28:08 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
enum InvoiceHTLCState {
|
|
|
|
ACCEPTED = 0;
|
|
|
|
SETTLED = 1;
|
2019-10-03 18:22:43 +03:00
|
|
|
CANCELED = 2;
|
2019-08-09 18:28:08 +03:00
|
|
|
}
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Details of an HTLC that paid to an invoice
|
2019-08-09 18:28:08 +03:00
|
|
|
message InvoiceHTLC {
|
2020-05-06 17:51:14 +03:00
|
|
|
// Short channel id over which the htlc was received.
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 chan_id = 1 [jstype = JS_STRING];
|
2019-08-09 18:28:08 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Index identifying the htlc on the channel.
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 htlc_index = 2;
|
2019-08-09 18:28:08 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The amount of the htlc in msat.
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 amt_msat = 3;
|
2019-08-09 18:28:08 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Block height at which this htlc was accepted.
|
2020-02-11 15:53:39 +03:00
|
|
|
int32 accept_height = 4;
|
2019-08-09 18:28:08 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Time at which this htlc was accepted.
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 accept_time = 5;
|
2019-08-09 18:28:08 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Time at which this htlc was settled or canceled.
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 resolve_time = 6;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Block height at which this htlc expires.
|
2020-02-11 15:53:39 +03:00
|
|
|
int32 expiry_height = 7;
|
2019-08-09 18:28:08 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Current state the htlc is in.
|
2020-02-11 15:53:39 +03:00
|
|
|
InvoiceHTLCState state = 8;
|
2019-11-19 15:33:05 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Custom tlv records.
|
2020-02-11 15:53:39 +03:00
|
|
|
map<uint64, bytes> custom_records = 9;
|
2019-09-03 13:23:39 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The total amount of the mpp payment in msat.
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 mpp_total_amt_msat = 10;
|
2021-03-03 21:00:14 +03:00
|
|
|
|
|
|
|
// Details relevant to AMP HTLCs, only populated if this is an AMP HTLC.
|
|
|
|
AMP amp = 11;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Details specific to AMP HTLCs.
|
|
|
|
message AMP {
|
|
|
|
// An n-of-n secret share of the root seed from which child payment hashes
|
|
|
|
// and preimages are derived.
|
|
|
|
bytes root_share = 1;
|
|
|
|
|
|
|
|
// An identifier for the HTLC set that this HTLC belongs to.
|
|
|
|
bytes set_id = 2;
|
|
|
|
|
|
|
|
// A nonce used to randomize the child preimage and child hash from a given
|
|
|
|
// root_share.
|
|
|
|
uint32 child_index = 3;
|
|
|
|
|
|
|
|
// The payment hash of the AMP HTLC.
|
|
|
|
bytes hash = 4;
|
|
|
|
|
|
|
|
// The preimage used to settle this AMP htlc. This field will only be
|
|
|
|
// populated if the invoice is in InvoiceState_ACCEPTED or
|
|
|
|
// InvoiceState_SETTLED.
|
|
|
|
bytes preimage = 5;
|
2016-09-19 21:52:23 +03:00
|
|
|
}
|
2018-12-19 18:03:48 +03:00
|
|
|
|
2016-09-19 21:52:23 +03:00
|
|
|
message AddInvoiceResponse {
|
2020-02-11 15:53:39 +03:00
|
|
|
bytes r_hash = 1;
|
2017-01-03 02:31:38 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-01 11:45:02 +03:00
|
|
|
A bare-bones invoice for a payment within the Lightning Network. With the
|
2017-07-28 02:39:49 +03:00
|
|
|
details of the invoice, the sender has all the data necessary to send a
|
|
|
|
payment to the recipient.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
string payment_request = 2;
|
2018-06-30 04:06:10 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2018-06-30 04:06:10 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 add_index = 16;
|
2020-12-24 16:41:42 +03:00
|
|
|
|
2020-11-25 06:05:14 +03:00
|
|
|
/*
|
|
|
|
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.
|
|
|
|
*/
|
|
|
|
bytes payment_addr = 17;
|
2016-09-19 21:52:23 +03:00
|
|
|
}
|
|
|
|
message PaymentHash {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2017-07-28 02:39:49 +03:00
|
|
|
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.
|
2019-11-01 11:45:02 +03:00
|
|
|
Deprecated now that the REST gateway supports base64 encoding of bytes
|
|
|
|
fields.
|
2017-07-28 02:39:49 +03:00
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
string r_hash_str = 1 [deprecated = true];
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-01 11:45:02 +03:00
|
|
|
The payment hash of the invoice to be looked up. When using REST, this field
|
|
|
|
must be encoded as base64.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
bytes r_hash = 2;
|
2016-09-19 21:52:23 +03:00
|
|
|
}
|
2018-08-11 05:35:38 +03:00
|
|
|
|
2016-09-19 21:52:23 +03:00
|
|
|
message ListInvoiceRequest {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-12-02 15:24:26 +03:00
|
|
|
If set, only invoices that are not settled and not canceled will be returned
|
|
|
|
in the response.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
bool pending_only = 1;
|
2018-08-11 05:35:38 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2018-09-14 00:50:58 +03:00
|
|
|
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.
|
2018-08-11 05:35:38 +03:00
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 index_offset = 4;
|
2018-08-11 05:35:38 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The max number of invoices to return in the response to this query.
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 num_max_invoices = 5;
|
2018-09-11 04:19:06 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2018-09-11 04:19:06 +03:00
|
|
|
If set, the invoices returned will result from seeking backwards from the
|
2018-09-14 00:50:58 +03:00
|
|
|
specified index offset. This can be used to paginate backwards.
|
2018-09-11 04:19:06 +03:00
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
bool reversed = 6;
|
2016-09-19 21:52:23 +03:00
|
|
|
}
|
|
|
|
message ListInvoiceResponse {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2018-08-11 05:35:38 +03:00
|
|
|
A list of invoices from the time slice of the time series specified in the
|
|
|
|
request.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
repeated Invoice invoices = 1;
|
2018-08-11 05:35:38 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2018-09-11 04:19:06 +03:00
|
|
|
The index of the last item in the set of returned invoices. This can be used
|
|
|
|
to seek further, pagination style.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 last_index_offset = 2;
|
2018-09-11 04:19:06 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2018-09-11 04:19:06 +03:00
|
|
|
The index of the last item in the set of returned invoices. This can be used
|
|
|
|
to seek backwards, pagination style.
|
2018-08-11 05:35:38 +03:00
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 first_index_offset = 3;
|
2016-09-19 21:52:23 +03:00
|
|
|
}
|
2016-10-16 00:38:47 +03:00
|
|
|
|
2017-04-12 00:49:39 +03:00
|
|
|
message InvoiceSubscription {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2018-04-25 06:41:22 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 add_index = 1;
|
2018-04-25 06:41:22 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2018-04-25 06:41:22 +03:00
|
|
|
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.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 settle_index = 2;
|
2017-04-12 00:49:39 +03:00
|
|
|
}
|
2016-12-05 14:59:36 +03:00
|
|
|
|
2020-04-06 12:05:25 +03:00
|
|
|
enum PaymentFailureReason {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-04-06 12:05:25 +03:00
|
|
|
Payment isn't failed (yet).
|
|
|
|
*/
|
|
|
|
FAILURE_REASON_NONE = 0;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-04-06 12:05:25 +03:00
|
|
|
There are more routes to try, but the payment timeout was exceeded.
|
|
|
|
*/
|
|
|
|
FAILURE_REASON_TIMEOUT = 1;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-04-06 12:05:25 +03:00
|
|
|
All possible routes were tried and failed permanently. Or were no
|
|
|
|
routes to the destination at all.
|
|
|
|
*/
|
|
|
|
FAILURE_REASON_NO_ROUTE = 2;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-04-06 12:05:25 +03:00
|
|
|
A non-recoverable error has occured.
|
|
|
|
*/
|
|
|
|
FAILURE_REASON_ERROR = 3;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-04-06 12:05:25 +03:00
|
|
|
Payment details incorrect (unknown hash, invalid amt or
|
|
|
|
invalid final cltv delta)
|
|
|
|
*/
|
|
|
|
FAILURE_REASON_INCORRECT_PAYMENT_DETAILS = 4;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-04-06 12:05:25 +03:00
|
|
|
Insufficient local balance.
|
|
|
|
*/
|
|
|
|
FAILURE_REASON_INSUFFICIENT_BALANCE = 5;
|
|
|
|
}
|
|
|
|
|
2016-12-05 14:59:36 +03:00
|
|
|
message Payment {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The payment hash
|
2020-02-11 15:53:39 +03:00
|
|
|
string payment_hash = 1;
|
2017-12-14 04:04:18 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Deprecated, use value_sat or value_msat.
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 value = 2 [deprecated = true];
|
2016-12-05 14:59:36 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Deprecated, use creation_time_ns
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 creation_date = 3 [deprecated = true];
|
2016-12-31 03:38:48 +03:00
|
|
|
|
2020-04-09 17:28:34 +03:00
|
|
|
reserved 4;
|
2016-12-31 03:38:48 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Deprecated, use fee_sat or fee_msat.
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 fee = 5 [deprecated = true];
|
2017-12-14 04:04:18 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The payment preimage
|
2020-02-11 15:53:39 +03:00
|
|
|
string payment_preimage = 6;
|
2018-09-16 15:43:20 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The value of the payment in satoshis
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 value_sat = 7;
|
2018-09-16 15:43:20 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The value of the payment in milli-satoshis
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 value_msat = 8;
|
2019-05-30 02:30:51 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The optional payment request being fulfilled.
|
2020-02-11 15:53:39 +03:00
|
|
|
string payment_request = 9;
|
2019-06-11 15:48:47 +03:00
|
|
|
|
|
|
|
enum PaymentStatus {
|
|
|
|
UNKNOWN = 0;
|
|
|
|
IN_FLIGHT = 1;
|
|
|
|
SUCCEEDED = 2;
|
|
|
|
FAILED = 3;
|
|
|
|
}
|
|
|
|
|
|
|
|
// The status of the payment.
|
2020-02-11 15:53:39 +03:00
|
|
|
PaymentStatus status = 10;
|
2019-07-09 00:38:44 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The fee paid for this payment in satoshis
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 fee_sat = 11;
|
2019-07-09 00:38:44 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The fee paid for this payment in milli-satoshis
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 fee_msat = 12;
|
2019-11-20 07:41:27 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The time in UNIX nanoseconds at which the payment was created.
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 creation_time_ns = 13;
|
2019-11-20 07:41:27 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The HTLCs made in attempt to settle the payment.
|
2020-02-11 15:53:39 +03:00
|
|
|
repeated HTLCAttempt htlcs = 14;
|
2020-01-17 09:35:03 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-01-17 09:35:03 +03:00
|
|
|
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.
|
|
|
|
*/
|
|
|
|
uint64 payment_index = 15;
|
2020-04-06 12:05:25 +03:00
|
|
|
|
|
|
|
PaymentFailureReason failure_reason = 16;
|
2019-11-20 07:41:27 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
message HTLCAttempt {
|
2021-01-25 19:18:30 +03:00
|
|
|
// The unique ID that is used for this attempt.
|
|
|
|
uint64 attempt_id = 7;
|
|
|
|
|
2020-02-11 15:53:39 +03:00
|
|
|
enum HTLCStatus {
|
|
|
|
IN_FLIGHT = 0;
|
|
|
|
SUCCEEDED = 1;
|
|
|
|
FAILED = 2;
|
|
|
|
}
|
2019-11-20 07:41:27 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The status of the HTLC.
|
2020-02-11 15:53:39 +03:00
|
|
|
HTLCStatus status = 1;
|
2019-11-20 07:41:27 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The route taken by this HTLC.
|
2020-02-11 15:53:39 +03:00
|
|
|
Route route = 2;
|
2019-11-20 07:41:27 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The time in UNIX nanoseconds at which this HTLC was sent.
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 attempt_time_ns = 3;
|
2019-11-20 07:41:27 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-02-11 15:53:39 +03:00
|
|
|
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.
|
|
|
|
*/
|
|
|
|
int64 resolve_time_ns = 4;
|
2020-02-19 19:21:03 +03:00
|
|
|
|
|
|
|
// Detailed htlc failure info.
|
|
|
|
Failure failure = 5;
|
2020-04-09 10:51:37 +03:00
|
|
|
|
|
|
|
// The preimage that was used to settle the HTLC.
|
|
|
|
bytes preimage = 6;
|
2016-12-05 14:59:36 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
message ListPaymentsRequest {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-06-14 02:00:38 +03:00
|
|
|
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
|
2020-01-17 09:35:03 +03:00
|
|
|
field is set to true. This flag doesn't change the meaning of the indices,
|
|
|
|
which are tied to individual payments.
|
2019-06-14 02:00:38 +03:00
|
|
|
*/
|
|
|
|
bool include_incomplete = 1;
|
2020-01-17 09:35:03 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-01-17 09:35:03 +03:00
|
|
|
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.
|
|
|
|
*/
|
|
|
|
uint64 index_offset = 2;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The maximal number of payments returned in the response to this query.
|
2020-01-17 09:35:03 +03:00
|
|
|
uint64 max_payments = 3;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-01-17 09:35:03 +03:00
|
|
|
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).
|
|
|
|
*/
|
|
|
|
bool reversed = 4;
|
2016-12-05 14:59:36 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
message ListPaymentsResponse {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The list of payments
|
2020-02-11 15:53:39 +03:00
|
|
|
repeated Payment payments = 1;
|
2020-01-17 09:35:03 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-01-17 09:35:03 +03:00
|
|
|
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.
|
|
|
|
*/
|
|
|
|
uint64 first_index_offset = 2;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-01-17 09:35:03 +03:00
|
|
|
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.
|
|
|
|
*/
|
|
|
|
uint64 last_index_offset = 3;
|
2016-12-05 14:59:36 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
message DeleteAllPaymentsRequest {
|
2019-06-11 16:06:13 +03:00
|
|
|
// Only delete failed payments.
|
|
|
|
bool failed_payments_only = 1;
|
|
|
|
|
|
|
|
/*
|
|
|
|
Only delete failed HTLCs from payments, not the payment itself.
|
|
|
|
*/
|
|
|
|
bool failed_htlcs_only = 2;
|
2016-12-05 14:59:36 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
message DeleteAllPaymentsResponse {
|
2016-12-27 08:44:44 +03:00
|
|
|
}
|
2017-01-15 05:14:03 +03:00
|
|
|
|
2018-05-29 12:26:47 +03:00
|
|
|
message AbandonChannelRequest {
|
|
|
|
ChannelPoint channel_point = 1;
|
2020-08-21 14:08:36 +03:00
|
|
|
|
|
|
|
bool pending_funding_shim_only = 2;
|
2018-05-29 12:26:47 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
message AbandonChannelResponse {
|
|
|
|
}
|
|
|
|
|
2017-01-15 05:14:03 +03:00
|
|
|
message DebugLevelRequest {
|
|
|
|
bool show = 1;
|
|
|
|
string level_spec = 2;
|
|
|
|
}
|
|
|
|
message DebugLevelResponse {
|
2020-02-11 15:53:39 +03:00
|
|
|
string sub_systems = 1;
|
2017-01-15 05:14:03 +03:00
|
|
|
}
|
2017-01-18 00:24:55 +03:00
|
|
|
|
|
|
|
message PayReqString {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The payment request string to be decoded
|
2017-01-18 00:24:55 +03:00
|
|
|
string pay_req = 1;
|
|
|
|
}
|
|
|
|
message PayReq {
|
2020-02-11 15:53:39 +03:00
|
|
|
string destination = 1;
|
|
|
|
string payment_hash = 2;
|
|
|
|
int64 num_satoshis = 3;
|
|
|
|
int64 timestamp = 4;
|
|
|
|
int64 expiry = 5;
|
|
|
|
string description = 6;
|
|
|
|
string description_hash = 7;
|
|
|
|
string fallback_addr = 8;
|
|
|
|
int64 cltv_expiry = 9;
|
|
|
|
repeated RouteHint route_hints = 10;
|
|
|
|
bytes payment_addr = 11;
|
|
|
|
int64 num_msat = 12;
|
|
|
|
map<uint32, Feature> features = 13;
|
2019-12-11 00:09:17 +03:00
|
|
|
}
|
|
|
|
|
2019-12-19 10:57:23 +03:00
|
|
|
enum FeatureBit {
|
2020-02-11 15:53:39 +03:00
|
|
|
DATALOSS_PROTECT_REQ = 0;
|
|
|
|
DATALOSS_PROTECT_OPT = 1;
|
|
|
|
INITIAL_ROUING_SYNC = 3;
|
|
|
|
UPFRONT_SHUTDOWN_SCRIPT_REQ = 4;
|
|
|
|
UPFRONT_SHUTDOWN_SCRIPT_OPT = 5;
|
|
|
|
GOSSIP_QUERIES_REQ = 6;
|
|
|
|
GOSSIP_QUERIES_OPT = 7;
|
|
|
|
TLV_ONION_REQ = 8;
|
|
|
|
TLV_ONION_OPT = 9;
|
|
|
|
EXT_GOSSIP_QUERIES_REQ = 10;
|
|
|
|
EXT_GOSSIP_QUERIES_OPT = 11;
|
|
|
|
STATIC_REMOTE_KEY_REQ = 12;
|
|
|
|
STATIC_REMOTE_KEY_OPT = 13;
|
|
|
|
PAYMENT_ADDR_REQ = 14;
|
|
|
|
PAYMENT_ADDR_OPT = 15;
|
|
|
|
MPP_REQ = 16;
|
|
|
|
MPP_OPT = 17;
|
2021-01-14 22:28:39 +03:00
|
|
|
WUMBO_CHANNELS_REQ = 18;
|
|
|
|
WUMBO_CHANNELS_OPT = 19;
|
|
|
|
ANCHORS_REQ = 20;
|
|
|
|
ANCHORS_OPT = 21;
|
|
|
|
ANCHORS_ZERO_FEE_HTLC_REQ = 22;
|
|
|
|
ANCHORS_ZERO_FEE_HTLC_OPT = 23;
|
2021-03-31 13:58:48 +03:00
|
|
|
AMP_REQ = 30;
|
|
|
|
AMP_OPT = 31;
|
2019-12-19 10:57:23 +03:00
|
|
|
}
|
|
|
|
|
2019-12-11 00:09:17 +03:00
|
|
|
message Feature {
|
2020-02-11 15:53:39 +03:00
|
|
|
string name = 2;
|
|
|
|
bool is_required = 3;
|
|
|
|
bool is_known = 4;
|
2017-01-18 00:24:55 +03:00
|
|
|
}
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-02-11 15:53:39 +03:00
|
|
|
message FeeReportRequest {
|
|
|
|
}
|
2017-08-22 10:07:25 +03:00
|
|
|
message ChannelFeeReport {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The short channel id that this fee report belongs to.
|
2020-03-02 12:59:26 +03:00
|
|
|
uint64 chan_id = 5 [jstype = JS_STRING];
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The channel that this fee report belongs to.
|
2020-02-12 18:13:07 +03:00
|
|
|
string channel_point = 1;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The base fee charged regardless of the number of milli-satoshis sent.
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 base_fee_msat = 2;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The amount charged per milli-satoshis transferred expressed in
|
|
|
|
// millionths of a satoshi.
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 fee_per_mil = 3;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The effective fee rate in milli-satoshis. Computed by dividing the
|
|
|
|
// fee_per_mil value by 1 million.
|
2020-02-11 15:53:39 +03:00
|
|
|
double fee_rate = 4;
|
2017-08-22 10:07:25 +03:00
|
|
|
}
|
|
|
|
message FeeReportResponse {
|
2020-05-06 17:51:14 +03:00
|
|
|
// An array of channel fee reports which describes the current fee schedule
|
|
|
|
// for each channel.
|
2020-02-11 15:53:39 +03:00
|
|
|
repeated ChannelFeeReport channel_fees = 1;
|
2018-02-28 09:20:46 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The total amount of fee revenue (in satoshis) the switch has collected
|
|
|
|
// over the past 24 hrs.
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 day_fee_sum = 2;
|
2018-02-28 09:20:46 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The total amount of fee revenue (in satoshis) the switch has collected
|
|
|
|
// over the past 1 week.
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 week_fee_sum = 3;
|
2018-02-28 09:20:46 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The total amount of fee revenue (in satoshis) the switch has collected
|
|
|
|
// over the past 1 month.
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 month_fee_sum = 4;
|
2017-08-22 10:07:25 +03:00
|
|
|
}
|
|
|
|
|
2017-12-16 00:11:23 +03:00
|
|
|
message PolicyUpdateRequest {
|
2017-08-22 10:07:25 +03:00
|
|
|
oneof scope {
|
2020-05-06 17:51:14 +03:00
|
|
|
// If set, then this update applies to all currently active channels.
|
2020-02-11 15:53:39 +03:00
|
|
|
bool global = 1;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// If set, this update will target a specific channel.
|
2020-02-11 15:53:39 +03:00
|
|
|
ChannelPoint chan_point = 2;
|
2017-08-22 10:07:25 +03:00
|
|
|
}
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The base fee charged regardless of the number of milli-satoshis sent.
|
2020-02-11 15:53:39 +03:00
|
|
|
int64 base_fee_msat = 3;
|
2017-08-22 10:07:25 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The effective fee rate in milli-satoshis. The precision of this value
|
|
|
|
// goes up to 6 decimal places, so 1e-6.
|
2020-02-11 15:53:39 +03:00
|
|
|
double fee_rate = 4;
|
2017-12-16 00:11:23 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The required timelock delta for HTLCs forwarded over the channel.
|
2020-02-11 15:53:39 +03:00
|
|
|
uint32 time_lock_delta = 5;
|
2019-08-20 03:55:30 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// If set, the maximum HTLC size in milli-satoshis. If unset, the maximum
|
|
|
|
// HTLC will be unchanged.
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 max_htlc_msat = 6;
|
2019-11-15 13:24:58 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The minimum HTLC size in milli-satoshis. Only applied if
|
|
|
|
// min_htlc_msat_specified is true.
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 min_htlc_msat = 7;
|
2019-11-15 13:24:58 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// If true, min_htlc_msat is applied.
|
2020-02-11 15:53:39 +03:00
|
|
|
bool min_htlc_msat_specified = 8;
|
2017-08-22 10:07:25 +03:00
|
|
|
}
|
2017-12-16 00:11:23 +03:00
|
|
|
message PolicyUpdateResponse {
|
2017-08-22 10:07:25 +03:00
|
|
|
}
|
2018-02-28 09:22:06 +03:00
|
|
|
|
|
|
|
message ForwardingHistoryRequest {
|
2020-05-06 17:51:14 +03:00
|
|
|
// 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.
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 start_time = 1;
|
2018-02-28 09:22:06 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// 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.
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 end_time = 2;
|
2018-02-28 09:22:06 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// 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.
|
2020-02-11 15:53:39 +03:00
|
|
|
uint32 index_offset = 3;
|
2018-02-28 09:22:06 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The max number of events to return in the response to this query.
|
2020-02-11 15:53:39 +03:00
|
|
|
uint32 num_max_events = 4;
|
2018-02-28 09:22:06 +03:00
|
|
|
}
|
|
|
|
message ForwardingEvent {
|
2020-05-06 17:51:14 +03:00
|
|
|
// Timestamp is the time (unix epoch offset) that this circuit was
|
2021-01-24 18:25:24 +03:00
|
|
|
// completed. Deprecated by timestamp_ns.
|
|
|
|
uint64 timestamp = 1 [deprecated = true];
|
2018-02-28 09:22:06 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The incoming channel ID that carried the HTLC that created the circuit.
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 chan_id_in = 2 [jstype = JS_STRING];
|
2018-02-28 09:22:06 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The outgoing channel ID that carried the preimage that completed the
|
|
|
|
// circuit.
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 chan_id_out = 4 [jstype = JS_STRING];
|
2018-02-28 09:22:06 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The total amount (in satoshis) of the incoming HTLC that created half
|
|
|
|
// the circuit.
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 amt_in = 5;
|
2018-02-28 09:22:06 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The total amount (in satoshis) of the outgoing HTLC that created the
|
|
|
|
// second half of the circuit.
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 amt_out = 6;
|
2018-02-28 09:22:06 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The total fee (in satoshis) that this payment circuit carried.
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 fee = 7;
|
2018-02-28 09:22:06 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The total fee (in milli-satoshis) that this payment circuit carried.
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 fee_msat = 8;
|
2018-11-13 20:22:12 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The total amount (in milli-satoshis) of the incoming HTLC that created
|
|
|
|
// half the circuit.
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 amt_in_msat = 9;
|
2019-10-16 20:50:58 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The total amount (in milli-satoshis) of the outgoing HTLC that created
|
|
|
|
// the second half of the circuit.
|
2020-02-11 15:53:39 +03:00
|
|
|
uint64 amt_out_msat = 10;
|
2019-10-16 20:50:58 +03:00
|
|
|
|
2021-01-24 18:25:24 +03:00
|
|
|
// The number of nanoseconds elapsed since January 1, 1970 UTC when this
|
|
|
|
// circuit was completed.
|
|
|
|
uint64 timestamp_ns = 11;
|
|
|
|
|
2018-02-28 09:22:06 +03:00
|
|
|
// TODO(roasbeef): add settlement latency?
|
|
|
|
// * use FPE on the chan id?
|
|
|
|
// * also list failures?
|
|
|
|
}
|
|
|
|
message ForwardingHistoryResponse {
|
2020-05-06 17:51:14 +03:00
|
|
|
// A list of forwarding events from the time slice of the time series
|
|
|
|
// specified in the request.
|
2020-02-11 15:53:39 +03:00
|
|
|
repeated ForwardingEvent forwarding_events = 1;
|
2018-02-28 09:22:06 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The index of the last time in the set of returned forwarding events. Can
|
|
|
|
// be used to seek further, pagination style.
|
2020-02-11 15:53:39 +03:00
|
|
|
uint32 last_offset_index = 2;
|
2018-02-28 09:22:06 +03:00
|
|
|
}
|
2018-12-10 06:57:57 +03:00
|
|
|
|
|
|
|
message ExportChannelBackupRequest {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The target channel point to obtain a back up for.
|
2018-12-10 06:57:57 +03:00
|
|
|
ChannelPoint chan_point = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
message ChannelBackup {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2018-12-10 06:57:57 +03:00
|
|
|
Identifies the channel that this backup belongs to.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
ChannelPoint chan_point = 1;
|
2018-12-10 06:57:57 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2018-12-10 06:57:57 +03:00
|
|
|
Is an encrypted single-chan backup. this can be passed to
|
2019-05-14 00:31:32 +03:00
|
|
|
RestoreChannelBackups, or the WalletUnlocker Init and Unlock methods in
|
2019-11-01 11:45:02 +03:00
|
|
|
order to trigger the recovery protocol. When using REST, this field must be
|
|
|
|
encoded as base64.
|
2018-12-10 06:57:57 +03:00
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
bytes chan_backup = 2;
|
2018-12-10 06:57:57 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
message MultiChanBackup {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2018-12-10 06:57:57 +03:00
|
|
|
Is the set of all channels that are included in this multi-channel backup.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
repeated ChannelPoint chan_points = 1;
|
2018-12-10 06:57:57 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2018-12-10 06:57:57 +03:00
|
|
|
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
|
2019-11-01 11:45:02 +03:00
|
|
|
safely be replaced with any prior/future versions. When using REST, this
|
|
|
|
field must be encoded as base64.
|
2018-12-10 06:57:57 +03:00
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
bytes multi_chan_backup = 2;
|
2018-12-10 06:57:57 +03:00
|
|
|
}
|
|
|
|
|
2020-02-11 15:53:39 +03:00
|
|
|
message ChanBackupExportRequest {
|
|
|
|
}
|
|
|
|
message ChanBackupSnapshot {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2018-12-10 06:57:57 +03:00
|
|
|
The set of new channels that have been added since the last channel backup
|
|
|
|
snapshot was requested.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
ChannelBackups single_chan_backups = 1;
|
2018-12-10 06:57:57 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2018-12-10 06:57:57 +03:00
|
|
|
A multi-channel backup that covers all open channels currently known to
|
|
|
|
lnd.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
MultiChanBackup multi_chan_backup = 2;
|
2018-12-10 06:57:57 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
message ChannelBackups {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2018-12-10 06:57:57 +03:00
|
|
|
A set of single-chan static channel backups.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
repeated ChannelBackup chan_backups = 1;
|
2018-12-10 06:57:57 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
message RestoreChanBackupRequest {
|
|
|
|
oneof backup {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-01 11:45:02 +03:00
|
|
|
The channels to restore as a list of channel/backup pairs.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
ChannelBackups chan_backups = 1;
|
2018-12-10 06:57:57 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2019-11-01 11:45:02 +03:00
|
|
|
The channels to restore in the packed multi backup format. When using
|
|
|
|
REST, this field must be encoded as base64.
|
|
|
|
*/
|
2020-02-11 15:53:39 +03:00
|
|
|
bytes multi_chan_backup = 2;
|
2018-12-10 06:57:57 +03:00
|
|
|
}
|
|
|
|
}
|
2020-02-11 15:53:39 +03:00
|
|
|
message RestoreBackupResponse {
|
|
|
|
}
|
2018-12-10 06:57:57 +03:00
|
|
|
|
2020-02-11 15:53:39 +03:00
|
|
|
message ChannelBackupSubscription {
|
|
|
|
}
|
2019-03-11 03:53:53 +03:00
|
|
|
|
|
|
|
message VerifyChanBackupResponse {
|
|
|
|
}
|
2019-10-23 14:28:17 +03:00
|
|
|
|
|
|
|
message MacaroonPermission {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The entity a permission grants access to.
|
2020-02-11 15:53:39 +03:00
|
|
|
string entity = 1;
|
2019-10-23 14:28:17 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The action that is granted.
|
2020-02-11 15:53:39 +03:00
|
|
|
string action = 2;
|
2019-10-23 14:28:17 +03:00
|
|
|
}
|
|
|
|
message BakeMacaroonRequest {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The list of permissions the new macaroon should grant.
|
2020-02-11 15:53:39 +03:00
|
|
|
repeated MacaroonPermission permissions = 1;
|
2020-07-23 19:36:42 +03:00
|
|
|
|
|
|
|
// The root key ID used to create the macaroon, must be a positive integer.
|
|
|
|
uint64 root_key_id = 2;
|
2019-10-23 14:28:17 +03:00
|
|
|
}
|
|
|
|
message BakeMacaroonResponse {
|
2020-05-06 17:51:14 +03:00
|
|
|
// The hex encoded macaroon, serialized in binary format.
|
2020-02-11 15:53:39 +03:00
|
|
|
string macaroon = 1;
|
2019-10-23 14:28:17 +03:00
|
|
|
}
|
2020-02-13 13:40:51 +03:00
|
|
|
|
2020-07-23 19:36:42 +03:00
|
|
|
message ListMacaroonIDsRequest {
|
|
|
|
}
|
|
|
|
message ListMacaroonIDsResponse {
|
|
|
|
// The list of root key IDs that are in use.
|
|
|
|
repeated uint64 root_key_ids = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
message DeleteMacaroonIDRequest {
|
|
|
|
// The root key ID to be removed.
|
|
|
|
uint64 root_key_id = 1;
|
|
|
|
}
|
|
|
|
message DeleteMacaroonIDResponse {
|
|
|
|
// A boolean indicates that the deletion is successful.
|
|
|
|
bool deleted = 1;
|
|
|
|
}
|
|
|
|
|
2020-09-04 10:22:38 +03:00
|
|
|
message MacaroonPermissionList {
|
|
|
|
// A list of macaroon permissions.
|
|
|
|
repeated MacaroonPermission permissions = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
message ListPermissionsRequest {
|
|
|
|
}
|
|
|
|
message ListPermissionsResponse {
|
|
|
|
/*
|
|
|
|
A map between all RPC method URIs and their required macaroon permissions to
|
|
|
|
access them.
|
|
|
|
*/
|
|
|
|
map<string, MacaroonPermissionList> method_permissions = 1;
|
|
|
|
}
|
|
|
|
|
2020-02-13 13:40:51 +03:00
|
|
|
message Failure {
|
|
|
|
enum FailureCode {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-02-13 13:40:51 +03:00
|
|
|
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.
|
|
|
|
*/
|
|
|
|
RESERVED = 0;
|
|
|
|
|
|
|
|
INCORRECT_OR_UNKNOWN_PAYMENT_DETAILS = 1;
|
|
|
|
INCORRECT_PAYMENT_AMOUNT = 2;
|
|
|
|
FINAL_INCORRECT_CLTV_EXPIRY = 3;
|
|
|
|
FINAL_INCORRECT_HTLC_AMOUNT = 4;
|
|
|
|
FINAL_EXPIRY_TOO_SOON = 5;
|
|
|
|
INVALID_REALM = 6;
|
|
|
|
EXPIRY_TOO_SOON = 7;
|
|
|
|
INVALID_ONION_VERSION = 8;
|
|
|
|
INVALID_ONION_HMAC = 9;
|
|
|
|
INVALID_ONION_KEY = 10;
|
|
|
|
AMOUNT_BELOW_MINIMUM = 11;
|
|
|
|
FEE_INSUFFICIENT = 12;
|
|
|
|
INCORRECT_CLTV_EXPIRY = 13;
|
|
|
|
CHANNEL_DISABLED = 14;
|
|
|
|
TEMPORARY_CHANNEL_FAILURE = 15;
|
|
|
|
REQUIRED_NODE_FEATURE_MISSING = 16;
|
|
|
|
REQUIRED_CHANNEL_FEATURE_MISSING = 17;
|
|
|
|
UNKNOWN_NEXT_PEER = 18;
|
|
|
|
TEMPORARY_NODE_FAILURE = 19;
|
|
|
|
PERMANENT_NODE_FAILURE = 20;
|
|
|
|
PERMANENT_CHANNEL_FAILURE = 21;
|
|
|
|
EXPIRY_TOO_FAR = 22;
|
|
|
|
MPP_TIMEOUT = 23;
|
2021-03-05 02:02:03 +03:00
|
|
|
INVALID_ONION_PAYLOAD = 24;
|
2020-02-13 13:40:51 +03:00
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-02-19 19:21:03 +03:00
|
|
|
An internal error occurred.
|
|
|
|
*/
|
|
|
|
INTERNAL_FAILURE = 997;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-02-13 13:40:51 +03:00
|
|
|
The error source is known, but the failure itself couldn't be decoded.
|
|
|
|
*/
|
|
|
|
UNKNOWN_FAILURE = 998;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-02-13 13:40:51 +03:00
|
|
|
An unreadable failure result is returned if the received failure message
|
|
|
|
cannot be decrypted. In that case the error source is unknown.
|
|
|
|
*/
|
|
|
|
UNREADABLE_FAILURE = 999;
|
|
|
|
}
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// Failure code as defined in the Lightning spec
|
2020-02-13 13:40:51 +03:00
|
|
|
FailureCode code = 1;
|
|
|
|
|
|
|
|
reserved 2;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// An optional channel update message.
|
2020-02-13 13:40:51 +03:00
|
|
|
ChannelUpdate channel_update = 3;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// A failure type-dependent htlc value.
|
2020-02-13 13:40:51 +03:00
|
|
|
uint64 htlc_msat = 4;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// The sha256 sum of the onion payload.
|
2020-02-13 13:40:51 +03:00
|
|
|
bytes onion_sha_256 = 5;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// A failure type-dependent cltv expiry value.
|
2020-02-13 13:40:51 +03:00
|
|
|
uint32 cltv_expiry = 6;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// A failure type-dependent flags value.
|
2020-02-13 13:40:51 +03:00
|
|
|
uint32 flags = 7;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-02-13 13:40:51 +03:00
|
|
|
The position in the path of the intermediate or final node that generated
|
|
|
|
the failure message. Position zero is the sender node.
|
|
|
|
**/
|
|
|
|
uint32 failure_source_index = 8;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
// A failure type-dependent block height.
|
2020-02-13 13:40:51 +03:00
|
|
|
uint32 height = 9;
|
|
|
|
}
|
|
|
|
|
|
|
|
message ChannelUpdate {
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-02-13 13:40:51 +03:00
|
|
|
The signature that validates the announced data and proves the ownership
|
|
|
|
of node id.
|
|
|
|
*/
|
|
|
|
bytes signature = 1;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-02-13 13:40:51 +03:00
|
|
|
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.
|
|
|
|
*/
|
|
|
|
bytes chain_hash = 2;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-02-13 13:40:51 +03:00
|
|
|
The unique description of the funding transaction.
|
|
|
|
*/
|
|
|
|
uint64 chan_id = 3 [jstype = JS_STRING];
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-02-13 13:40:51 +03:00
|
|
|
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.
|
|
|
|
*/
|
|
|
|
uint32 timestamp = 4;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-02-13 13:40:51 +03:00
|
|
|
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.
|
|
|
|
*/
|
|
|
|
uint32 message_flags = 10;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-02-13 13:40:51 +03:00
|
|
|
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.
|
|
|
|
*/
|
|
|
|
uint32 channel_flags = 5;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-02-13 13:40:51 +03:00
|
|
|
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.
|
|
|
|
*/
|
|
|
|
uint32 time_lock_delta = 6;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-02-13 13:40:51 +03:00
|
|
|
The minimum HTLC value which will be accepted.
|
|
|
|
*/
|
|
|
|
uint64 htlc_minimum_msat = 7;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-02-13 13:40:51 +03:00
|
|
|
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.
|
|
|
|
*/
|
|
|
|
uint32 base_fee = 8;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-02-13 13:40:51 +03:00
|
|
|
The fee rate that will be charged per millionth of a satoshi.
|
|
|
|
*/
|
|
|
|
uint32 fee_rate = 9;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-02-13 13:40:51 +03:00
|
|
|
The maximum HTLC value which will be accepted.
|
|
|
|
*/
|
|
|
|
uint64 htlc_maximum_msat = 11;
|
|
|
|
|
2020-05-06 17:51:14 +03:00
|
|
|
/*
|
2020-02-13 13:40:51 +03:00
|
|
|
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.
|
|
|
|
*/
|
|
|
|
bytes extra_opaque_data = 12;
|
2020-03-04 15:21:28 +03:00
|
|
|
}
|
2020-09-04 10:22:50 +03:00
|
|
|
|
|
|
|
message MacaroonId {
|
|
|
|
bytes nonce = 1;
|
|
|
|
bytes storageId = 2;
|
|
|
|
repeated Op ops = 3;
|
|
|
|
}
|
|
|
|
|
|
|
|
message Op {
|
|
|
|
string entity = 1;
|
|
|
|
repeated string actions = 2;
|
|
|
|
}
|