akovalenko/lnd.xprv
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
a92017fe9a
lnd.xprv/lnrpc/rpc.swagger.json

991 lines
21 KiB
JSON
Raw Normal View History

lnrpc: add cursory REST support to the RPC server This commit adds a REST interface to the existing gRPC server by employing a simple http proxy auto-generated from the existing protobuf files. Currently full-support for any streaming RPC’s are currently untested. In addition to auto-generating a REST proxy server, a swagger.json is also generated which allows for gRPC-like native objects with higher-level clients, and also for auto-generated documentation. Due to limitations with accepting raw byte strings as parameters, some RPC’s have been modified to take both raw-bytes and string arguments. Additionally a new RPC has been added ‘NewWitnessAddress’ since the proxy doesn’t currently support enum-based arguments. Currently the proxy server is embedded within the daemon as an active HTTP server, however we may want to package the proxy server as a separate binary in the future. Similarly, we may want to add additional configuration information which controls the optional inclusion of the REST proxy. Atm, just like the current gRPC interface, the REST API is fully unauthenticated. Before moving to an initial alpha release after making the necessary changes to meet the spec drafted in Milan, authentication of the RPC interfaces will be addressed.
2016-10-16 00:38:47 +03:00
{
"swagger": "2.0",
"info": {
"title": "rpc.proto",
"version": "version not set"
},
"schemes": [
"http",
"https"
],
"consumes": [
"application/json"
],
"produces": [
"application/json"
],
"paths": {
"/v1/balance/blockchain": {
"get": {
"operationId": "WalletBalance",
"responses": {
"200": {
"description": "",
"schema": {
"$ref": "#/definitions/lnrpcWalletBalanceResponse"
}
}
},
"tags": [
"Lightning"
]
}
},
"/v1/balance/channels": {
"get": {
"operationId": "ChannelBalance",
"responses": {
"200": {
"description": "",
"schema": {
"$ref": "#/definitions/lnrpcChannelBalanceResponse"
}
}
},
"tags": [
"Lightning"
]
}
},
"/v1/channels": {
"get": {
"operationId": "ListChannels",
"responses": {
"200": {
"description": "",
"schema": {
"$ref": "#/definitions/lnrpcListChannelsResponse"
}
}
},
"tags": [
"Lightning"
]
},
"post": {
lnrpc: add synchronous versions of SendPayment and OpenChannel This commit adds synchronous version of the RPC’s to send payments over channels and open new channels. The previous async versions of these RPC calls have been removed from the REST interface. Additionally for these two RPC calls any field which accepted byte slices now also accept a variant of the field which is a hex-encoded string. The OpenChannelSync RPC is intended to be used along with either the ListChannels or PendingChannels RPC to poll for a channels existence or non-existence as a signal that the channel is finally open.
2016-11-11 04:33:24 +03:00
"operationId": "OpenChannelSync",
lnrpc: add cursory REST support to the RPC server This commit adds a REST interface to the existing gRPC server by employing a simple http proxy auto-generated from the existing protobuf files. Currently full-support for any streaming RPC’s are currently untested. In addition to auto-generating a REST proxy server, a swagger.json is also generated which allows for gRPC-like native objects with higher-level clients, and also for auto-generated documentation. Due to limitations with accepting raw byte strings as parameters, some RPC’s have been modified to take both raw-bytes and string arguments. Additionally a new RPC has been added ‘NewWitnessAddress’ since the proxy doesn’t currently support enum-based arguments. Currently the proxy server is embedded within the daemon as an active HTTP server, however we may want to package the proxy server as a separate binary in the future. Similarly, we may want to add additional configuration information which controls the optional inclusion of the REST proxy. Atm, just like the current gRPC interface, the REST API is fully unauthenticated. Before moving to an initial alpha release after making the necessary changes to meet the spec drafted in Milan, authentication of the RPC interfaces will be addressed.
2016-10-16 00:38:47 +03:00
"responses": {
"200": {
lnrpc: add synchronous versions of SendPayment and OpenChannel This commit adds synchronous version of the RPC’s to send payments over channels and open new channels. The previous async versions of these RPC calls have been removed from the REST interface. Additionally for these two RPC calls any field which accepted byte slices now also accept a variant of the field which is a hex-encoded string. The OpenChannelSync RPC is intended to be used along with either the ListChannels or PendingChannels RPC to poll for a channels existence or non-existence as a signal that the channel is finally open.
2016-11-11 04:33:24 +03:00
"description": "",
lnrpc: add cursory REST support to the RPC server This commit adds a REST interface to the existing gRPC server by employing a simple http proxy auto-generated from the existing protobuf files. Currently full-support for any streaming RPC’s are currently untested. In addition to auto-generating a REST proxy server, a swagger.json is also generated which allows for gRPC-like native objects with higher-level clients, and also for auto-generated documentation. Due to limitations with accepting raw byte strings as parameters, some RPC’s have been modified to take both raw-bytes and string arguments. Additionally a new RPC has been added ‘NewWitnessAddress’ since the proxy doesn’t currently support enum-based arguments. Currently the proxy server is embedded within the daemon as an active HTTP server, however we may want to package the proxy server as a separate binary in the future. Similarly, we may want to add additional configuration information which controls the optional inclusion of the REST proxy. Atm, just like the current gRPC interface, the REST API is fully unauthenticated. Before moving to an initial alpha release after making the necessary changes to meet the spec drafted in Milan, authentication of the RPC interfaces will be addressed.
2016-10-16 00:38:47 +03:00
"schema": {
lnrpc: add synchronous versions of SendPayment and OpenChannel This commit adds synchronous version of the RPC’s to send payments over channels and open new channels. The previous async versions of these RPC calls have been removed from the REST interface. Additionally for these two RPC calls any field which accepted byte slices now also accept a variant of the field which is a hex-encoded string. The OpenChannelSync RPC is intended to be used along with either the ListChannels or PendingChannels RPC to poll for a channels existence or non-existence as a signal that the channel is finally open.
2016-11-11 04:33:24 +03:00
"$ref": "#/definitions/lnrpcChannelPoint"
lnrpc: add cursory REST support to the RPC server This commit adds a REST interface to the existing gRPC server by employing a simple http proxy auto-generated from the existing protobuf files. Currently full-support for any streaming RPC’s are currently untested. In addition to auto-generating a REST proxy server, a swagger.json is also generated which allows for gRPC-like native objects with higher-level clients, and also for auto-generated documentation. Due to limitations with accepting raw byte strings as parameters, some RPC’s have been modified to take both raw-bytes and string arguments. Additionally a new RPC has been added ‘NewWitnessAddress’ since the proxy doesn’t currently support enum-based arguments. Currently the proxy server is embedded within the daemon as an active HTTP server, however we may want to package the proxy server as a separate binary in the future. Similarly, we may want to add additional configuration information which controls the optional inclusion of the REST proxy. Atm, just like the current gRPC interface, the REST API is fully unauthenticated. Before moving to an initial alpha release after making the necessary changes to meet the spec drafted in Milan, authentication of the RPC interfaces will be addressed.
2016-10-16 00:38:47 +03:00
}
}
},
"parameters": [
{
"name": "body",
"in": "body",
"required": true,
"schema": {
"$ref": "#/definitions/lnrpcOpenChannelRequest"
}
}
],
"tags": [
"Lightning"
]
}
},
"/v1/channels/pending": {
"get": {
"operationId": "PendingChannels",
"responses": {
"200": {
"description": "",
"schema": {
"$ref": "#/definitions/lnrpcPendingChannelResponse"
}
}
},
"tags": [
"Lightning"
]
}
},
"/v1/channels/transactions": {
"post": {
lnrpc: add synchronous versions of SendPayment and OpenChannel This commit adds synchronous version of the RPC’s to send payments over channels and open new channels. The previous async versions of these RPC calls have been removed from the REST interface. Additionally for these two RPC calls any field which accepted byte slices now also accept a variant of the field which is a hex-encoded string. The OpenChannelSync RPC is intended to be used along with either the ListChannels or PendingChannels RPC to poll for a channels existence or non-existence as a signal that the channel is finally open.
2016-11-11 04:33:24 +03:00
"operationId": "SendPaymentSync",
lnrpc: add cursory REST support to the RPC server This commit adds a REST interface to the existing gRPC server by employing a simple http proxy auto-generated from the existing protobuf files. Currently full-support for any streaming RPC’s are currently untested. In addition to auto-generating a REST proxy server, a swagger.json is also generated which allows for gRPC-like native objects with higher-level clients, and also for auto-generated documentation. Due to limitations with accepting raw byte strings as parameters, some RPC’s have been modified to take both raw-bytes and string arguments. Additionally a new RPC has been added ‘NewWitnessAddress’ since the proxy doesn’t currently support enum-based arguments. Currently the proxy server is embedded within the daemon as an active HTTP server, however we may want to package the proxy server as a separate binary in the future. Similarly, we may want to add additional configuration information which controls the optional inclusion of the REST proxy. Atm, just like the current gRPC interface, the REST API is fully unauthenticated. Before moving to an initial alpha release after making the necessary changes to meet the spec drafted in Milan, authentication of the RPC interfaces will be addressed.
2016-10-16 00:38:47 +03:00
"responses": {
"200": {
lnrpc: add synchronous versions of SendPayment and OpenChannel This commit adds synchronous version of the RPC’s to send payments over channels and open new channels. The previous async versions of these RPC calls have been removed from the REST interface. Additionally for these two RPC calls any field which accepted byte slices now also accept a variant of the field which is a hex-encoded string. The OpenChannelSync RPC is intended to be used along with either the ListChannels or PendingChannels RPC to poll for a channels existence or non-existence as a signal that the channel is finally open.
2016-11-11 04:33:24 +03:00
"description": "",
lnrpc: add cursory REST support to the RPC server This commit adds a REST interface to the existing gRPC server by employing a simple http proxy auto-generated from the existing protobuf files. Currently full-support for any streaming RPC’s are currently untested. In addition to auto-generating a REST proxy server, a swagger.json is also generated which allows for gRPC-like native objects with higher-level clients, and also for auto-generated documentation. Due to limitations with accepting raw byte strings as parameters, some RPC’s have been modified to take both raw-bytes and string arguments. Additionally a new RPC has been added ‘NewWitnessAddress’ since the proxy doesn’t currently support enum-based arguments. Currently the proxy server is embedded within the daemon as an active HTTP server, however we may want to package the proxy server as a separate binary in the future. Similarly, we may want to add additional configuration information which controls the optional inclusion of the REST proxy. Atm, just like the current gRPC interface, the REST API is fully unauthenticated. Before moving to an initial alpha release after making the necessary changes to meet the spec drafted in Milan, authentication of the RPC interfaces will be addressed.
2016-10-16 00:38:47 +03:00
"schema": {
"$ref": "#/definitions/lnrpcSendResponse"
}
}
},
"parameters": [
{
"name": "body",
"in": "body",
"required": true,
"schema": {
"$ref": "#/definitions/lnrpcSendRequest"
}
}
],
"tags": [
"Lightning"
]
}
},
"/v1/channels/{channel_point.funding_txid}/{channel_point.output_index}/{force}": {
"delete": {
"summary": "TODO(roasbeef): merge with below with bool?",
"operationId": "CloseChannel",
"responses": {
"200": {
"description": "(streaming responses)",
"schema": {
"$ref": "#/definitions/lnrpcCloseStatusUpdate"
}
}
},
"parameters": [
{
"name": "channel_point.funding_txid",
"in": "path",
"required": true,
"type": "string",
"format": "byte"
},
{
"name": "channel_point.output_index",
"in": "path",
"required": true,
"type": "integer",
"format": "int64"
},
{
"name": "force",
"in": "path",
"required": true,
"type": "boolean",
"format": "boolean"
}
],
"tags": [
"Lightning"
]
}
},
"/v1/getinfo": {
"get": {
"operationId": "GetInfo",
"responses": {
"200": {
"description": "",
"schema": {
"$ref": "#/definitions/lnrpcGetInfoResponse"
}
}
},
"tags": [
"Lightning"
]
}
},
"/v1/invoices": {
"post": {
"operationId": "AddInvoice",
"responses": {
"200": {
"description": "",
"schema": {
"$ref": "#/definitions/lnrpcAddInvoiceResponse"
}
}
},
"parameters": [
{
"name": "body",
"in": "body",
"required": true,
"schema": {
"$ref": "#/definitions/lnrpcInvoice"
}
}
],
"tags": [
"Lightning"
]
}
},
"/v1/invoices/subscribe": {
"get": {
"operationId": "SubscribeInvoices",
"responses": {
"200": {
"description": "(streaming responses)",
"schema": {
"$ref": "#/definitions/lnrpcInvoice"
}
}
},
"tags": [
"Lightning"
]
}
},
"/v1/invoices/{pending_only}": {
"get": {
"operationId": "ListInvoices",
"responses": {
"200": {
"description": "",
"schema": {
"$ref": "#/definitions/lnrpcListInvoiceResponse"
}
}
},
"parameters": [
{
"name": "pending_only",
"in": "path",
"required": true,
"type": "boolean",
"format": "boolean"
}
],
"tags": [
"Lightning"
]
}
},
"/v1/invoices/{r_hash_str}": {
"get": {
"operationId": "LookupInvoice",
"responses": {
"200": {
"description": "",
"schema": {
"$ref": "#/definitions/lnrpcInvoice"
}
}
},
"parameters": [
{
"name": "r_hash_str",
"in": "path",
"required": true,
"type": "string",
"format": "string"
}
],
"tags": [
"Lightning"
]
}
},
"/v1/newaddress": {
"get": {
"operationId": "NewWitnessAddress",
"responses": {
"200": {
"description": "",
"schema": {
"$ref": "#/definitions/lnrpcNewAddressResponse"
}
}
},
"tags": [
"Lightning"
]
}
},
"/v1/peers": {
"get": {
"operationId": "ListPeers",
"responses": {
"200": {
"description": "",
"schema": {
"$ref": "#/definitions/lnrpcListPeersResponse"
}
}
},
"tags": [
"Lightning"
]
},
"post": {
"operationId": "ConnectPeer",
"responses": {
"200": {
"description": "",
"schema": {
"$ref": "#/definitions/lnrpcConnectPeerResponse"
}
}
},
"parameters": [
{
"name": "body",
"in": "body",
"required": true,
"schema": {
"$ref": "#/definitions/lnrpcConnectPeerRequest"
}
}
],
"tags": [
"Lightning"
]
}
},
"/v1/transactions": {
"get": {
"operationId": "GetTransactions",
"responses": {
"200": {
"description": "",
"schema": {
"$ref": "#/definitions/lnrpcTransactionDetails"
}
}
},
"tags": [
"Lightning"
]
},
"post": {
"operationId": "SendCoins",
"responses": {
"200": {
"description": "",
"schema": {
"$ref": "#/definitions/lnrpcSendCoinsResponse"
}
}
},
"parameters": [
{
"name": "body",
"in": "body",
"required": true,
"schema": {
"$ref": "#/definitions/lnrpcSendCoinsRequest"
}
}
],
"tags": [
"Lightning"
]
}
}
},
"definitions": {
"PendingChannelResponsePendingChannel": {
"type": "object",
"properties": {
"capacity": {
"type": "string",
"format": "int64"
},
"channel_point": {
"type": "string",
"format": "string"
},
"closing_txid": {
"type": "string",
"format": "string"
},
lnrpc: convert all instances of lightning_id to regular compressed pubkeys This commit modifies a few of the RPC call which previously took a lightning_id as their paramter to instead take a compressed public key field. With this change must of the code within the daemon can be simplified as we only use public keys everywhere throuhgout the daemon. Signed-off-by: Olaoluwa Osuntokun <laolu32@gmail.com>
2016-10-28 05:41:42 +03:00
"identity_key": {
lnrpc: add cursory REST support to the RPC server This commit adds a REST interface to the existing gRPC server by employing a simple http proxy auto-generated from the existing protobuf files. Currently full-support for any streaming RPC’s are currently untested. In addition to auto-generating a REST proxy server, a swagger.json is also generated which allows for gRPC-like native objects with higher-level clients, and also for auto-generated documentation. Due to limitations with accepting raw byte strings as parameters, some RPC’s have been modified to take both raw-bytes and string arguments. Additionally a new RPC has been added ‘NewWitnessAddress’ since the proxy doesn’t currently support enum-based arguments. Currently the proxy server is embedded within the daemon as an active HTTP server, however we may want to package the proxy server as a separate binary in the future. Similarly, we may want to add additional configuration information which controls the optional inclusion of the REST proxy. Atm, just like the current gRPC interface, the REST API is fully unauthenticated. Before moving to an initial alpha release after making the necessary changes to meet the spec drafted in Milan, authentication of the RPC interfaces will be addressed.
2016-10-16 00:38:47 +03:00
"type": "string",
"format": "string"
},
"local_balance": {
"type": "string",
"format": "int64"
},
"peer_id": {
"type": "integer",
"format": "int32"
},
"remote_balance": {
"type": "string",
"format": "int64"
},
"status": {
"$ref": "#/definitions/lnrpcChannelStatus"
}
}
},
"lnrpcActiveChannel": {
"type": "object",
"properties": {
"capacity": {
"type": "string",
"format": "int64"
},
"channel_point": {
"type": "string",
"format": "string"
},
"local_balance": {
"type": "string",
"format": "int64"
},
"num_updates": {
"type": "string",
"format": "uint64"
},
"pending_htlcs": {
"type": "array",
"items": {
"$ref": "#/definitions/lnrpcHTLC"
}
},
"remote_balance": {
"type": "string",
"format": "int64"
},
"remote_pubkey": {
"type": "string",
"format": "string"
},
lnrpc: added rpc support for querying a channel's satoshis sent/received Added total_satoshis_sent and total_satoshis_received fields to the ListChannels RPC call.
2016-11-19 03:20:44 +03:00
"total_satoshis_received": {
"type": "string",
"format": "int64"
},
"total_satoshis_sent": {
"type": "string",
"format": "int64"
},
lnrpc: add cursory REST support to the RPC server This commit adds a REST interface to the existing gRPC server by employing a simple http proxy auto-generated from the existing protobuf files. Currently full-support for any streaming RPC’s are currently untested. In addition to auto-generating a REST proxy server, a swagger.json is also generated which allows for gRPC-like native objects with higher-level clients, and also for auto-generated documentation. Due to limitations with accepting raw byte strings as parameters, some RPC’s have been modified to take both raw-bytes and string arguments. Additionally a new RPC has been added ‘NewWitnessAddress’ since the proxy doesn’t currently support enum-based arguments. Currently the proxy server is embedded within the daemon as an active HTTP server, however we may want to package the proxy server as a separate binary in the future. Similarly, we may want to add additional configuration information which controls the optional inclusion of the REST proxy. Atm, just like the current gRPC interface, the REST API is fully unauthenticated. Before moving to an initial alpha release after making the necessary changes to meet the spec drafted in Milan, authentication of the RPC interfaces will be addressed.
2016-10-16 00:38:47 +03:00
"unsettled_balance": {
"type": "string",
"format": "int64"
}
}
},
"lnrpcAddInvoiceResponse": {
"type": "object",
"properties": {
"r_hash": {
"type": "string",
"format": "byte"
}
}
},
"lnrpcChannelBalanceRequest": {
"type": "object"
},
"lnrpcChannelBalanceResponse": {
"type": "object",
"properties": {
"balance": {
"type": "string",
"format": "int64"
}
}
},
"lnrpcChannelCloseUpdate": {
"type": "object",
"properties": {
"closing_txid": {
"type": "string",
"format": "byte"
},
"success": {
"type": "boolean",
"format": "boolean"
}
}
},
"lnrpcChannelPoint": {
"type": "object",
"properties": {
"funding_txid": {
"type": "string",
"format": "byte"
},
"funding_txid_str": {
"type": "string",
"format": "string"
},
"output_index": {
"type": "integer",
"format": "int64"
}
}
},
"lnrpcChannelStatus": {
"type": "string",
"enum": [
"ALL",
"OPENING",
"CLOSING"
],
"default": "ALL"
},
"lnrpcCloseChannelRequest": {
"type": "object",
"properties": {
"channel_point": {
"$ref": "#/definitions/lnrpcChannelPoint"
},
"force": {
"type": "boolean",
"format": "boolean"
},
"time_limit": {
"type": "string",
"format": "int64"
}
}
},
"lnrpcCloseStatusUpdate": {
"type": "object",
"properties": {
"chan_close": {
"$ref": "#/definitions/lnrpcChannelCloseUpdate"
},
"close_pending": {
"$ref": "#/definitions/lnrpcPendingUpdate"
},
"confirmation": {
"$ref": "#/definitions/lnrpcConfirmationUpdate"
}
}
},
"lnrpcConfirmationUpdate": {
"type": "object",
"properties": {
"block_height": {
"type": "integer",
"format": "int32"
},
"block_sha": {
"type": "string",
"format": "byte"
},
"num_confs_left": {
"type": "integer",
"format": "int64"
}
}
},
"lnrpcConnectPeerRequest": {
"type": "object",
"properties": {
"addr": {
"$ref": "#/definitions/lnrpcLightningAddress"
}
}
},
"lnrpcConnectPeerResponse": {
"type": "object",
"properties": {
"peer_id": {
"type": "integer",
"format": "int32"
}
}
},
"lnrpcGetInfoRequest": {
"type": "object"
},
"lnrpcGetInfoResponse": {
"type": "object",
"properties": {
lnrpc: add current block height and a 'synced 'bit to GetInfo response
2016-11-15 02:54:47 +03:00
"block_height": {
"type": "integer",
"format": "int64"
},
lnrpc: add cursory REST support to the RPC server This commit adds a REST interface to the existing gRPC server by employing a simple http proxy auto-generated from the existing protobuf files. Currently full-support for any streaming RPC’s are currently untested. In addition to auto-generating a REST proxy server, a swagger.json is also generated which allows for gRPC-like native objects with higher-level clients, and also for auto-generated documentation. Due to limitations with accepting raw byte strings as parameters, some RPC’s have been modified to take both raw-bytes and string arguments. Additionally a new RPC has been added ‘NewWitnessAddress’ since the proxy doesn’t currently support enum-based arguments. Currently the proxy server is embedded within the daemon as an active HTTP server, however we may want to package the proxy server as a separate binary in the future. Similarly, we may want to add additional configuration information which controls the optional inclusion of the REST proxy. Atm, just like the current gRPC interface, the REST API is fully unauthenticated. Before moving to an initial alpha release after making the necessary changes to meet the spec drafted in Milan, authentication of the RPC interfaces will be addressed.
2016-10-16 00:38:47 +03:00
"identity_pubkey": {
"type": "string",
"format": "string"
},
"lightning_id": {
"type": "string",
"format": "string"
},
"num_active_channels": {
"type": "integer",
"format": "int64"
},
"num_peers": {
"type": "integer",
"format": "int64"
},
"num_pending_channels": {
"type": "integer",
"format": "int64"
lnrpc: add current block height and a 'synced 'bit to GetInfo response
2016-11-15 02:54:47 +03:00
},
"synced_to_chain": {
"type": "boolean",
"format": "boolean"
lnrpc: add cursory REST support to the RPC server This commit adds a REST interface to the existing gRPC server by employing a simple http proxy auto-generated from the existing protobuf files. Currently full-support for any streaming RPC’s are currently untested. In addition to auto-generating a REST proxy server, a swagger.json is also generated which allows for gRPC-like native objects with higher-level clients, and also for auto-generated documentation. Due to limitations with accepting raw byte strings as parameters, some RPC’s have been modified to take both raw-bytes and string arguments. Additionally a new RPC has been added ‘NewWitnessAddress’ since the proxy doesn’t currently support enum-based arguments. Currently the proxy server is embedded within the daemon as an active HTTP server, however we may want to package the proxy server as a separate binary in the future. Similarly, we may want to add additional configuration information which controls the optional inclusion of the REST proxy. Atm, just like the current gRPC interface, the REST API is fully unauthenticated. Before moving to an initial alpha release after making the necessary changes to meet the spec drafted in Milan, authentication of the RPC interfaces will be addressed.
2016-10-16 00:38:47 +03:00
}
}
},
"lnrpcGetTransactionsRequest": {
"type": "object"
},
"lnrpcHTLC": {
"type": "object",
"properties": {
"amount": {
"type": "string",
"format": "int64"
},
"expiration_height": {
"type": "integer",
"format": "int64"
},
"hash_lock": {
"type": "string",
"format": "byte"
},
"incoming": {
"type": "boolean",
"format": "boolean"
},
"revocation_delay": {
"type": "integer",
"format": "int64"
}
}
},
"lnrpcInvoice": {
"type": "object",
"properties": {
lnrpc: display creation date and settle date for Invoices
2016-11-13 05:03:19 +03:00
"creation_date": {
"type": "string",
"format": "int64"
},
lnrpc: add cursory REST support to the RPC server This commit adds a REST interface to the existing gRPC server by employing a simple http proxy auto-generated from the existing protobuf files. Currently full-support for any streaming RPC’s are currently untested. In addition to auto-generating a REST proxy server, a swagger.json is also generated which allows for gRPC-like native objects with higher-level clients, and also for auto-generated documentation. Due to limitations with accepting raw byte strings as parameters, some RPC’s have been modified to take both raw-bytes and string arguments. Additionally a new RPC has been added ‘NewWitnessAddress’ since the proxy doesn’t currently support enum-based arguments. Currently the proxy server is embedded within the daemon as an active HTTP server, however we may want to package the proxy server as a separate binary in the future. Similarly, we may want to add additional configuration information which controls the optional inclusion of the REST proxy. Atm, just like the current gRPC interface, the REST API is fully unauthenticated. Before moving to an initial alpha release after making the necessary changes to meet the spec drafted in Milan, authentication of the RPC interfaces will be addressed.
2016-10-16 00:38:47 +03:00
"memo": {
"type": "string",
"format": "string"
},
"r_hash": {
"type": "string",
"format": "byte"
},
"r_preimage": {
"type": "string",
"format": "byte"
},
"receipt": {
"type": "string",
"format": "byte"
},
lnrpc: display creation date and settle date for Invoices
2016-11-13 05:03:19 +03:00
"settle_date": {
"type": "string",
"format": "int64"
},
lnrpc: add cursory REST support to the RPC server This commit adds a REST interface to the existing gRPC server by employing a simple http proxy auto-generated from the existing protobuf files. Currently full-support for any streaming RPC’s are currently untested. In addition to auto-generating a REST proxy server, a swagger.json is also generated which allows for gRPC-like native objects with higher-level clients, and also for auto-generated documentation. Due to limitations with accepting raw byte strings as parameters, some RPC’s have been modified to take both raw-bytes and string arguments. Additionally a new RPC has been added ‘NewWitnessAddress’ since the proxy doesn’t currently support enum-based arguments. Currently the proxy server is embedded within the daemon as an active HTTP server, however we may want to package the proxy server as a separate binary in the future. Similarly, we may want to add additional configuration information which controls the optional inclusion of the REST proxy. Atm, just like the current gRPC interface, the REST API is fully unauthenticated. Before moving to an initial alpha release after making the necessary changes to meet the spec drafted in Milan, authentication of the RPC interfaces will be addressed.
2016-10-16 00:38:47 +03:00
"settled": {
"type": "boolean",
"format": "boolean"
},
"value": {
"type": "string",
"format": "int64"
}
}
},
"lnrpcInvoiceSubscription": {
"type": "object"
},
"lnrpcLightningAddress": {
"type": "object",
"properties": {
"host": {
"type": "string",
"format": "string"
},
lnrpc: convert all instances of lightning_id to regular compressed pubkeys This commit modifies a few of the RPC call which previously took a lightning_id as their paramter to instead take a compressed public key field. With this change must of the code within the daemon can be simplified as we only use public keys everywhere throuhgout the daemon. Signed-off-by: Olaoluwa Osuntokun <laolu32@gmail.com>
2016-10-28 05:41:42 +03:00
"pubkey": {
lnrpc: add cursory REST support to the RPC server This commit adds a REST interface to the existing gRPC server by employing a simple http proxy auto-generated from the existing protobuf files. Currently full-support for any streaming RPC’s are currently untested. In addition to auto-generating a REST proxy server, a swagger.json is also generated which allows for gRPC-like native objects with higher-level clients, and also for auto-generated documentation. Due to limitations with accepting raw byte strings as parameters, some RPC’s have been modified to take both raw-bytes and string arguments. Additionally a new RPC has been added ‘NewWitnessAddress’ since the proxy doesn’t currently support enum-based arguments. Currently the proxy server is embedded within the daemon as an active HTTP server, however we may want to package the proxy server as a separate binary in the future. Similarly, we may want to add additional configuration information which controls the optional inclusion of the REST proxy. Atm, just like the current gRPC interface, the REST API is fully unauthenticated. Before moving to an initial alpha release after making the necessary changes to meet the spec drafted in Milan, authentication of the RPC interfaces will be addressed.
2016-10-16 00:38:47 +03:00
"type": "string",
"format": "string"
}
}
},
"lnrpcListChannelsRequest": {
"type": "object"
},
"lnrpcListChannelsResponse": {
"type": "object",
"properties": {
"channels": {
"type": "array",
"items": {
"$ref": "#/definitions/lnrpcActiveChannel"
}
}
}
},
"lnrpcListInvoiceRequest": {
"type": "object",
"properties": {
"pending_only": {
"type": "boolean",
"format": "boolean"
}
}
},
"lnrpcListInvoiceResponse": {
"type": "object",
"properties": {
"invoices": {
"type": "array",
"items": {
"$ref": "#/definitions/lnrpcInvoice"
}
}
}
},
"lnrpcListPeersRequest": {
"type": "object"
},
"lnrpcListPeersResponse": {
"type": "object",
"properties": {
"peers": {
"type": "array",
"items": {
"$ref": "#/definitions/lnrpcPeer"
}
}
}
},
"lnrpcNewAddressResponse": {
"type": "object",
"properties": {
"address": {
"type": "string",
"format": "string"
}
}
},
"lnrpcNewWitnessAddressRequest": {
"type": "object"
},
"lnrpcOpenChannelRequest": {
"type": "object",
"properties": {
"commission_size": {
"type": "string",
"format": "int64"
},
"local_funding_amount": {
"type": "string",
"format": "int64"
},
lnrpc: convert all instances of lightning_id to regular compressed pubkeys This commit modifies a few of the RPC call which previously took a lightning_id as their paramter to instead take a compressed public key field. With this change must of the code within the daemon can be simplified as we only use public keys everywhere throuhgout the daemon. Signed-off-by: Olaoluwa Osuntokun <laolu32@gmail.com>
2016-10-28 05:41:42 +03:00
"node_pubkey": {
"type": "string",
"format": "byte"
},
lnrpc: add synchronous versions of SendPayment and OpenChannel This commit adds synchronous version of the RPC’s to send payments over channels and open new channels. The previous async versions of these RPC calls have been removed from the REST interface. Additionally for these two RPC calls any field which accepted byte slices now also accept a variant of the field which is a hex-encoded string. The OpenChannelSync RPC is intended to be used along with either the ListChannels or PendingChannels RPC to poll for a channels existence or non-existence as a signal that the channel is finally open.
2016-11-11 04:33:24 +03:00
"node_pubkey_string": {
"type": "string",
"format": "string"
},
lnrpc: add cursory REST support to the RPC server This commit adds a REST interface to the existing gRPC server by employing a simple http proxy auto-generated from the existing protobuf files. Currently full-support for any streaming RPC’s are currently untested. In addition to auto-generating a REST proxy server, a swagger.json is also generated which allows for gRPC-like native objects with higher-level clients, and also for auto-generated documentation. Due to limitations with accepting raw byte strings as parameters, some RPC’s have been modified to take both raw-bytes and string arguments. Additionally a new RPC has been added ‘NewWitnessAddress’ since the proxy doesn’t currently support enum-based arguments. Currently the proxy server is embedded within the daemon as an active HTTP server, however we may want to package the proxy server as a separate binary in the future. Similarly, we may want to add additional configuration information which controls the optional inclusion of the REST proxy. Atm, just like the current gRPC interface, the REST API is fully unauthenticated. Before moving to an initial alpha release after making the necessary changes to meet the spec drafted in Milan, authentication of the RPC interfaces will be addressed.
2016-10-16 00:38:47 +03:00
"num_confs": {
"type": "integer",
"format": "int64"
},
"remote_funding_amount": {
"type": "string",
"format": "int64"
},
"target_peer_id": {
"type": "integer",
"format": "int32"
}
}
},
"lnrpcPaymentHash": {
"type": "object",
"properties": {
"r_hash": {
"type": "string",
"format": "byte"
},
"r_hash_str": {
"type": "string",
"format": "string"
}
}
},
"lnrpcPeer": {
"type": "object",
"properties": {
"address": {
"type": "string",
"format": "string"
},
"bytes_recv": {
"type": "string",
"format": "uint64"
},
"bytes_sent": {
"type": "string",
"format": "uint64"
},
"inbound": {
"type": "boolean",
"format": "boolean"
},
"peer_id": {
"type": "integer",
"format": "int32"
},
lnrpc: returns the node's pubkey instead of lighting_id in ListPeers
2016-10-27 00:31:41 +03:00
"pub_key": {
"type": "string",
"format": "string"
},
lnrpc: add cursory REST support to the RPC server This commit adds a REST interface to the existing gRPC server by employing a simple http proxy auto-generated from the existing protobuf files. Currently full-support for any streaming RPC’s are currently untested. In addition to auto-generating a REST proxy server, a swagger.json is also generated which allows for gRPC-like native objects with higher-level clients, and also for auto-generated documentation. Due to limitations with accepting raw byte strings as parameters, some RPC’s have been modified to take both raw-bytes and string arguments. Additionally a new RPC has been added ‘NewWitnessAddress’ since the proxy doesn’t currently support enum-based arguments. Currently the proxy server is embedded within the daemon as an active HTTP server, however we may want to package the proxy server as a separate binary in the future. Similarly, we may want to add additional configuration information which controls the optional inclusion of the REST proxy. Atm, just like the current gRPC interface, the REST API is fully unauthenticated. Before moving to an initial alpha release after making the necessary changes to meet the spec drafted in Milan, authentication of the RPC interfaces will be addressed.
2016-10-16 00:38:47 +03:00
"sat_recv": {
"type": "string",
"format": "int64"
},
"sat_sent": {
"type": "string",
"format": "int64"
}
}
},
"lnrpcPendingChannelRequest": {
"type": "object",
"properties": {
"status": {
"$ref": "#/definitions/lnrpcChannelStatus"
}
}
},
"lnrpcPendingChannelResponse": {
"type": "object",
"properties": {
"pending_channels": {
"type": "array",
"items": {
"$ref": "#/definitions/PendingChannelResponsePendingChannel"
}
}
}
},
"lnrpcPendingUpdate": {
"type": "object",
"properties": {
"txid": {
"type": "string",
"format": "byte"
}
}
},
"lnrpcSendCoinsRequest": {
"type": "object",
"properties": {
"addr": {
"type": "string",
"format": "string"
},
"amount": {
"type": "string",
"format": "int64"
}
}
},
"lnrpcSendCoinsResponse": {
"type": "object",
"properties": {
"txid": {
"type": "string",
"format": "string"
}
}
},
"lnrpcSendRequest": {
"type": "object",
"properties": {
"amt": {
"type": "string",
"format": "int64"
},
"dest": {
"type": "string",
"format": "byte"
},
lnrpc: add synchronous versions of SendPayment and OpenChannel This commit adds synchronous version of the RPC’s to send payments over channels and open new channels. The previous async versions of these RPC calls have been removed from the REST interface. Additionally for these two RPC calls any field which accepted byte slices now also accept a variant of the field which is a hex-encoded string. The OpenChannelSync RPC is intended to be used along with either the ListChannels or PendingChannels RPC to poll for a channels existence or non-existence as a signal that the channel is finally open.
2016-11-11 04:33:24 +03:00
"dest_string": {
"type": "string",
"format": "string"
},
lnrpc: add cursory REST support to the RPC server This commit adds a REST interface to the existing gRPC server by employing a simple http proxy auto-generated from the existing protobuf files. Currently full-support for any streaming RPC’s are currently untested. In addition to auto-generating a REST proxy server, a swagger.json is also generated which allows for gRPC-like native objects with higher-level clients, and also for auto-generated documentation. Due to limitations with accepting raw byte strings as parameters, some RPC’s have been modified to take both raw-bytes and string arguments. Additionally a new RPC has been added ‘NewWitnessAddress’ since the proxy doesn’t currently support enum-based arguments. Currently the proxy server is embedded within the daemon as an active HTTP server, however we may want to package the proxy server as a separate binary in the future. Similarly, we may want to add additional configuration information which controls the optional inclusion of the REST proxy. Atm, just like the current gRPC interface, the REST API is fully unauthenticated. Before moving to an initial alpha release after making the necessary changes to meet the spec drafted in Milan, authentication of the RPC interfaces will be addressed.
2016-10-16 00:38:47 +03:00
"fast_send": {
"type": "boolean",
"format": "boolean"
},
"payment_hash": {
"type": "string",
"format": "byte"
lnrpc: add synchronous versions of SendPayment and OpenChannel This commit adds synchronous version of the RPC’s to send payments over channels and open new channels. The previous async versions of these RPC calls have been removed from the REST interface. Additionally for these two RPC calls any field which accepted byte slices now also accept a variant of the field which is a hex-encoded string. The OpenChannelSync RPC is intended to be used along with either the ListChannels or PendingChannels RPC to poll for a channels existence or non-existence as a signal that the channel is finally open.
2016-11-11 04:33:24 +03:00
},
"payment_hash_string": {
"type": "string",
"format": "string"
lnrpc: add cursory REST support to the RPC server This commit adds a REST interface to the existing gRPC server by employing a simple http proxy auto-generated from the existing protobuf files. Currently full-support for any streaming RPC’s are currently untested. In addition to auto-generating a REST proxy server, a swagger.json is also generated which allows for gRPC-like native objects with higher-level clients, and also for auto-generated documentation. Due to limitations with accepting raw byte strings as parameters, some RPC’s have been modified to take both raw-bytes and string arguments. Additionally a new RPC has been added ‘NewWitnessAddress’ since the proxy doesn’t currently support enum-based arguments. Currently the proxy server is embedded within the daemon as an active HTTP server, however we may want to package the proxy server as a separate binary in the future. Similarly, we may want to add additional configuration information which controls the optional inclusion of the REST proxy. Atm, just like the current gRPC interface, the REST API is fully unauthenticated. Before moving to an initial alpha release after making the necessary changes to meet the spec drafted in Milan, authentication of the RPC interfaces will be addressed.
2016-10-16 00:38:47 +03:00
}
}
},
"lnrpcSendResponse": {
"type": "object"
},
"lnrpcTransaction": {
"type": "object",
"properties": {
"amount": {
"type": "number",
"format": "double"
},
"block_hash": {
"type": "string",
"format": "string"
},
"block_height": {
"type": "integer",
"format": "int32"
},
"num_confirmations": {
"type": "integer",
"format": "int32"
},
"time_stamp": {
"type": "string",
"format": "int64"
},
"total_fees": {
"type": "string",
"format": "int64"
},
"tx_hash": {
"type": "string",
"format": "string"
}
}
},
"lnrpcTransactionDetails": {
"type": "object",
"properties": {
"transactions": {
"type": "array",
"items": {
"$ref": "#/definitions/lnrpcTransaction"
}
}
}
},
"lnrpcWalletBalanceRequest": {
"type": "object",
"properties": {
"witness_only": {
"type": "boolean",
"format": "boolean"
}
}
},
"lnrpcWalletBalanceResponse": {
"type": "object",
"properties": {
"balance": {
"type": "number",
"format": "double"
}
}
}
}
}
Reference in New Issue Copy Permalink