1
0
mirror of https://github.com/bumi/lnrpc synced 2025-06-19 14:13:46 +00:00
lnrpc/lib/grpc_services/rpc_services_pb.rb
Michael Bumann 404ed3b99e Add support for v0.11 GRPC services
This also refactors the client GRPC wrapper to dynamically load the
request objects.
All GRPC generated client files now live under lib/grpc_services
2020-08-28 14:14:50 +02:00

379 lines
22 KiB
Ruby

# Generated by the protocol buffer compiler. DO NOT EDIT!
# Source: rpc.proto for package 'lnrpc'
require 'grpc'
require 'rpc_pb'
module Lnrpc
module Lightning
#
# 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
# can be in either block or // comment format.
#
# 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`
#
# Failure to specify the exact name of the command will cause documentation
# generation to fail.
#
# More information on how exactly the gRPC documentation is generated from
# this proto file can be found here:
# https://github.com/lightninglabs/lightning-api
#
# Lightning is the main RPC server of the daemon.
class Service
include GRPC::GenericService
self.marshal_class_method = :encode
self.unmarshal_class_method = :decode
self.service_name = 'lnrpc.Lightning'
# lncli: `walletbalance`
# WalletBalance returns total unspent outputs(confirmed and unconfirmed), all
# confirmed unspent outputs and all unconfirmed unspent outputs under control
# of the wallet.
rpc :WalletBalance, WalletBalanceRequest, WalletBalanceResponse
# lncli: `channelbalance`
# ChannelBalance returns the total funds available across all open channels
# in satoshis.
rpc :ChannelBalance, ChannelBalanceRequest, ChannelBalanceResponse
# lncli: `listchaintxns`
# GetTransactions returns a list describing all the known transactions
# relevant to the wallet.
rpc :GetTransactions, GetTransactionsRequest, TransactionDetails
# lncli: `estimatefee`
# EstimateFee asks the chain backend to estimate the fee rate and total fees
# for a transaction that pays to multiple specified outputs.
#
# When using REST, the `AddrToAmount` map type can be set by appending
# `&AddrToAmount[<address>]=<amount_to_send>` to the URL. Unfortunately this
# map type doesn't appear in the REST API documentation because of a bug in
# the grpc-gateway library.
rpc :EstimateFee, EstimateFeeRequest, EstimateFeeResponse
# lncli: `sendcoins`
# SendCoins executes a request to send coins to a particular address. Unlike
# SendMany, this RPC call only allows creating a single output at a time. If
# neither target_conf, or sat_per_byte are set, then the internal wallet will
# consult its fee model to determine a fee for the default confirmation
# target.
rpc :SendCoins, SendCoinsRequest, SendCoinsResponse
# lncli: `listunspent`
# Deprecated, use walletrpc.ListUnspent instead.
#
# ListUnspent returns a list of all utxos spendable by the wallet with a
# number of confirmations between the specified minimum and maximum.
rpc :ListUnspent, ListUnspentRequest, ListUnspentResponse
#
# 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.
rpc :SubscribeTransactions, GetTransactionsRequest, stream(Transaction)
# lncli: `sendmany`
# SendMany handles a request for a transaction that creates multiple specified
# outputs in parallel. If neither target_conf, or sat_per_byte are set, then
# the internal wallet will consult its fee model to determine a fee for the
# default confirmation target.
rpc :SendMany, SendManyRequest, SendManyResponse
# lncli: `newaddress`
# NewAddress creates a new address under control of the local wallet.
rpc :NewAddress, NewAddressRequest, NewAddressResponse
# lncli: `signmessage`
# SignMessage signs a message with this node's private key. The returned
# signature string is `zbase32` encoded and pubkey recoverable, meaning that
# only the message digest and signature are needed for verification.
rpc :SignMessage, SignMessageRequest, SignMessageResponse
# lncli: `verifymessage`
# VerifyMessage verifies a signature over a msg. The signature must be
# zbase32 encoded and signed by an active node in the resident node's
# channel database. In addition to returning the validity of the signature,
# VerifyMessage also returns the recovered pubkey from the signature.
rpc :VerifyMessage, VerifyMessageRequest, VerifyMessageResponse
# lncli: `connect`
# ConnectPeer attempts to establish a connection to a remote peer. This is at
# the networking level, and is used for communication between nodes. This is
# distinct from establishing a channel with a peer.
rpc :ConnectPeer, ConnectPeerRequest, ConnectPeerResponse
# lncli: `disconnect`
# DisconnectPeer attempts to disconnect one peer from another identified by a
# given pubKey. In the case that we currently have a pending or active channel
# with the target peer, then this action will be not be allowed.
rpc :DisconnectPeer, DisconnectPeerRequest, DisconnectPeerResponse
# lncli: `listpeers`
# ListPeers returns a verbose listing of all currently active peers.
rpc :ListPeers, ListPeersRequest, ListPeersResponse
#
# 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, stream(PeerEvent)
# lncli: `getinfo`
# GetInfo returns general information concerning the lightning node including
# it's identity pubkey, alias, the chains it is connected to, and information
# concerning the number of open+pending channels.
rpc :GetInfo, GetInfoRequest, GetInfoResponse
# * 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, GetRecoveryInfoResponse
# TODO(roasbeef): merge with below with bool?
#
# lncli: `pendingchannels`
# PendingChannels returns a list of all the channels that are currently
# considered "pending". A channel is pending if it has finished the funding
# workflow and is waiting for confirmations for the funding txn, or is in the
# process of closure, either initiated cooperatively or non-cooperatively.
rpc :PendingChannels, PendingChannelsRequest, PendingChannelsResponse
# lncli: `listchannels`
# ListChannels returns a description of all the open channels that this node
# is a participant in.
rpc :ListChannels, ListChannelsRequest, ListChannelsResponse
#
# 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.
rpc :SubscribeChannelEvents, ChannelEventSubscription, stream(ChannelEventUpdate)
# lncli: `closedchannels`
# ClosedChannels returns a description of all the closed channels that
# this node was a participant in.
rpc :ClosedChannels, ClosedChannelsRequest, ClosedChannelsResponse
#
# 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.
rpc :OpenChannelSync, OpenChannelRequest, ChannelPoint
# lncli: `openchannel`
# OpenChannel attempts to open a singly funded channel specified in the
# request to a remote peer. Users are able to specify a target number of
# blocks that the funding transaction should be confirmed in, or a manual fee
# rate to us for the funding transaction. If neither are specified, then a
# lax block confirmation target is used. Each OpenStatusUpdate will return
# the pending channel ID of the in-progress channel. Depending on the
# arguments specified in the OpenChannelRequest, this pending channel ID can
# then be used to manually progress the channel funding flow.
rpc :OpenChannel, OpenChannelRequest, stream(OpenStatusUpdate)
#
# 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.
rpc :FundingStateStep, FundingTransitionMsg, FundingStateStepResp
#
# 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.
rpc :ChannelAcceptor, stream(ChannelAcceptResponse), stream(ChannelAcceptRequest)
# lncli: `closechannel`
# CloseChannel attempts to close an active channel identified by its channel
# outpoint (ChannelPoint). The actions of this method can additionally be
# augmented to attempt a force close after a timeout period in the case of an
# inactive peer. If a non-force close (cooperative closure) is requested,
# then the user can specify either a target number of blocks until the
# closure transaction is confirmed, or a manual fee rate. If neither are
# specified, then a default lax, block confirmation target is used.
rpc :CloseChannel, CloseChannelRequest, stream(CloseStatusUpdate)
# lncli: `abandonchannel`
# AbandonChannel removes all channel state from the database except for a
# close summary. This method can be used to get rid of permanently unusable
# channels due to bugs fixed in newer versions of lnd. Only available
# when in debug builds of lnd.
rpc :AbandonChannel, AbandonChannelRequest, AbandonChannelResponse
# lncli: `sendpayment`
# Deprecated, use routerrpc.SendPaymentV2. SendPayment dispatches a
# bi-directional streaming RPC for sending payments through the Lightning
# Network. A single RPC invocation creates a persistent bi-directional
# stream allowing clients to rapidly send payments through the Lightning
# Network with a single persistent connection.
rpc :SendPayment, stream(SendRequest), stream(SendResponse)
#
# 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.
rpc :SendPaymentSync, SendRequest, SendResponse
# lncli: `sendtoroute`
# Deprecated, use routerrpc.SendToRouteV2. SendToRoute is a bi-directional
# streaming RPC for sending payment through the Lightning Network. This
# method differs from SendPayment in that it allows users to specify a full
# route manually. This can be used for things like rebalancing, and atomic
# swaps.
rpc :SendToRoute, stream(SendToRouteRequest), stream(SendResponse)
#
# SendToRouteSync is a synchronous version of SendToRoute. It Will block
# until the payment either fails or succeeds.
rpc :SendToRouteSync, SendToRouteRequest, SendResponse
# lncli: `addinvoice`
# AddInvoice attempts to add a new invoice to the invoice database. Any
# duplicated invoices are rejected, therefore all invoices *must* have a
# unique payment preimage.
rpc :AddInvoice, Invoice, AddInvoiceResponse
# lncli: `listinvoices`
# ListInvoices returns a list of all the invoices currently stored within the
# database. Any active debug invoices are ignored. It has full support for
# paginated responses, allowing users to query for specific invoices through
# their add_index. This can be done by using either the first_index_offset or
# last_index_offset fields included in the response as the index_offset of the
# next request. By default, the first 100 invoices created will be returned.
# Backwards pagination is also supported through the Reversed flag.
rpc :ListInvoices, ListInvoiceRequest, ListInvoiceResponse
# lncli: `lookupinvoice`
# LookupInvoice attempts to look up an invoice according to its payment hash.
# The passed payment hash *must* be exactly 32 bytes, if not, an error is
# returned.
rpc :LookupInvoice, PaymentHash, Invoice
#
# SubscribeInvoices returns a uni-directional stream (server -> client) for
# notifying the client of newly added/settled invoices. The caller can
# optionally specify the add_index and/or the settle_index. If the add_index
# is specified, then we'll first start by sending add invoice events for all
# invoices with an add_index greater than the specified value. If the
# settle_index is specified, the next, we'll send out all settle events for
# invoices with a settle_index greater than the specified value. One or both
# of these fields can be set. If no fields are set, then we'll only send out
# the latest add/settle events.
rpc :SubscribeInvoices, InvoiceSubscription, stream(Invoice)
# lncli: `decodepayreq`
# DecodePayReq takes an encoded payment request string and attempts to decode
# it, returning a full description of the conditions encoded within the
# payment request.
rpc :DecodePayReq, PayReqString, PayReq
# lncli: `listpayments`
# ListPayments returns a list of all outgoing payments.
rpc :ListPayments, ListPaymentsRequest, ListPaymentsResponse
#
# DeleteAllPayments deletes all outgoing payments from DB.
rpc :DeleteAllPayments, DeleteAllPaymentsRequest, DeleteAllPaymentsResponse
# lncli: `describegraph`
# DescribeGraph returns a description of the latest graph state from the
# point of view of the node. The graph information is partitioned into two
# components: all the nodes/vertexes, and all the edges that connect the
# vertexes themselves. As this is a directed graph, the edges also contain
# the node directional specific routing policy which includes: the time lock
# delta, fee information, etc.
rpc :DescribeGraph, ChannelGraphRequest, ChannelGraph
# lncli: `getnodemetrics`
# GetNodeMetrics returns node metrics calculated from the graph. Currently
# the only supported metric is betweenness centrality of individual nodes.
rpc :GetNodeMetrics, NodeMetricsRequest, NodeMetricsResponse
# lncli: `getchaninfo`
# GetChanInfo returns the latest authenticated network announcement for the
# given channel identified by its channel ID: an 8-byte integer which
# uniquely identifies the location of transaction's funding output within the
# blockchain.
rpc :GetChanInfo, ChanInfoRequest, ChannelEdge
# lncli: `getnodeinfo`
# GetNodeInfo returns the latest advertised, aggregated, and authenticated
# channel information for the specified node identified by its public key.
rpc :GetNodeInfo, NodeInfoRequest, NodeInfo
# lncli: `queryroutes`
# QueryRoutes attempts to query the daemon's Channel Router for a possible
# route to a target destination capable of carrying a specific amount of
# satoshis. The returned route contains the full details required to craft and
# send an HTLC, also including the necessary information that should be
# present within the Sphinx packet encapsulated within the HTLC.
#
# When using REST, the `dest_custom_records` map type can be set by appending
# `&dest_custom_records[<record_number>]=<record_data_base64_url_encoded>`
# to the URL. Unfortunately this map type doesn't appear in the REST API
# documentation because of a bug in the grpc-gateway library.
rpc :QueryRoutes, QueryRoutesRequest, QueryRoutesResponse
# lncli: `getnetworkinfo`
# GetNetworkInfo returns some basic stats about the known channel graph from
# the point of view of the node.
rpc :GetNetworkInfo, NetworkInfoRequest, NetworkInfo
# lncli: `stop`
# StopDaemon will send a shutdown request to the interrupt handler, triggering
# a graceful shutdown of the daemon.
rpc :StopDaemon, StopRequest, StopResponse
#
# 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.
rpc :SubscribeChannelGraph, GraphTopologySubscription, stream(GraphTopologyUpdate)
# lncli: `debuglevel`
# DebugLevel allows a caller to programmatically set the logging verbosity of
# lnd. The logging can be targeted according to a coarse daemon-wide logging
# level, or in a granular fashion to specify the logging for a target
# sub-system.
rpc :DebugLevel, DebugLevelRequest, DebugLevelResponse
# lncli: `feereport`
# FeeReport allows the caller to obtain a report detailing the current fee
# schedule enforced by the node globally for each channel.
rpc :FeeReport, FeeReportRequest, FeeReportResponse
# lncli: `updatechanpolicy`
# UpdateChannelPolicy allows the caller to update the fee schedule and
# channel policies for all channels globally, or a particular channel.
rpc :UpdateChannelPolicy, PolicyUpdateRequest, PolicyUpdateResponse
# lncli: `fwdinghistory`
# ForwardingHistory allows the caller to query the htlcswitch for a record of
# all HTLCs forwarded within the target time range, and integer offset
# within that time range. If no time-range is specified, then the first chunk
# of the past 24 hrs of forwarding history are returned.
#
# A list of forwarding events are returned. The size of each forwarding event
# is 40 bytes, and the max message size able to be returned in gRPC is 4 MiB.
# As a result each message can only contain 50k entries. Each response has
# the index offset of the last entry. The index offset can be provided to the
# request to allow the caller to skip a series of records.
rpc :ForwardingHistory, ForwardingHistoryRequest, ForwardingHistoryResponse
# lncli: `exportchanbackup`
# ExportChannelBackup attempts to return an encrypted static channel backup
# for the target channel identified by it channel point. The backup is
# encrypted with a key generated from the aezeed seed of the user. The
# returned backup can either be restored using the RestoreChannelBackup
# method once lnd is running, or via the InitWallet and UnlockWallet methods
# from the WalletUnlocker service.
rpc :ExportChannelBackup, ExportChannelBackupRequest, ChannelBackup
#
# 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.
rpc :ExportAllChannelBackups, ChanBackupExportRequest, ChanBackupSnapshot
#
# 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.
rpc :VerifyChanBackup, ChanBackupSnapshot, VerifyChanBackupResponse
# lncli: `restorechanbackup`
# RestoreChannelBackups accepts a set of singular channel backups, or a
# single encrypted multi-chan backup and attempts to recover any funds
# remaining within the channel. If we are able to unpack the backup, then the
# new channel will be shown under listchannels, as well as pending channels.
rpc :RestoreChannelBackups, RestoreChanBackupRequest, RestoreBackupResponse
#
# 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.
rpc :SubscribeChannelBackups, ChannelBackupSubscription, stream(ChanBackupSnapshot)
# lncli: `bakemacaroon`
# BakeMacaroon allows the creation of a new macaroon with custom read and
# write permissions. No first-party caveats are added since this can be done
# offline.
rpc :BakeMacaroon, BakeMacaroonRequest, BakeMacaroonResponse
end
Stub = Service.rpc_stub_class
end
end