Commit Graph

172 Commits

Author SHA1 Message Date
Olaoluwa Osuntokun
1dfda91415
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-08 14:46:24 -08:00
Olaoluwa Osuntokun
3a851d8bc6
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-27 21:04:42 -06:00
bryanvu
508138f8c8 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-02-24 11:37:33 -08:00
bryanvu
b21bd351e8 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-02-21 19:21:19 -08:00
Olaoluwa Osuntokun
ef6ddcf788
lnrpc: include payment preimage in SendPayment response 2017-02-21 01:43:45 -08:00
Olaoluwa Osuntokun
3988473d45
lnrpc: add ping time to peer to the ListPeers response 2017-01-25 18:16:37 -08:00
Olaoluwa Osuntokun
faae0b3bf2
lnrpc: add new RPC to decode payment requests 2017-01-17 13:25:03 -08:00
Olaoluwa Osuntokun
765d9fd5e9
lnrpc: return route taken in SendPayment response 2017-01-16 20:37:15 -08:00
Olaoluwa Osuntokun
d79530e25d
lnrpc: add encoded payment requests to the ListInvoices response
This commit modifies the ListInvoice RPC to also return the encoded
payment request in the response. With this change it’ll be possible to
always obtain the encoded payment for any invoice, rather than only
being able to obtain it directly after the creation of an invoice.
2017-01-12 18:51:49 -08:00
Olaoluwa Osuntokun
a1d584f1b2
lnrpc: recompile protos 2017-01-09 19:01:10 -08:00
Olaoluwa Osuntokun
ca84c620ea
lnrpc: return encoded payReq in AddInvoice, accept payReq's in SendPayment 2017-01-02 15:31:44 -08:00
Olaoluwa Osuntokun
480fd8d03f
lnrpc: rename r_hash to payment_hash in Payment message 2016-12-30 16:38:54 -08:00
Olaoluwa Osuntokun
f9f840feb6
lnrpc: recompile protos 2016-12-27 16:44:45 -08:00
BitfuryLightning
eb4d0e035e 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-27 16:16:23 -08:00
Olaoluwa Osuntokun
a011a3f414
lnrpc: add testnet bool to GetInfo RPC, remove lightning_id 2016-12-12 15:56:54 -08:00
bryanvu
2bf5794645 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-22 14:57:03 -06:00
Olaoluwa Osuntokun
39262c66d6
lnrpc: add current block height and a 'synced 'bit to GetInfo response 2016-11-14 15:54:53 -08:00
Olaoluwa Osuntokun
df74d8981d
lnrpc: display creation date and settle date for Invoices 2016-11-12 18:09:36 -08:00
Olaoluwa Osuntokun
64396a69c3
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-10 17:33:34 -08:00
Olaoluwa Osuntokun
de1a3e1436
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-27 19:41:51 -07:00
Olaoluwa Osuntokun
bde47f6ebb
lnrpc: returns the node's pubkey instead of lighting_id in ListPeers 2016-10-26 14:31:48 -07:00
Olaoluwa Osuntokun
566cd86a1d
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-15 14:39:00 -07:00