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.
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.
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.
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.
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>
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.
