Commit Graph

16 Commits

Author SHA1 Message Date
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