lnrpc 0.8.0.beta.rc1 → 0.11.1

Sign up to get free protection for your applications and to get access to all the features.
Files changed (37) hide show
  1. checksums.yaml +4 -4
  2. data/.gitignore +2 -0
  3. data/Gemfile.lock +17 -17
  4. data/README.md +28 -16
  5. data/examples.rb +13 -6
  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 +117 -121
  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 +62 -46
  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 -2588
  37. data/lib/lnrpc/rpc_pb.rb +0 -939
@@ -5,75 +5,25 @@ require 'grpc'
5
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.
18
- #
13
+ # can be in either block or // comment format.
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:
21
17
  # lncli: `methodname`
22
- #
18
+ #
23
19
  # Failure to specify the exact name of the command will cause documentation
24
20
  # generation to fail.
25
- #
21
+ #
26
22
  # More information on how exactly the gRPC documentation is generated from
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