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.
Files changed (37) hide show
  1. checksums.yaml +4 -4
  2. data/.gitignore +2 -0
  3. data/Gemfile.lock +3 -3
  4. data/README.md +28 -16
  5. data/examples.rb +6 -11
  6. data/generate-grpc-service-files.sh +30 -0
  7. data/lib/grpc_services/autopilotrpc/autopilot_pb.rb +48 -0
  8. data/lib/grpc_services/autopilotrpc/autopilot_services_pb.rb +40 -0
  9. data/lib/grpc_services/chainrpc/chainnotifier_pb.rb +67 -0
  10. data/lib/grpc_services/chainrpc/chainnotifier_services_pb.rb +51 -0
  11. data/lib/grpc_services/invoicesrpc/invoices_pb.rb +48 -0
  12. data/lib/grpc_services/invoicesrpc/invoices_services_pb.rb +41 -0
  13. data/lib/grpc_services/lnclipb/lncli_pb.rb +18 -0
  14. data/lib/grpc_services/routerrpc/router_pb.rb +229 -0
  15. data/lib/grpc_services/routerrpc/router_services_pb.rb +86 -0
  16. data/lib/grpc_services/rpc_pb.rb +1265 -0
  17. data/lib/{lnrpc → grpc_services}/rpc_services_pb.rb +115 -119
  18. data/lib/grpc_services/signrpc/signer_pb.rb +83 -0
  19. data/lib/grpc_services/signrpc/signer_services_pb.rb +68 -0
  20. data/lib/grpc_services/verrpc/verrpc_pb.rb +27 -0
  21. data/lib/grpc_services/verrpc/verrpc_services_pb.rb +27 -0
  22. data/lib/grpc_services/walletrpc/walletkit_pb.rb +149 -0
  23. data/lib/grpc_services/walletrpc/walletkit_services_pb.rb +115 -0
  24. data/lib/grpc_services/walletunlocker_pb.rb +51 -0
  25. data/lib/grpc_services/walletunlocker_services_pb.rb +72 -0
  26. data/lib/grpc_services/watchtowerrpc/watchtower_pb.rb +21 -0
  27. data/lib/grpc_services/watchtowerrpc/watchtower_services_pb.rb +28 -0
  28. data/lib/grpc_services/wtclientrpc/wtclient_pb.rb +75 -0
  29. data/lib/grpc_services/wtclientrpc/wtclient_services_pb.rb +43 -0
  30. data/lib/lnrpc.rb +19 -3
  31. data/lib/lnrpc/client.rb +60 -45
  32. data/lib/lnrpc/grpc_wrapper.rb +43 -0
  33. data/lib/lnrpc/version.rb +1 -1
  34. data/lnrpc.gemspec +4 -2
  35. metadata +35 -11
  36. data/lib/lnrpc/rpc.proto +0 -2580
  37. 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
- require_relative 'rpc_pb'
5
+ require 'rpc_pb'
6
6
 
7
7
  module Lnrpc
8
- module WalletUnlocker
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 /// comment format.
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
- # The WalletUnlocker service is used to set up a wallet password for
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
- # * lncli: `walletbalance`
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
- # * lncli: `channelbalance`
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
- # * lncli: `listchaintxns`
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
- # * lncli: `estimatefee`
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
- # * lncli: `sendcoins`
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
- # * lncli: `listunspent`
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
- # * lncli: `sendmany`
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
- # * lncli: `newaddress`
81
+ # lncli: `newaddress`
125
82
  # NewAddress creates a new address under control of the local wallet.
126
83
  rpc :NewAddress, NewAddressRequest, NewAddressResponse
127
- # * lncli: `signmessage`
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
- # * lncli: `verifymessage`
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
- # * lncli: `connect`
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
- # * lncli: `disconnect`
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
- # * lncli: `listpeers`
105
+ # lncli: `listpeers`
149
106
  # ListPeers returns a verbose listing of all currently active peers.
150
107
  rpc :ListPeers, ListPeersRequest, ListPeersResponse
151
- # * lncli: `getinfo`
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
- # * lncli: `pendingchannels`
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
- # * lncli: `listchannels`
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
- # * lncli: `closedchannels`
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
- # * lncli: `openchannel`
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
- # * lncli: `closechannel`
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
- # * lncli: `abandonchannel`
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
- # * lncli: `sendpayment`
214
- # SendPayment dispatches a bi-directional streaming RPC for sending payments
215
- # through the Lightning Network. A single RPC invocation creates a persistent
216
- # bi-directional stream allowing clients to rapidly send payments through the
217
- # Lightning Network with a single persistent connection.
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
- # * lncli: `sendtoroute`
226
- # SendToRoute is a bi-directional streaming RPC for sending payment through
227
- # the Lightning Network. This method differs from SendPayment in that it
228
- # allows users to specify a full route manually. This can be used for things
229
- # like rebalancing, and atomic swaps.
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
- # * lncli: `addinvoice`
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
- # * lncli: `listinvoices`
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
- # * lncli: `lookupinvoice`
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. If the
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. One or both
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
- # * lncli: `decodepayreq`
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
- # * lncli: `listpayments`
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
- # * lncli: `describegraph`
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. As this is a directed graph, the edges also contain
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
- # * lncli: `getchaninfo`
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
- # * lncli: `getnodeinfo`
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
- # * lncli: `queryroutes`
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
- # * lncli: `getnetworkinfo`
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
- # * lncli: `stop`
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
- # * lncli: `debuglevel`
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
- # * lncli: `feereport`
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
- # * lncli: `updatechanpolicy`
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
- # * lncli: `fwdinghistory`
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. Each response has
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
- # * lncli: `exportchanbackup`
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
- # * lncli: `restorechanbackup`
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