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

1736 lines
37 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"
}
}
},
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"parameters": [
{
"name": "witness_only",
"in": "query",
"required": false,
"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
"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": {
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"summary": "TODO(roasbeef): merge with below with bool?",
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
"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": {
"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"
]
}
},
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
"/v1/graph": {
"get": {
"operationId": "DescribeGraph",
"responses": {
"200": {
"description": "",
"schema": {
"$ref": "#/definitions/lnrpcChannelGraph"
}
}
},
"tags": [
"Lightning"
]
}
},
"/v1/graph/edge/{chan_id}": {
"get": {
"operationId": "GetChanInfo",
"responses": {
"200": {
"description": "",
"schema": {
"$ref": "#/definitions/lnrpcChannelEdge"
}
}
},
"parameters": [
{
"name": "chan_id",
"in": "path",
"required": true,
"type": "string",
"format": "uint64"
}
],
"tags": [
"Lightning"
]
}
},
"/v1/graph/info": {
"get": {
"operationId": "GetNetworkInfo",
"responses": {
"200": {
"description": "",
"schema": {
"$ref": "#/definitions/lnrpcNetworkInfo"
}
}
},
"tags": [
"Lightning"
]
}
},
"/v1/graph/node/{pub_key}": {
"get": {
"operationId": "GetNodeInfo",
"responses": {
"200": {
"description": "",
"schema": {
"$ref": "#/definitions/lnrpcNodeInfo"
}
}
},
"parameters": [
{
"name": "pub_key",
"in": "path",
"required": true,
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "string"
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
}
],
"tags": [
"Lightning"
]
}
},
lnrpc: convert QueryRoute to QueryRoutes This commit converts the previous QueryRoute command to a new command: QueryRoutes. This command is identical to QueryRoute other than the fact that it’s able to return multiple routes rather than a single route.
2017-03-21 05:01:32 +03:00
"/v1/graph/routes/{pub_key}/{amt}": {
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
"get": {
lnrpc: convert QueryRoute to QueryRoutes This commit converts the previous QueryRoute command to a new command: QueryRoutes. This command is identical to QueryRoute other than the fact that it’s able to return multiple routes rather than a single route.
2017-03-21 05:01:32 +03:00
"operationId": "QueryRoutes",
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
"responses": {
"200": {
"description": "",
"schema": {
lnrpc: convert QueryRoute to QueryRoutes This commit converts the previous QueryRoute command to a new command: QueryRoutes. This command is identical to QueryRoute other than the fact that it’s able to return multiple routes rather than a single route.
2017-03-21 05:01:32 +03:00
"$ref": "#/definitions/lnrpcQueryRoutesResponse"
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
}
}
},
"parameters": [
{
"name": "pub_key",
"in": "path",
"required": true,
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "string"
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
},
{
"name": "amt",
"in": "path",
"required": true,
"type": "string",
"format": "int64"
}
],
"tags": [
"Lightning"
]
}
},
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
"/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,
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "string"
},
{
"name": "r_hash",
"in": "query",
"required": false,
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",
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"format": "byte"
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
}
],
"tags": [
"Lightning"
]
}
},
"/v1/newaddress": {
"get": {
"operationId": "NewWitnessAddress",
"responses": {
"200": {
"description": "",
"schema": {
"$ref": "#/definitions/lnrpcNewAddressResponse"
}
}
},
"tags": [
"Lightning"
]
}
},
channeldb: save outgoing payments Add structure for outgoing payments. Saving payment in DB after successful payment send. Add RPC call for listing all payments.
2016-12-05 14:59:36 +03:00
"/v1/payments": {
"get": {
"operationId": "ListPayments",
"responses": {
"200": {
"description": "",
"schema": {
"$ref": "#/definitions/lnrpcListPaymentsResponse"
}
}
},
"tags": [
"Lightning"
]
},
"delete": {
"operationId": "DeleteAllPayments",
"responses": {
"200": {
"description": "",
"schema": {
"$ref": "#/definitions/lnrpcDeleteAllPaymentsResponse"
}
}
},
"tags": [
"Lightning"
]
}
},
lnrpc: add new RPC to decode payment requests
2017-01-18 00:24:55 +03:00
"/v1/payreq/{pay_req}": {
"get": {
"operationId": "DecodePayReq",
"responses": {
"200": {
"description": "",
"schema": {
"$ref": "#/definitions/lnrpcPayReq"
}
}
},
"parameters": [
{
"name": "pay_req",
"in": "path",
"required": true,
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "string"
lnrpc: add new RPC to decode payment requests
2017-01-18 00:24:55 +03:00
}
],
"tags": [
"Lightning"
]
}
},
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
"/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": {
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"NewAddressRequestAddressType": {
"type": "string",
"enum": [
"WITNESS_PUBKEY_HASH",
"NESTED_PUBKEY_HASH",
"PUBKEY_HASH"
],
"default": "WITNESS_PUBKEY_HASH"
},
lnrpc: augment the PendingChannels RPC to include details of closed channels This commit adds some additional fields to the PendingChannels RPC s.t users will be able to use the RPC to gain a complete view w.r.t where all the funds within the daemon are, and how soon they can be retrieved. The following information is now returned: * all channels pending open * all channels pending cooperative close * all channels pending force close
2017-05-05 01:34:02 +03:00
"PendingChannelResponseClosedChannel": {
"type": "object",
"properties": {
"channel": {
"$ref": "#/definitions/PendingChannelResponsePendingChannel"
},
"closing_txid": {
"type": "string"
}
}
},
"PendingChannelResponseForceClosedChannel": {
"type": "object",
"properties": {
"channel": {
"$ref": "#/definitions/PendingChannelResponsePendingChannel"
},
"closing_txid": {
"type": "string"
},
"limbo_balance": {
"type": "string",
"format": "int64"
},
"maturity_height": {
"type": "integer",
"format": "int64"
},
"blocks_til_maturity": {
"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
"PendingChannelResponsePendingChannel": {
"type": "object",
"properties": {
lnrpc: augment the PendingChannels RPC to include details of closed channels This commit adds some additional fields to the PendingChannels RPC s.t users will be able to use the RPC to gain a complete view w.r.t where all the funds within the daemon are, and how soon they can be retrieved. The following information is now returned: * all channels pending open * all channels pending cooperative close * all channels pending force close
2017-05-05 01:34:02 +03:00
"remote_node_pub": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "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
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"channel_point": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "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
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"capacity": {
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",
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"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
},
"local_balance": {
"type": "string",
"format": "int64"
},
"remote_balance": {
"type": "string",
"format": "int64"
lnrpc: augment the PendingChannels RPC to include details of closed channels This commit adds some additional fields to the PendingChannels RPC s.t users will be able to use the RPC to gain a complete view w.r.t where all the funds within the daemon are, and how soon they can be retrieved. The following information is now returned: * all channels pending open * all channels pending cooperative close * all channels pending force close
2017-05-05 01:34:02 +03:00
}
}
},
"PendingChannelResponsePendingOpenChannel": {
"type": "object",
"properties": {
"channel": {
"$ref": "#/definitions/PendingChannelResponsePendingChannel"
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
},
lnrpc: augment the PendingChannels RPC to include details of closed channels This commit adds some additional fields to the PendingChannels RPC s.t users will be able to use the RPC to gain a complete view w.r.t where all the funds within the daemon are, and how soon they can be retrieved. The following information is now returned: * all channels pending open * all channels pending cooperative close * all channels pending force close
2017-05-05 01:34:02 +03:00
"confirmation_height": {
"type": "integer",
"format": "int64"
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
},
lnrpc: augment the PendingChannels RPC to include details of closed channels This commit adds some additional fields to the PendingChannels RPC s.t users will be able to use the RPC to gain a complete view w.r.t where all the funds within the daemon are, and how soon they can be retrieved. The following information is now returned: * all channels pending open * all channels pending cooperative close * all channels pending force close
2017-05-05 01:34:02 +03:00
"blocks_till_open": {
"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
}
}
},
"lnrpcActiveChannel": {
"type": "object",
"properties": {
lnrpc: add field denoting if channel peer is online in ListChannels This commit adds a new field to the ListChannels RPC command which indicates if the peer is currently online or not. This is useful as UI’s will be able to use this information to communicate the availability of each channel to an end user.
2017-03-09 01:45:58 +03:00
"active": {
"type": "boolean",
"format": "boolean"
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"remote_pubkey": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "string"
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
},
"channel_point": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "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
},
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
"chan_id": {
"type": "string",
"format": "uint64"
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"capacity": {
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",
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"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
},
"local_balance": {
"type": "string",
"format": "int64"
},
"remote_balance": {
"type": "string",
"format": "int64"
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"unsettled_balance": {
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
"type": "string",
"format": "int64"
},
"total_satoshis_sent": {
"type": "string",
"format": "int64"
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"total_satoshis_received": {
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": "int64"
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
},
"num_updates": {
"type": "string",
"format": "uint64"
},
"pending_htlcs": {
"type": "array",
"items": {
"$ref": "#/definitions/lnrpcHTLC"
}
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
}
}
},
"lnrpcAddInvoiceResponse": {
"type": "object",
"properties": {
"r_hash": {
"type": "string",
"format": "byte"
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
},
"payment_request": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "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
}
}
},
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
"lnrpcChanInfoRequest": {
"type": "object",
"properties": {
"chan_id": {
"type": "string",
"format": "uint64"
}
}
},
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
"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"
}
}
},
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
"lnrpcChannelEdge": {
"type": "object",
"properties": {
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"channel_id": {
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
"type": "string",
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"format": "uint64"
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
},
"chan_point": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "string"
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
},
"last_update": {
"type": "integer",
"format": "int64"
},
"node1_pub": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "string"
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
},
"node2_pub": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "string"
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
},
"capacity": {
"type": "string",
"format": "int64"
},
"node1_policy": {
"$ref": "#/definitions/lnrpcRoutingPolicy"
},
"node2_policy": {
"$ref": "#/definitions/lnrpcRoutingPolicy"
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
}
}
},
lnrpc: add new SubscribeChannelGraph RPC call This commit adds a new streaming RPC call the exposes the newly added routing layer TopologyChange notifications within the gRPC service.
2017-03-14 06:37:25 +03:00
"lnrpcChannelEdgeUpdate": {
"type": "object",
"properties": {
"chan_id": {
"type": "string",
"format": "uint64"
},
"chan_point": {
"$ref": "#/definitions/lnrpcChannelPoint"
},
"capacity": {
"type": "string",
"format": "int64"
},
"routing_policy": {
"$ref": "#/definitions/lnrpcRoutingPolicy"
},
"advertising_node": {
"type": "string"
},
"connecting_node": {
"type": "string"
}
}
},
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
"lnrpcChannelGraph": {
"type": "object",
"properties": {
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"nodes": {
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
"type": "array",
"items": {
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"$ref": "#/definitions/lnrpcLightningNode"
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
}
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"edges": {
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
"type": "array",
"items": {
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"$ref": "#/definitions/lnrpcChannelEdge"
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
}
}
}
},
"lnrpcChannelGraphRequest": {
"type": "object"
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"lnrpcChannelOpenUpdate": {
"type": "object",
"properties": {
"channel_point": {
"$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
"lnrpcChannelPoint": {
"type": "object",
"properties": {
"funding_txid": {
"type": "string",
lnrpc: add new SubscribeChannelGraph RPC call This commit adds a new streaming RPC call the exposes the newly added routing layer TopologyChange notifications within the gRPC service.
2017-03-14 06:37:25 +03:00
"format": "byte",
"title": "TODO(roasbeef): make str vs bytes into a oneof"
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
},
"funding_txid_str": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "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
},
"output_index": {
"type": "integer",
"format": "int64"
}
}
},
"lnrpcCloseChannelRequest": {
"type": "object",
"properties": {
"channel_point": {
"$ref": "#/definitions/lnrpcChannelPoint"
},
"time_limit": {
"type": "string",
"format": "int64"
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
},
"force": {
"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
}
}
},
"lnrpcCloseStatusUpdate": {
"type": "object",
"properties": {
"close_pending": {
"$ref": "#/definitions/lnrpcPendingUpdate"
},
"confirmation": {
"$ref": "#/definitions/lnrpcConfirmationUpdate"
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
},
"chan_close": {
"$ref": "#/definitions/lnrpcChannelCloseUpdate"
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
}
}
},
lnrpc: add new SubscribeChannelGraph RPC call This commit adds a new streaming RPC call the exposes the newly added routing layer TopologyChange notifications within the gRPC service.
2017-03-14 06:37:25 +03:00
"lnrpcClosedChannelUpdate": {
"type": "object",
"properties": {
"chan_id": {
"type": "string",
"format": "uint64"
},
"capacity": {
"type": "string",
"format": "int64"
},
"closed_height": {
"type": "integer",
"format": "int64"
},
"chan_point": {
"$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
"lnrpcConfirmationUpdate": {
"type": "object",
"properties": {
"block_sha": {
"type": "string",
"format": "byte"
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"block_height": {
"type": "integer",
"format": "int32"
},
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_left": {
"type": "integer",
"format": "int64"
}
}
},
"lnrpcConnectPeerRequest": {
"type": "object",
"properties": {
"addr": {
"$ref": "#/definitions/lnrpcLightningAddress"
lnrpc: recompile protos
2017-01-10 06:01:06 +03:00
},
"perm": {
"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
}
}
},
"lnrpcConnectPeerResponse": {
"type": "object",
"properties": {
"peer_id": {
"type": "integer",
"format": "int32"
}
}
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"lnrpcDebugLevelRequest": {
"type": "object",
"properties": {
"show": {
"type": "boolean",
"format": "boolean"
},
"level_spec": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "string"
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
}
}
},
"lnrpcDebugLevelResponse": {
"type": "object",
"properties": {
"sub_systems": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "string"
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
}
}
},
channeldb: save outgoing payments Add structure for outgoing payments. Saving payment in DB after successful payment send. Add RPC call for listing all payments.
2016-12-05 14:59:36 +03:00
"lnrpcDeleteAllPaymentsRequest": {
"type": "object"
},
"lnrpcDeleteAllPaymentsResponse": {
"type": "object"
},
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
"lnrpcGetInfoRequest": {
"type": "object"
},
"lnrpcGetInfoResponse": {
"type": "object",
"properties": {
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"identity_pubkey": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "string"
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"alias": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "string"
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"num_pending_channels": {
lnrpc: add current block height and a 'synced 'bit to GetInfo response
2016-11-15 02:54:47 +03:00
"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
"num_active_channels": {
"type": "integer",
"format": "int64"
},
"num_peers": {
"type": "integer",
"format": "int64"
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"block_height": {
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": "integer",
"format": "int64"
lnrpc: add current block height and a 'synced 'bit to GetInfo response
2016-11-15 02:54:47 +03:00
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"block_hash": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "string"
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
},
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 testnet bool to GetInfo RPC, remove lightning_id
2016-12-13 02:34:20 +03:00
},
"testnet": {
"type": "boolean",
"format": "boolean"
lnrpc: add chains field to GetInfoResponse to display active chains
2017-05-03 05:49:41 +03:00
},
"chains": {
"type": "array",
"items": {
"type": "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
}
}
},
"lnrpcGetTransactionsRequest": {
"type": "object"
},
lnrpc: add new SubscribeChannelGraph RPC call This commit adds a new streaming RPC call the exposes the newly added routing layer TopologyChange notifications within the gRPC service.
2017-03-14 06:37:25 +03:00
"lnrpcGraphTopologySubscription": {
"type": "object"
},
"lnrpcGraphTopologyUpdate": {
"type": "object",
"properties": {
"node_updates": {
"type": "array",
"items": {
"$ref": "#/definitions/lnrpcNodeUpdate"
}
},
"channel_updates": {
"type": "array",
"items": {
"$ref": "#/definitions/lnrpcChannelEdgeUpdate"
}
},
"closed_chans": {
"type": "array",
"items": {
"$ref": "#/definitions/lnrpcClosedChannelUpdate"
}
}
}
},
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
"lnrpcHTLC": {
"type": "object",
"properties": {
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"incoming": {
"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
"amount": {
"type": "string",
"format": "int64"
},
"hash_lock": {
"type": "string",
"format": "byte"
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"expiration_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
},
"revocation_delay": {
"type": "integer",
"format": "int64"
}
}
},
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
"lnrpcHop": {
"type": "object",
"properties": {
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"chan_id": {
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
"type": "string",
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"format": "uint64"
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
},
"chan_capacity": {
"type": "string",
"format": "int64"
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"amt_to_forward": {
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
"type": "string",
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"format": "int64"
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
},
"fee": {
"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
"lnrpcInvoice": {
"type": "object",
"properties": {
"memo": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "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
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"receipt": {
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": "byte"
},
"r_preimage": {
"type": "string",
"format": "byte"
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"r_hash": {
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": "byte"
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"value": {
lnrpc: display creation date and settle date for Invoices
2016-11-13 05:03:19 +03:00
"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"
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"creation_date": {
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": "int64"
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
},
"settle_date": {
"type": "string",
"format": "int64"
},
"payment_request": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "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
}
}
},
"lnrpcInvoiceSubscription": {
"type": "object"
},
"lnrpcLightningAddress": {
"type": "object",
"properties": {
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"pubkey": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "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
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"host": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "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
}
}
},
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
"lnrpcLightningNode": {
"type": "object",
"properties": {
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"last_update": {
"type": "integer",
"format": "int64"
},
"pub_key": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "string"
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"alias": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "string"
lnwire: update NodeAnnouncement to handle multiple addresses This commit modifies address handling in the NodeAnnouncement struct, switching from net.TCPAddr to []net.Addr. This enables more flexible address handling with multiple types and multiple addresses for each node. This commit addresses the first part of issue #131 .
2017-02-17 12:29:23 +03:00
},
"addresses": {
"type": "array",
"items": {
"$ref": "#/definitions/lnrpcNodeAddress"
}
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
}
}
},
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
"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"
}
}
}
},
channeldb: save outgoing payments Add structure for outgoing payments. Saving payment in DB after successful payment send. Add RPC call for listing all payments.
2016-12-05 14:59:36 +03:00
"lnrpcListPaymentsRequest": {
"type": "object"
},
"lnrpcListPaymentsResponse": {
"type": "object",
"properties": {
"payments": {
"type": "array",
"items": {
"$ref": "#/definitions/lnrpcPayment"
}
}
}
},
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
"lnrpcListPeersRequest": {
"type": "object"
},
"lnrpcListPeersResponse": {
"type": "object",
"properties": {
"peers": {
"type": "array",
"items": {
"$ref": "#/definitions/lnrpcPeer"
}
}
}
},
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
"lnrpcNetworkInfo": {
"type": "object",
"properties": {
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"graph_diameter": {
"type": "integer",
"format": "int64"
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
},
"avg_out_degree": {
"type": "number",
"format": "double"
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"max_out_degree": {
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
"type": "integer",
"format": "int64"
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"num_nodes": {
"type": "integer",
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
"format": "int64"
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"num_channels": {
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
"type": "integer",
"format": "int64"
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"total_network_capacity": {
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
"type": "string",
"format": "int64"
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"avg_channel_size": {
"type": "number",
"format": "double"
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"min_channel_size": {
"type": "string",
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
"format": "int64"
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"max_channel_size": {
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
"type": "string",
"format": "int64"
}
}
},
"lnrpcNetworkInfoRequest": {
"type": "object"
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"lnrpcNewAddressRequest": {
"type": "object",
"properties": {
"type": {
"$ref": "#/definitions/NewAddressRequestAddressType"
}
}
},
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
"lnrpcNewAddressResponse": {
"type": "object",
"properties": {
"address": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "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
}
}
},
"lnrpcNewWitnessAddressRequest": {
"type": "object"
},
lnwire: update NodeAnnouncement to handle multiple addresses This commit modifies address handling in the NodeAnnouncement struct, switching from net.TCPAddr to []net.Addr. This enables more flexible address handling with multiple types and multiple addresses for each node. This commit addresses the first part of issue #131 .
2017-02-17 12:29:23 +03:00
"lnrpcNodeAddress": {
"type": "object",
"properties": {
"network": {
"type": "string"
},
"addr": {
"type": "string"
}
}
},
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
"lnrpcNodeInfo": {
"type": "object",
"properties": {
"node": {
"$ref": "#/definitions/lnrpcLightningNode"
},
"num_channels": {
"type": "integer",
"format": "int64"
},
"total_capacity": {
"type": "string",
"format": "int64"
}
}
},
"lnrpcNodeInfoRequest": {
"type": "object",
"properties": {
"pub_key": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "string"
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
}
}
},
lnrpc: add new SubscribeChannelGraph RPC call This commit adds a new streaming RPC call the exposes the newly added routing layer TopologyChange notifications within the gRPC service.
2017-03-14 06:37:25 +03:00
"lnrpcNodeUpdate": {
"type": "object",
"properties": {
"addresses": {
"type": "array",
"items": {
"type": "string"
}
},
"identity_key": {
"type": "string"
},
"global_features": {
"type": "string",
"format": "byte"
},
"alias": {
"type": "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
"lnrpcOpenChannelRequest": {
"type": "object",
"properties": {
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"target_peer_id": {
"type": "integer",
"format": "int32"
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
},
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": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "string"
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
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"local_funding_amount": {
"type": "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
"format": "int64"
},
lnrpc: recompile protos
2017-01-10 06:01:06 +03:00
"push_sat": {
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": "int64"
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"num_confs": {
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": "integer",
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"format": "int64"
}
}
},
"lnrpcOpenStatusUpdate": {
"type": "object",
"properties": {
"chan_pending": {
"$ref": "#/definitions/lnrpcPendingUpdate"
},
"confirmation": {
"$ref": "#/definitions/lnrpcConfirmationUpdate"
},
"chan_open": {
"$ref": "#/definitions/lnrpcChannelOpenUpdate"
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
}
}
},
lnrpc: add new RPC to decode payment requests
2017-01-18 00:24:55 +03:00
"lnrpcPayReq": {
"type": "object",
"properties": {
"destination": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "string"
lnrpc: add new RPC to decode payment requests
2017-01-18 00:24:55 +03:00
},
"payment_hash": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "string"
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
},
"num_satoshis": {
"type": "string",
"format": "int64"
lnrpc: add new RPC to decode payment requests
2017-01-18 00:24:55 +03:00
}
}
},
"lnrpcPayReqString": {
"type": "object",
"properties": {
"pay_req": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "string"
lnrpc: add new RPC to decode payment requests
2017-01-18 00:24:55 +03:00
}
}
},
channeldb: save outgoing payments Add structure for outgoing payments. Saving payment in DB after successful payment send. Add RPC call for listing all payments.
2016-12-05 14:59:36 +03:00
"lnrpcPayment": {
"type": "object",
"properties": {
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"payment_hash": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "string"
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
},
"value": {
channeldb: save outgoing payments Add structure for outgoing payments. Saving payment in DB after successful payment send. Add RPC call for listing all payments.
2016-12-05 14:59:36 +03:00
"type": "string",
"format": "int64"
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"creation_date": {
channeldb: save outgoing payments Add structure for outgoing payments. Saving payment in DB after successful payment send. Add RPC call for listing all payments.
2016-12-05 14:59:36 +03:00
"type": "string",
"format": "int64"
},
"path": {
"type": "array",
"items": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "string"
channeldb: save outgoing payments Add structure for outgoing payments. Saving payment in DB after successful payment send. Add RPC call for listing all payments.
2016-12-05 14:59:36 +03:00
}
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"fee": {
channeldb: save outgoing payments Add structure for outgoing payments. Saving payment in DB after successful payment send. Add RPC call for listing all payments.
2016-12-05 14:59:36 +03:00
"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
"lnrpcPaymentHash": {
"type": "object",
"properties": {
"r_hash_str": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "string"
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
},
"r_hash": {
"type": "string",
"format": "byte"
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
}
}
},
"lnrpcPeer": {
"type": "object",
"properties": {
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"pub_key": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "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
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"peer_id": {
"type": "integer",
"format": "int32"
},
"address": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "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
},
"bytes_sent": {
"type": "string",
"format": "uint64"
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"bytes_recv": {
lnrpc: add ping time to peer to the ListPeers response
2017-01-26 05:16:28 +03:00
"type": "string",
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"format": "uint64"
lnrpc: add ping time to peer to the ListPeers response
2017-01-26 05:16:28 +03:00
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"sat_sent": {
lnrpc: returns the node's pubkey instead of lighting_id in ListPeers
2016-10-27 00:31:41 +03:00
"type": "string",
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"format": "int64"
lnrpc: returns the node's pubkey instead of lighting_id in ListPeers
2016-10-27 00:31:41 +03:00
},
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"
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"inbound": {
"type": "boolean",
"format": "boolean"
},
"ping_time": {
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": "int64"
}
}
},
"lnrpcPendingChannelRequest": {
lnrpc: augment the PendingChannels RPC to include details of closed channels This commit adds some additional fields to the PendingChannels RPC s.t users will be able to use the RPC to gain a complete view w.r.t where all the funds within the daemon are, and how soon they can be retrieved. The following information is now returned: * all channels pending open * all channels pending cooperative close * all channels pending force close
2017-05-05 01:34:02 +03:00
"type": "object"
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
},
"lnrpcPendingChannelResponse": {
"type": "object",
"properties": {
lnrpc: augment the PendingChannels RPC to include details of closed channels This commit adds some additional fields to the PendingChannels RPC s.t users will be able to use the RPC to gain a complete view w.r.t where all the funds within the daemon are, and how soon they can be retrieved. The following information is now returned: * all channels pending open * all channels pending cooperative close * all channels pending force close
2017-05-05 01:34:02 +03:00
"total_limbo_balance": {
"type": "string",
"format": "int64"
},
"pending_open_channels": {
"type": "array",
"items": {
"$ref": "#/definitions/PendingChannelResponsePendingOpenChannel"
}
},
"pending_closing_channels": {
"type": "array",
"items": {
"$ref": "#/definitions/PendingChannelResponseClosedChannel"
}
},
"pending_force_closing_channels": {
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": "array",
"items": {
lnrpc: augment the PendingChannels RPC to include details of closed channels This commit adds some additional fields to the PendingChannels RPC s.t users will be able to use the RPC to gain a complete view w.r.t where all the funds within the daemon are, and how soon they can be retrieved. The following information is now returned: * all channels pending open * all channels pending cooperative close * all channels pending force close
2017-05-05 01:34:02 +03:00
"$ref": "#/definitions/PendingChannelResponseForceClosedChannel"
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
}
}
}
},
"lnrpcPendingUpdate": {
"type": "object",
"properties": {
"txid": {
"type": "string",
"format": "byte"
lnrpc: add output_index field to PendingUpdate message Because we want to persist the state of the channel once the funding transaction has been broadcast rather than once it has been fully opened, we need to report the funding transaction ID to the UI or tests when the transaction is pending, rather than after it has been confirmed.
2017-01-24 04:57:45 +03:00
},
"output_index": {
"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
}
}
},
lnrpc: convert QueryRoute to QueryRoutes This commit converts the previous QueryRoute command to a new command: QueryRoutes. This command is identical to QueryRoute other than the fact that it’s able to return multiple routes rather than a single route.
2017-03-21 05:01:32 +03:00
"lnrpcQueryRoutesRequest": {
"type": "object",
"properties": {
"pub_key": {
"type": "string"
},
"amt": {
"type": "string",
"format": "int64"
}
}
},
"lnrpcQueryRoutesResponse": {
"type": "object",
"properties": {
"routes": {
"type": "array",
"items": {
"$ref": "#/definitions/lnrpcRoute"
}
}
}
},
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
"lnrpcRoute": {
"type": "object",
"properties": {
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"total_time_lock": {
"type": "integer",
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
"format": "int64"
},
"total_fees": {
"type": "string",
"format": "int64"
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"total_amt": {
"type": "string",
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
"format": "int64"
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
},
"hops": {
"type": "array",
"items": {
"$ref": "#/definitions/lnrpcHop"
}
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
}
}
},
"lnrpcRoutingPolicy": {
"type": "object",
"properties": {
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"time_lock_delta": {
"type": "integer",
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
"format": "int64"
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"min_htlc": {
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
"type": "string",
"format": "int64"
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"fee_base_msat": {
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
"type": "string",
"format": "int64"
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"fee_rate_milli_msat": {
"type": "string",
lnrpc: recompile protos
2016-12-27 08:45:01 +03:00
"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
"lnrpcSendCoinsRequest": {
"type": "object",
"properties": {
"addr": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "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
},
"amount": {
"type": "string",
"format": "int64"
}
}
},
"lnrpcSendCoinsResponse": {
"type": "object",
"properties": {
"txid": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "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
}
}
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"lnrpcSendManyRequest": {
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": "object",
"properties": {
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"AddrToAmount": {
"type": "object",
"additionalProperties": {
"type": "string",
"format": "int64"
}
}
}
},
"lnrpcSendManyResponse": {
"type": "object",
"properties": {
"txid": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "string"
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
}
}
},
"lnrpcSendRequest": {
"type": "object",
"properties": {
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
"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": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "string"
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
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"amt": {
"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
"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": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "string"
lnrpc: return encoded payReq in AddInvoice, accept payReq's in SendPayment
2017-01-03 02:31:38 +03:00
},
"payment_request": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "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": {
lnrpc: return route taken in SendPayment response
2017-01-17 07:35:29 +03:00
"type": "object",
"properties": {
lnrpc: include payment preimage in SendPayment response
2017-02-21 10:54:52 +03:00
"payment_preimage": {
"type": "string",
"format": "byte"
},
lnrpc: return route taken in SendPayment response
2017-01-17 07:35:29 +03:00
"payment_route": {
"$ref": "#/definitions/lnrpcRoute"
}
}
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
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"lnrpcSetAliasRequest": {
"type": "object",
"properties": {
"new_alias": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "string"
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
}
}
},
"lnrpcSetAliasResponse": {
"type": "object"
},
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
"lnrpcTransaction": {
"type": "object",
"properties": {
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"tx_hash": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "string"
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
},
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
"amount": {
lnrpc: switch Transaction.Amount from double (BTC) to int64 (sat)
2017-03-06 01:53:37 +03:00
"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
},
fundingmanager: change funding messages to use server.sendToPeer Previously, during the channel funding process, peers sent wire messages using peer.queueMsg. By switching to server.sendToPeer, the fundingManager is more resilient to network connection issues or system restarts during the funding process. With server.sendToPeer, if a peer gets disconnected, the daemon can attempt to reconnect and continue the process using the peer’s public key ID.
2017-01-13 06:40:38 +03:00
"num_confirmations": {
"type": "integer",
"format": "int32"
},
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
"block_hash": {
lnrpc: re-compile protos with protoc v3.0.2 add json_name option This commit modifies the protobuf file and most of the auto-generated files to be generated by protoc version v3.0.2. Additionally, this fixes a minor cosmetic regression within the `lncli` command line tool which caused the JSON responses to be rendered in `camelCase` rather than `snake_case`. We fix this by specifying the `json_name` for each relevant RPC response.
2017-02-28 06:03:43 +03:00
"type": "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
},
"block_height": {
"type": "integer",
"format": "int32"
},
"time_stamp": {
"type": "string",
"format": "int64"
},
"total_fees": {
"type": "string",
"format": "int64"
}
}
},
"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