lnrpc 0.8.0.beta → 0.11.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- checksums.yaml +4 -4
- data/.gitignore +2 -0
- data/Gemfile.lock +3 -3
- data/README.md +28 -16
- data/examples.rb +6 -11
- data/generate-grpc-service-files.sh +30 -0
- data/lib/grpc_services/autopilotrpc/autopilot_pb.rb +48 -0
- data/lib/grpc_services/autopilotrpc/autopilot_services_pb.rb +40 -0
- data/lib/grpc_services/chainrpc/chainnotifier_pb.rb +67 -0
- data/lib/grpc_services/chainrpc/chainnotifier_services_pb.rb +51 -0
- data/lib/grpc_services/invoicesrpc/invoices_pb.rb +48 -0
- data/lib/grpc_services/invoicesrpc/invoices_services_pb.rb +41 -0
- data/lib/grpc_services/lnclipb/lncli_pb.rb +18 -0
- data/lib/grpc_services/routerrpc/router_pb.rb +229 -0
- data/lib/grpc_services/routerrpc/router_services_pb.rb +86 -0
- data/lib/grpc_services/rpc_pb.rb +1265 -0
- data/lib/{lnrpc → grpc_services}/rpc_services_pb.rb +115 -119
- data/lib/grpc_services/signrpc/signer_pb.rb +83 -0
- data/lib/grpc_services/signrpc/signer_services_pb.rb +68 -0
- data/lib/grpc_services/verrpc/verrpc_pb.rb +27 -0
- data/lib/grpc_services/verrpc/verrpc_services_pb.rb +27 -0
- data/lib/grpc_services/walletrpc/walletkit_pb.rb +149 -0
- data/lib/grpc_services/walletrpc/walletkit_services_pb.rb +115 -0
- data/lib/grpc_services/walletunlocker_pb.rb +51 -0
- data/lib/grpc_services/walletunlocker_services_pb.rb +72 -0
- data/lib/grpc_services/watchtowerrpc/watchtower_pb.rb +21 -0
- data/lib/grpc_services/watchtowerrpc/watchtower_services_pb.rb +28 -0
- data/lib/grpc_services/wtclientrpc/wtclient_pb.rb +75 -0
- data/lib/grpc_services/wtclientrpc/wtclient_services_pb.rb +43 -0
- data/lib/lnrpc.rb +19 -3
- data/lib/lnrpc/client.rb +60 -45
- data/lib/lnrpc/grpc_wrapper.rb +43 -0
- data/lib/lnrpc/version.rb +1 -1
- data/lnrpc.gemspec +4 -2
- metadata +35 -11
- data/lib/lnrpc/rpc.proto +0 -2580
- data/lib/lnrpc/rpc_pb.rb +0 -938
@@ -2,19 +2,15 @@
|
|
2
2
|
# Source: rpc.proto for package 'lnrpc'
|
3
3
|
|
4
4
|
require 'grpc'
|
5
|
-
|
5
|
+
require 'rpc_pb'
|
6
6
|
|
7
7
|
module Lnrpc
|
8
|
-
module
|
9
|
-
#
|
8
|
+
module Lightning
|
9
|
+
#
|
10
10
|
# Comments in this file will be directly parsed into the API
|
11
11
|
# Documentation as descriptions of the associated method, message, or field.
|
12
12
|
# These descriptions should go right above the definition of the object, and
|
13
|
-
# can be in either block or
|
14
|
-
#
|
15
|
-
# One edge case exists where a // comment followed by a /// comment in the
|
16
|
-
# next line will cause the description not to show up in the documentation. In
|
17
|
-
# that instance, simply separate the two comments with a blank line.
|
13
|
+
# can be in either block or // comment format.
|
18
14
|
#
|
19
15
|
# An RPC method can be matched to an lncli command by placing a line in the
|
20
16
|
# beginning of the description in exactly the following format:
|
@@ -27,53 +23,7 @@ module Lnrpc
|
|
27
23
|
# this proto file can be found here:
|
28
24
|
# https://github.com/lightninglabs/lightning-api
|
29
25
|
#
|
30
|
-
#
|
31
|
-
# lnd at first startup, and unlock a previously set up wallet.
|
32
|
-
class Service
|
33
|
-
|
34
|
-
include GRPC::GenericService
|
35
|
-
|
36
|
-
self.marshal_class_method = :encode
|
37
|
-
self.unmarshal_class_method = :decode
|
38
|
-
self.service_name = 'lnrpc.WalletUnlocker'
|
39
|
-
|
40
|
-
# *
|
41
|
-
# GenSeed is the first method that should be used to instantiate a new lnd
|
42
|
-
# instance. This method allows a caller to generate a new aezeed cipher seed
|
43
|
-
# given an optional passphrase. If provided, the passphrase will be necessary
|
44
|
-
# to decrypt the cipherseed to expose the internal wallet seed.
|
45
|
-
#
|
46
|
-
# Once the cipherseed is obtained and verified by the user, the InitWallet
|
47
|
-
# method should be used to commit the newly generated seed, and create the
|
48
|
-
# wallet.
|
49
|
-
rpc :GenSeed, GenSeedRequest, GenSeedResponse
|
50
|
-
# *
|
51
|
-
# InitWallet is used when lnd is starting up for the first time to fully
|
52
|
-
# initialize the daemon and its internal wallet. At the very least a wallet
|
53
|
-
# password must be provided. This will be used to encrypt sensitive material
|
54
|
-
# on disk.
|
55
|
-
#
|
56
|
-
# In the case of a recovery scenario, the user can also specify their aezeed
|
57
|
-
# mnemonic and passphrase. If set, then the daemon will use this prior state
|
58
|
-
# to initialize its internal wallet.
|
59
|
-
#
|
60
|
-
# Alternatively, this can be used along with the GenSeed RPC to obtain a
|
61
|
-
# seed, then present it to the user. Once it has been verified by the user,
|
62
|
-
# the seed can be fed into this RPC in order to commit the new wallet.
|
63
|
-
rpc :InitWallet, InitWalletRequest, InitWalletResponse
|
64
|
-
# * lncli: `unlock`
|
65
|
-
# UnlockWallet is used at startup of lnd to provide a password to unlock
|
66
|
-
# the wallet database.
|
67
|
-
rpc :UnlockWallet, UnlockWalletRequest, UnlockWalletResponse
|
68
|
-
# * lncli: `changepassword`
|
69
|
-
# ChangePassword changes the password of the encrypted wallet. This will
|
70
|
-
# automatically unlock the wallet database if successful.
|
71
|
-
rpc :ChangePassword, ChangePasswordRequest, ChangePasswordResponse
|
72
|
-
end
|
73
|
-
|
74
|
-
Stub = Service.rpc_stub_class
|
75
|
-
end
|
76
|
-
module Lightning
|
26
|
+
# Lightning is the main RPC server of the daemon.
|
77
27
|
class Service
|
78
28
|
|
79
29
|
include GRPC::GenericService
|
@@ -82,120 +32,150 @@ module Lnrpc
|
|
82
32
|
self.unmarshal_class_method = :decode
|
83
33
|
self.service_name = 'lnrpc.Lightning'
|
84
34
|
|
85
|
-
#
|
35
|
+
# lncli: `walletbalance`
|
86
36
|
# WalletBalance returns total unspent outputs(confirmed and unconfirmed), all
|
87
37
|
# confirmed unspent outputs and all unconfirmed unspent outputs under control
|
88
38
|
# of the wallet.
|
89
39
|
rpc :WalletBalance, WalletBalanceRequest, WalletBalanceResponse
|
90
|
-
#
|
40
|
+
# lncli: `channelbalance`
|
91
41
|
# ChannelBalance returns the total funds available across all open channels
|
92
42
|
# in satoshis.
|
93
43
|
rpc :ChannelBalance, ChannelBalanceRequest, ChannelBalanceResponse
|
94
|
-
#
|
44
|
+
# lncli: `listchaintxns`
|
95
45
|
# GetTransactions returns a list describing all the known transactions
|
96
46
|
# relevant to the wallet.
|
97
47
|
rpc :GetTransactions, GetTransactionsRequest, TransactionDetails
|
98
|
-
#
|
48
|
+
# lncli: `estimatefee`
|
99
49
|
# EstimateFee asks the chain backend to estimate the fee rate and total fees
|
100
50
|
# for a transaction that pays to multiple specified outputs.
|
51
|
+
#
|
52
|
+
# When using REST, the `AddrToAmount` map type can be set by appending
|
53
|
+
# `&AddrToAmount[<address>]=<amount_to_send>` to the URL. Unfortunately this
|
54
|
+
# map type doesn't appear in the REST API documentation because of a bug in
|
55
|
+
# the grpc-gateway library.
|
101
56
|
rpc :EstimateFee, EstimateFeeRequest, EstimateFeeResponse
|
102
|
-
#
|
57
|
+
# lncli: `sendcoins`
|
103
58
|
# SendCoins executes a request to send coins to a particular address. Unlike
|
104
59
|
# SendMany, this RPC call only allows creating a single output at a time. If
|
105
60
|
# neither target_conf, or sat_per_byte are set, then the internal wallet will
|
106
61
|
# consult its fee model to determine a fee for the default confirmation
|
107
62
|
# target.
|
108
63
|
rpc :SendCoins, SendCoinsRequest, SendCoinsResponse
|
109
|
-
#
|
64
|
+
# lncli: `listunspent`
|
65
|
+
# Deprecated, use walletrpc.ListUnspent instead.
|
66
|
+
#
|
110
67
|
# ListUnspent returns a list of all utxos spendable by the wallet with a
|
111
68
|
# number of confirmations between the specified minimum and maximum.
|
112
69
|
rpc :ListUnspent, ListUnspentRequest, ListUnspentResponse
|
113
|
-
#
|
70
|
+
#
|
114
71
|
# SubscribeTransactions creates a uni-directional stream from the server to
|
115
72
|
# the client in which any newly discovered transactions relevant to the
|
116
73
|
# wallet are sent over.
|
117
74
|
rpc :SubscribeTransactions, GetTransactionsRequest, stream(Transaction)
|
118
|
-
#
|
75
|
+
# lncli: `sendmany`
|
119
76
|
# SendMany handles a request for a transaction that creates multiple specified
|
120
77
|
# outputs in parallel. If neither target_conf, or sat_per_byte are set, then
|
121
78
|
# the internal wallet will consult its fee model to determine a fee for the
|
122
79
|
# default confirmation target.
|
123
80
|
rpc :SendMany, SendManyRequest, SendManyResponse
|
124
|
-
#
|
81
|
+
# lncli: `newaddress`
|
125
82
|
# NewAddress creates a new address under control of the local wallet.
|
126
83
|
rpc :NewAddress, NewAddressRequest, NewAddressResponse
|
127
|
-
#
|
84
|
+
# lncli: `signmessage`
|
128
85
|
# SignMessage signs a message with this node's private key. The returned
|
129
86
|
# signature string is `zbase32` encoded and pubkey recoverable, meaning that
|
130
87
|
# only the message digest and signature are needed for verification.
|
131
88
|
rpc :SignMessage, SignMessageRequest, SignMessageResponse
|
132
|
-
#
|
89
|
+
# lncli: `verifymessage`
|
133
90
|
# VerifyMessage verifies a signature over a msg. The signature must be
|
134
91
|
# zbase32 encoded and signed by an active node in the resident node's
|
135
92
|
# channel database. In addition to returning the validity of the signature,
|
136
93
|
# VerifyMessage also returns the recovered pubkey from the signature.
|
137
94
|
rpc :VerifyMessage, VerifyMessageRequest, VerifyMessageResponse
|
138
|
-
#
|
95
|
+
# lncli: `connect`
|
139
96
|
# ConnectPeer attempts to establish a connection to a remote peer. This is at
|
140
97
|
# the networking level, and is used for communication between nodes. This is
|
141
98
|
# distinct from establishing a channel with a peer.
|
142
99
|
rpc :ConnectPeer, ConnectPeerRequest, ConnectPeerResponse
|
143
|
-
#
|
100
|
+
# lncli: `disconnect`
|
144
101
|
# DisconnectPeer attempts to disconnect one peer from another identified by a
|
145
102
|
# given pubKey. In the case that we currently have a pending or active channel
|
146
103
|
# with the target peer, then this action will be not be allowed.
|
147
104
|
rpc :DisconnectPeer, DisconnectPeerRequest, DisconnectPeerResponse
|
148
|
-
#
|
105
|
+
# lncli: `listpeers`
|
149
106
|
# ListPeers returns a verbose listing of all currently active peers.
|
150
107
|
rpc :ListPeers, ListPeersRequest, ListPeersResponse
|
151
|
-
#
|
108
|
+
#
|
109
|
+
# SubscribePeerEvents creates a uni-directional stream from the server to
|
110
|
+
# the client in which any events relevant to the state of peers are sent
|
111
|
+
# over. Events include peers going online and offline.
|
112
|
+
rpc :SubscribePeerEvents, PeerEventSubscription, stream(PeerEvent)
|
113
|
+
# lncli: `getinfo`
|
152
114
|
# GetInfo returns general information concerning the lightning node including
|
153
115
|
# it's identity pubkey, alias, the chains it is connected to, and information
|
154
116
|
# concerning the number of open+pending channels.
|
155
117
|
rpc :GetInfo, GetInfoRequest, GetInfoResponse
|
118
|
+
# * lncli: `getrecoveryinfo`
|
119
|
+
# GetRecoveryInfo returns information concerning the recovery mode including
|
120
|
+
# whether it's in a recovery mode, whether the recovery is finished, and the
|
121
|
+
# progress made so far.
|
122
|
+
rpc :GetRecoveryInfo, GetRecoveryInfoRequest, GetRecoveryInfoResponse
|
156
123
|
# TODO(roasbeef): merge with below with bool?
|
157
124
|
#
|
158
|
-
#
|
125
|
+
# lncli: `pendingchannels`
|
159
126
|
# PendingChannels returns a list of all the channels that are currently
|
160
127
|
# considered "pending". A channel is pending if it has finished the funding
|
161
128
|
# workflow and is waiting for confirmations for the funding txn, or is in the
|
162
129
|
# process of closure, either initiated cooperatively or non-cooperatively.
|
163
130
|
rpc :PendingChannels, PendingChannelsRequest, PendingChannelsResponse
|
164
|
-
#
|
131
|
+
# lncli: `listchannels`
|
165
132
|
# ListChannels returns a description of all the open channels that this node
|
166
133
|
# is a participant in.
|
167
134
|
rpc :ListChannels, ListChannelsRequest, ListChannelsResponse
|
168
|
-
#
|
135
|
+
#
|
169
136
|
# SubscribeChannelEvents creates a uni-directional stream from the server to
|
170
137
|
# the client in which any updates relevant to the state of the channels are
|
171
138
|
# sent over. Events include new active channels, inactive channels, and closed
|
172
139
|
# channels.
|
173
140
|
rpc :SubscribeChannelEvents, ChannelEventSubscription, stream(ChannelEventUpdate)
|
174
|
-
#
|
141
|
+
# lncli: `closedchannels`
|
175
142
|
# ClosedChannels returns a description of all the closed channels that
|
176
143
|
# this node was a participant in.
|
177
144
|
rpc :ClosedChannels, ClosedChannelsRequest, ClosedChannelsResponse
|
178
|
-
#
|
145
|
+
#
|
179
146
|
# OpenChannelSync is a synchronous version of the OpenChannel RPC call. This
|
180
147
|
# call is meant to be consumed by clients to the REST proxy. As with all
|
181
148
|
# other sync calls, all byte slices are intended to be populated as hex
|
182
149
|
# encoded strings.
|
183
150
|
rpc :OpenChannelSync, OpenChannelRequest, ChannelPoint
|
184
|
-
#
|
151
|
+
# lncli: `openchannel`
|
185
152
|
# OpenChannel attempts to open a singly funded channel specified in the
|
186
153
|
# request to a remote peer. Users are able to specify a target number of
|
187
154
|
# blocks that the funding transaction should be confirmed in, or a manual fee
|
188
155
|
# rate to us for the funding transaction. If neither are specified, then a
|
189
|
-
# lax block confirmation target is used.
|
156
|
+
# lax block confirmation target is used. Each OpenStatusUpdate will return
|
157
|
+
# the pending channel ID of the in-progress channel. Depending on the
|
158
|
+
# arguments specified in the OpenChannelRequest, this pending channel ID can
|
159
|
+
# then be used to manually progress the channel funding flow.
|
190
160
|
rpc :OpenChannel, OpenChannelRequest, stream(OpenStatusUpdate)
|
191
|
-
#
|
161
|
+
#
|
162
|
+
# FundingStateStep is an advanced funding related call that allows the caller
|
163
|
+
# to either execute some preparatory steps for a funding workflow, or
|
164
|
+
# manually progress a funding workflow. The primary way a funding flow is
|
165
|
+
# identified is via its pending channel ID. As an example, this method can be
|
166
|
+
# used to specify that we're expecting a funding flow for a particular
|
167
|
+
# pending channel ID, for which we need to use specific parameters.
|
168
|
+
# Alternatively, this can be used to interactively drive PSBT signing for
|
169
|
+
# funding for partially complete funding transactions.
|
170
|
+
rpc :FundingStateStep, FundingTransitionMsg, FundingStateStepResp
|
171
|
+
#
|
192
172
|
# ChannelAcceptor dispatches a bi-directional streaming RPC in which
|
193
173
|
# OpenChannel requests are sent to the client and the client responds with
|
194
174
|
# a boolean that tells LND whether or not to accept the channel. This allows
|
195
175
|
# node operators to specify their own criteria for accepting inbound channels
|
196
176
|
# through a single persistent connection.
|
197
177
|
rpc :ChannelAcceptor, stream(ChannelAcceptResponse), stream(ChannelAcceptRequest)
|
198
|
-
#
|
178
|
+
# lncli: `closechannel`
|
199
179
|
# CloseChannel attempts to close an active channel identified by its channel
|
200
180
|
# outpoint (ChannelPoint). The actions of this method can additionally be
|
201
181
|
# augmented to attempt a force close after a timeout period in the case of an
|
@@ -204,40 +184,42 @@ module Lnrpc
|
|
204
184
|
# closure transaction is confirmed, or a manual fee rate. If neither are
|
205
185
|
# specified, then a default lax, block confirmation target is used.
|
206
186
|
rpc :CloseChannel, CloseChannelRequest, stream(CloseStatusUpdate)
|
207
|
-
#
|
187
|
+
# lncli: `abandonchannel`
|
208
188
|
# AbandonChannel removes all channel state from the database except for a
|
209
189
|
# close summary. This method can be used to get rid of permanently unusable
|
210
190
|
# channels due to bugs fixed in newer versions of lnd. Only available
|
211
191
|
# when in debug builds of lnd.
|
212
192
|
rpc :AbandonChannel, AbandonChannelRequest, AbandonChannelResponse
|
213
|
-
#
|
214
|
-
# SendPayment dispatches a
|
215
|
-
#
|
216
|
-
#
|
217
|
-
#
|
193
|
+
# lncli: `sendpayment`
|
194
|
+
# Deprecated, use routerrpc.SendPaymentV2. SendPayment dispatches a
|
195
|
+
# bi-directional streaming RPC for sending payments through the Lightning
|
196
|
+
# Network. A single RPC invocation creates a persistent bi-directional
|
197
|
+
# stream allowing clients to rapidly send payments through the Lightning
|
198
|
+
# Network with a single persistent connection.
|
218
199
|
rpc :SendPayment, stream(SendRequest), stream(SendResponse)
|
219
|
-
#
|
200
|
+
#
|
220
201
|
# SendPaymentSync is the synchronous non-streaming version of SendPayment.
|
221
202
|
# This RPC is intended to be consumed by clients of the REST proxy.
|
222
203
|
# Additionally, this RPC expects the destination's public key and the payment
|
223
204
|
# hash (if any) to be encoded as hex strings.
|
224
205
|
rpc :SendPaymentSync, SendRequest, SendResponse
|
225
|
-
#
|
226
|
-
# SendToRoute is a bi-directional
|
227
|
-
#
|
228
|
-
#
|
229
|
-
# like rebalancing, and atomic
|
206
|
+
# lncli: `sendtoroute`
|
207
|
+
# Deprecated, use routerrpc.SendToRouteV2. SendToRoute is a bi-directional
|
208
|
+
# streaming RPC for sending payment through the Lightning Network. This
|
209
|
+
# method differs from SendPayment in that it allows users to specify a full
|
210
|
+
# route manually. This can be used for things like rebalancing, and atomic
|
211
|
+
# swaps.
|
230
212
|
rpc :SendToRoute, stream(SendToRouteRequest), stream(SendResponse)
|
231
|
-
#
|
213
|
+
#
|
232
214
|
# SendToRouteSync is a synchronous version of SendToRoute. It Will block
|
233
215
|
# until the payment either fails or succeeds.
|
234
216
|
rpc :SendToRouteSync, SendToRouteRequest, SendResponse
|
235
|
-
#
|
217
|
+
# lncli: `addinvoice`
|
236
218
|
# AddInvoice attempts to add a new invoice to the invoice database. Any
|
237
219
|
# duplicated invoices are rejected, therefore all invoices *must* have a
|
238
220
|
# unique payment preimage.
|
239
221
|
rpc :AddInvoice, Invoice, AddInvoiceResponse
|
240
|
-
#
|
222
|
+
# lncli: `listinvoices`
|
241
223
|
# ListInvoices returns a list of all the invoices currently stored within the
|
242
224
|
# database. Any active debug invoices are ignored. It has full support for
|
243
225
|
# paginated responses, allowing users to query for specific invoices through
|
@@ -246,67 +228,76 @@ module Lnrpc
|
|
246
228
|
# next request. By default, the first 100 invoices created will be returned.
|
247
229
|
# Backwards pagination is also supported through the Reversed flag.
|
248
230
|
rpc :ListInvoices, ListInvoiceRequest, ListInvoiceResponse
|
249
|
-
#
|
231
|
+
# lncli: `lookupinvoice`
|
250
232
|
# LookupInvoice attempts to look up an invoice according to its payment hash.
|
251
233
|
# The passed payment hash *must* be exactly 32 bytes, if not, an error is
|
252
234
|
# returned.
|
253
235
|
rpc :LookupInvoice, PaymentHash, Invoice
|
254
|
-
#
|
236
|
+
#
|
255
237
|
# SubscribeInvoices returns a uni-directional stream (server -> client) for
|
256
238
|
# notifying the client of newly added/settled invoices. The caller can
|
257
239
|
# optionally specify the add_index and/or the settle_index. If the add_index
|
258
240
|
# is specified, then we'll first start by sending add invoice events for all
|
259
|
-
# invoices with an add_index greater than the specified value.
|
241
|
+
# invoices with an add_index greater than the specified value. If the
|
260
242
|
# settle_index is specified, the next, we'll send out all settle events for
|
261
|
-
# invoices with a settle_index greater than the specified value.
|
243
|
+
# invoices with a settle_index greater than the specified value. One or both
|
262
244
|
# of these fields can be set. If no fields are set, then we'll only send out
|
263
245
|
# the latest add/settle events.
|
264
246
|
rpc :SubscribeInvoices, InvoiceSubscription, stream(Invoice)
|
265
|
-
#
|
247
|
+
# lncli: `decodepayreq`
|
266
248
|
# DecodePayReq takes an encoded payment request string and attempts to decode
|
267
249
|
# it, returning a full description of the conditions encoded within the
|
268
250
|
# payment request.
|
269
251
|
rpc :DecodePayReq, PayReqString, PayReq
|
270
|
-
#
|
252
|
+
# lncli: `listpayments`
|
271
253
|
# ListPayments returns a list of all outgoing payments.
|
272
254
|
rpc :ListPayments, ListPaymentsRequest, ListPaymentsResponse
|
273
|
-
#
|
255
|
+
#
|
274
256
|
# DeleteAllPayments deletes all outgoing payments from DB.
|
275
257
|
rpc :DeleteAllPayments, DeleteAllPaymentsRequest, DeleteAllPaymentsResponse
|
276
|
-
#
|
258
|
+
# lncli: `describegraph`
|
277
259
|
# DescribeGraph returns a description of the latest graph state from the
|
278
260
|
# point of view of the node. The graph information is partitioned into two
|
279
261
|
# components: all the nodes/vertexes, and all the edges that connect the
|
280
|
-
# vertexes themselves.
|
262
|
+
# vertexes themselves. As this is a directed graph, the edges also contain
|
281
263
|
# the node directional specific routing policy which includes: the time lock
|
282
264
|
# delta, fee information, etc.
|
283
265
|
rpc :DescribeGraph, ChannelGraphRequest, ChannelGraph
|
284
|
-
#
|
266
|
+
# lncli: `getnodemetrics`
|
267
|
+
# GetNodeMetrics returns node metrics calculated from the graph. Currently
|
268
|
+
# the only supported metric is betweenness centrality of individual nodes.
|
269
|
+
rpc :GetNodeMetrics, NodeMetricsRequest, NodeMetricsResponse
|
270
|
+
# lncli: `getchaninfo`
|
285
271
|
# GetChanInfo returns the latest authenticated network announcement for the
|
286
272
|
# given channel identified by its channel ID: an 8-byte integer which
|
287
273
|
# uniquely identifies the location of transaction's funding output within the
|
288
274
|
# blockchain.
|
289
275
|
rpc :GetChanInfo, ChanInfoRequest, ChannelEdge
|
290
|
-
#
|
276
|
+
# lncli: `getnodeinfo`
|
291
277
|
# GetNodeInfo returns the latest advertised, aggregated, and authenticated
|
292
278
|
# channel information for the specified node identified by its public key.
|
293
279
|
rpc :GetNodeInfo, NodeInfoRequest, NodeInfo
|
294
|
-
#
|
280
|
+
# lncli: `queryroutes`
|
295
281
|
# QueryRoutes attempts to query the daemon's Channel Router for a possible
|
296
282
|
# route to a target destination capable of carrying a specific amount of
|
297
283
|
# satoshis. The returned route contains the full details required to craft and
|
298
284
|
# send an HTLC, also including the necessary information that should be
|
299
285
|
# present within the Sphinx packet encapsulated within the HTLC.
|
286
|
+
#
|
287
|
+
# When using REST, the `dest_custom_records` map type can be set by appending
|
288
|
+
# `&dest_custom_records[<record_number>]=<record_data_base64_url_encoded>`
|
289
|
+
# to the URL. Unfortunately this map type doesn't appear in the REST API
|
290
|
+
# documentation because of a bug in the grpc-gateway library.
|
300
291
|
rpc :QueryRoutes, QueryRoutesRequest, QueryRoutesResponse
|
301
|
-
#
|
292
|
+
# lncli: `getnetworkinfo`
|
302
293
|
# GetNetworkInfo returns some basic stats about the known channel graph from
|
303
294
|
# the point of view of the node.
|
304
295
|
rpc :GetNetworkInfo, NetworkInfoRequest, NetworkInfo
|
305
|
-
#
|
296
|
+
# lncli: `stop`
|
306
297
|
# StopDaemon will send a shutdown request to the interrupt handler, triggering
|
307
298
|
# a graceful shutdown of the daemon.
|
308
299
|
rpc :StopDaemon, StopRequest, StopResponse
|
309
|
-
#
|
300
|
+
#
|
310
301
|
# SubscribeChannelGraph launches a streaming RPC that allows the caller to
|
311
302
|
# receive notifications upon any changes to the channel graph topology from
|
312
303
|
# the point of view of the responding node. Events notified include: new
|
@@ -314,21 +305,21 @@ module Lnrpc
|
|
314
305
|
# channels being advertised, updates in the routing policy for a directional
|
315
306
|
# channel edge, and when channels are closed on-chain.
|
316
307
|
rpc :SubscribeChannelGraph, GraphTopologySubscription, stream(GraphTopologyUpdate)
|
317
|
-
#
|
308
|
+
# lncli: `debuglevel`
|
318
309
|
# DebugLevel allows a caller to programmatically set the logging verbosity of
|
319
310
|
# lnd. The logging can be targeted according to a coarse daemon-wide logging
|
320
311
|
# level, or in a granular fashion to specify the logging for a target
|
321
312
|
# sub-system.
|
322
313
|
rpc :DebugLevel, DebugLevelRequest, DebugLevelResponse
|
323
|
-
#
|
314
|
+
# lncli: `feereport`
|
324
315
|
# FeeReport allows the caller to obtain a report detailing the current fee
|
325
316
|
# schedule enforced by the node globally for each channel.
|
326
317
|
rpc :FeeReport, FeeReportRequest, FeeReportResponse
|
327
|
-
#
|
318
|
+
# lncli: `updatechanpolicy`
|
328
319
|
# UpdateChannelPolicy allows the caller to update the fee schedule and
|
329
320
|
# channel policies for all channels globally, or a particular channel.
|
330
321
|
rpc :UpdateChannelPolicy, PolicyUpdateRequest, PolicyUpdateResponse
|
331
|
-
#
|
322
|
+
# lncli: `fwdinghistory`
|
332
323
|
# ForwardingHistory allows the caller to query the htlcswitch for a record of
|
333
324
|
# all HTLCs forwarded within the target time range, and integer offset
|
334
325
|
# within that time range. If no time-range is specified, then the first chunk
|
@@ -336,11 +327,11 @@ module Lnrpc
|
|
336
327
|
#
|
337
328
|
# A list of forwarding events are returned. The size of each forwarding event
|
338
329
|
# is 40 bytes, and the max message size able to be returned in gRPC is 4 MiB.
|
339
|
-
# As a result each message can only contain 50k entries.
|
330
|
+
# As a result each message can only contain 50k entries. Each response has
|
340
331
|
# the index offset of the last entry. The index offset can be provided to the
|
341
332
|
# request to allow the caller to skip a series of records.
|
342
333
|
rpc :ForwardingHistory, ForwardingHistoryRequest, ForwardingHistoryResponse
|
343
|
-
#
|
334
|
+
# lncli: `exportchanbackup`
|
344
335
|
# ExportChannelBackup attempts to return an encrypted static channel backup
|
345
336
|
# for the target channel identified by it channel point. The backup is
|
346
337
|
# encrypted with a key generated from the aezeed seed of the user. The
|
@@ -348,25 +339,25 @@ module Lnrpc
|
|
348
339
|
# method once lnd is running, or via the InitWallet and UnlockWallet methods
|
349
340
|
# from the WalletUnlocker service.
|
350
341
|
rpc :ExportChannelBackup, ExportChannelBackupRequest, ChannelBackup
|
351
|
-
#
|
342
|
+
#
|
352
343
|
# ExportAllChannelBackups returns static channel backups for all existing
|
353
344
|
# channels known to lnd. A set of regular singular static channel backups for
|
354
345
|
# each channel are returned. Additionally, a multi-channel backup is returned
|
355
346
|
# as well, which contains a single encrypted blob containing the backups of
|
356
347
|
# each channel.
|
357
348
|
rpc :ExportAllChannelBackups, ChanBackupExportRequest, ChanBackupSnapshot
|
358
|
-
#
|
349
|
+
#
|
359
350
|
# VerifyChanBackup allows a caller to verify the integrity of a channel backup
|
360
351
|
# snapshot. This method will accept either a packed Single or a packed Multi.
|
361
352
|
# Specifying both will result in an error.
|
362
353
|
rpc :VerifyChanBackup, ChanBackupSnapshot, VerifyChanBackupResponse
|
363
|
-
#
|
354
|
+
# lncli: `restorechanbackup`
|
364
355
|
# RestoreChannelBackups accepts a set of singular channel backups, or a
|
365
356
|
# single encrypted multi-chan backup and attempts to recover any funds
|
366
357
|
# remaining within the channel. If we are able to unpack the backup, then the
|
367
358
|
# new channel will be shown under listchannels, as well as pending channels.
|
368
359
|
rpc :RestoreChannelBackups, RestoreChanBackupRequest, RestoreBackupResponse
|
369
|
-
#
|
360
|
+
#
|
370
361
|
# SubscribeChannelBackups allows a client to sub-subscribe to the most up to
|
371
362
|
# date information concerning the state of all channel backups. Each time a
|
372
363
|
# new channel is added, we return the new set of channels, along with a
|
@@ -375,6 +366,11 @@ module Lnrpc
|
|
375
366
|
# ups, but the updated set of encrypted multi-chan backups with the closed
|
376
367
|
# channel(s) removed.
|
377
368
|
rpc :SubscribeChannelBackups, ChannelBackupSubscription, stream(ChanBackupSnapshot)
|
369
|
+
# lncli: `bakemacaroon`
|
370
|
+
# BakeMacaroon allows the creation of a new macaroon with custom read and
|
371
|
+
# write permissions. No first-party caveats are added since this can be done
|
372
|
+
# offline.
|
373
|
+
rpc :BakeMacaroon, BakeMacaroonRequest, BakeMacaroonResponse
|
378
374
|
end
|
379
375
|
|
380
376
|
Stub = Service.rpc_stub_class
|