This commit restructures an invoice's ContractTerms to better encompass
the restrictions placed on settling. For instance, the final ctlv delta
and invoice expiry are moved from the main invoice body (where
additional metadata is stored). Additionally, it moves the State field
outside of the terms since it is rather metadata about the invoice
instead of any terms offered to the sender in the payment request.
This commit modifies the FetchPayment method to return MPPayment structs
converted from the legacy on-disk format. This allows us to attach the
HTLCs to the events given to clients subscribing to the outcome of an
HTLC.
This commit also bubbles up to the routerrpc/router_server, by
populating HTLCAttempts in the response and extracting the legacy route
field from the HTLCAttempts.
With this PR we deprecate fields that have been specifically added to
to work around a bug in the gRPC/REST gateway that didn't allow bytes
fields to be encoded in REST requests.
That bug has now been fixed so the fields are no longer required.
To make it more clear how bytes fields have to be used in REST,
comments have been added to all those fields.
This commit parses mpp_total_amt_msat and mpp_payment_addr from the
SendToRoute rpc and populates an MPP record on the internal hop
reprsentation. When the router goes to encode the onion packet, these
fields will be serialized for the destination. We also populate the mpp
fields when marshalling routes in rpc responses.
This commit add mpp_total_amt_msat and mpp_payment_addr to the Hop
message. Doing so enables users submitting mpp payments via rpc to
set these parameters for the destination. In addition, it will allow us
to display these fields in rpc responses.
In this commit, we create a new chainfee package, that houses all fee
related functionality used within the codebase. The creation of this new
package furthers our long-term goal of extracting functionality from the
bloated `lnwallet` package into new distinct packages. Additionally,
this new packages resolves a class of import cycle that could arise if a
new package that was imported by something in `lnwallet` wanted to use
the existing fee related functions in the prior `lnwallet` package.
Probabilities are no longer returned for querymc calls. To still provide
some insight into the mission control internals, this commit adds a new
rpc that calculates a success probability estimate for a specific node
pair and amount.
With a separate proto message, it becomes possible to also return the
pair data for a single pair. This prepares for the new mc probability
querying rpc.
This commit adds the total observed lifetime of a channel and the
totaluptime of its remote peer to the lnrpc channel struct. These
fields are marked as experimential because they are subject to
change.
This commit changes mission control to partially base the estimated
probability for untried connections on historical results obtained in
previous payment attempts. This incentivizes routing nodes to keep all
of their channels in good shape.
Probability estimates are amount dependent. Previously we assumed an
amount, but that starts to make less sense when we make probability more
dependent on amounts in the future.
This sets the `jstype` option to `JS_STRING` for all `chan_id` fields
in the proto rpc definition. `chan_id` is a 64 bit integer, which is
not natively supported by javascript's floating-point `number` with
only 52 bit precision. Nevertheless, by default protobuf will use the
`number` type for 64 bit integer fields in javascript, which can cause
loss of precision problems with `chan_id`. Explicitly setting the type
for javascript as a string will prevent these issues, and should not
interfere with its use as an identifier.
With the introduction of the max CLTV limit parameter, nodes are able to
reject HTLCs that exceed it. This should also be applied to path
finding, otherwise HTLCs crafted by the same node that exceed it never
left the switch. This wasn't a big deal since the previous max CLTV
limit was ~5000 blocks. Once it was lowered to 1008, the issue became
more apparent. Therefore, all of our path finding attempts now have a
restriction of said limit in in order to properly carry out HTLCs to the
network.
In order to prevent future unforeseen issues, we are temporarily
disabling the ability to send custom tlv records to the receiver of a
payment. Currently the receiver does not process or expose these
additional fields via rpc or internally, so they are being disabled
until the end-to-end flow is finished and fully validated.
Extends the invalid payment details failure with the new accept height
field. This allows sender to distinguish between a genuine invalid
details situation and a delay caused by intermediate nodes.
This commit adds a set of htlcs to the Invoice struct and
serializes/deserializes this set to/from disk. It is a preparation for
accurate invoice accounting across restarts of lnd.
A migration is added for the invoice htlcs.
In addition to these changes, separate final cltv delta and expiry
invoice fields are created and populated. Previously it was required
to decode this from the stored payment request. The reason to create
a combined commit is to prevent multiple migrations.
This commit modifies paymentLifecycle so that it not only feeds
failures into mission control, but successes as well.
This allows for more accurate probability estimates. Previously,
the success probability for a successful pair and a pair with
no history was equal. There was no force that pushed towards
previously successful routes.
In this commit, we add a new field to the Hop proto to allow callers to
be able to specify TLV records for the SendToRoute call, and also to be
able to display TLV records that were used during regular path finding.
We also update SendPayment to support dest TLV records.
In this commit, we address an issue that would cause us to scan from the
genesis block for the spend of an output that we wish to use to raise
the fee of a transaction through CPFP. This was due to setting a 0
height hint when constructing the input required by the sweeper and was
discovered due to the recently added validation checks at the chain
notifier level. We'll now use the current height as the height hint
instead as the sweeper will end up creating a new transaction that
spends the input.
Previously mission control tracked failures on a per node, per channel basis.
This commit changes this to tracking on the level of directed node pairs. The goal
of moving to this coarser-grained level is to reduce the number of required
payment attempts without compromising payment reliability.
Align naming better with the lightning spec. Not the full name of the
failure (FailIncorrectOrUnknownPaymentDetails) is used, because this
would cause too many long lines in the code.
lnrpc/rpc.proto: updates RoutingPolicy last_update number
rpcserver: adding LastUpdate field to marshalDbEdge
This commit adds a LastUpdate field to each RoutingPolicy, it will show
the time each RoutingPolicy was updated.
lnrpc: regenerating proto files
In this commit two fields were added to the Channl RPC result in both
open and pending states.
The fields: local_chan_reserve, remote_chan_reserve represents the
reservation the nodes are rquired to keep in both sides of the channel.
This is usefull when calculating the "real" inbound and outbound
liquidity in an accurate way.
In this commit, we modify the parsing of user provided outpoints to
ensure that we catch a nil (empty) output early. Otherwise, passing a
set of incorrect arguments would cause `lnd` to crash.
This RPC exposes the recently added BumpFee functionality to the
UtxoSweeper in order to allow users of the RPC to manually bump fees of
low fee inputs/transactions.
This commit exposes the three main parameters that influence mission
control and path finding to the user as command line or config file
flags. It allows for fine-tuning for optimal results.
Previously every payment had its own local mission control state which
was in effect only for that payment. In this commit most of the local
state is removed and payments all tap into the global mission control
probability estimator.
Furthermore the decay time of pruned edges and nodes is extended, so
that observations about the network can better benefit future payment
processes.
Last, the probability function is transformed from a binary output to a
gradual curve, allowing for a better trade off between candidate routes.
This PR replaces the previously used edge and node ignore lists in path
finding by a probability based system. It modifies path finding so that
it not only compares routes on fee and time lock, but also takes route
success probability into account.
Allowing routes to be compared based on success probability is achieved
by introducing a 'virtual' cost of a payment attempt and using that to
translate probability into another cost factor.
This commit upgrades the protobuf version. Compared to the previous
v1.2.0 it generates smaller diffs in generated code. This change was
introduced in:
fffb0f7828
This fixes a bug where the RHashStr field on the PaymentHash request for
SubscribeSingleInvoice was being ignored. This replaces the PaymentHash
message for the SubscribeSingleInvoice request with a new message called
SubscribeSingleInvoiceRequest that contains only the RHash field.
This commit modifies the invoice registry to handle invoices for which
the preimage is not known yet (hodl invoices). In that case, the
resolution channel passed in from links and resolvers is stored until we
either learn the preimage or want to cancel the htlc.
This commit moves the query routes backend logic from the main
rpc server into the sub server. It is another step towards splitting up
the main rpc server code.
In addition to this, a unit test is added to verify rpc parameter
parsing.
Now that QueryRoutes gained the ability to route from any source node
and takes in edge and node black lists, all pieces are in place to have
users implemented their own k-shortests path algorithm. Or any other algorithm
they might wish to use and currently can't.
This commit marks the num_routes field as deprecated as a preparation
for removing k-shortest for lnd.
This commit allows the execution of QueryRoutes to be controlled using
lists of black-listed edges and nodes. Any path returned will not pass
through the edges and/or nodes on the list.
In this commit, we add two new address types to `NewAddressRequest`.
These address types will allow the caller to retrieve the last _unused_
address, rather than always rotating to the next address in the
keychain.
In this commit, we rename the new `MaxHtlc` field to `MaxHtlcMsat`. We
do this in order to adhere to the new practice to suffix each amount
related field with their proper unit.
In this commit, we implement the full RouterServer as specified by the
newly added sub-service as defined in router.proto. This new sub-server
has its own macaroon state (but overlapping permissions which can be
combined with the current admin.macaroon), and gives users a simplified
interface for a gRPC service that is able to simply send payment. Much
of the error reporting atm, is a place holder, and a follow up commit
will put up the infrastructure for a proper set of errors.
This commit is a step to split the lnwallet package. It puts the Input
interface and implementations in a separate package along with all their
dependencies from lnwallet.
Update is necessary to get protoc to generate files in the right
directory when using modules outside the gopath. The old version of this
dependency did not support paths=source_relative.
This commit also fixes a build error in lnd_test.go because of a
slight difference in generated code.
This commit adds a new service lnrpc/autopilot, that is to be used to
communicate with the running autopilot. Currently a RPC for getting the
status of the agent is included, as well as enabling/disabling at
runtime.
Returns a brief json summary of each utxo found by calling
ListUnspentWitness in the wallet. The two arguments are the
minimum and maximum number of conrfirmations (0=include
unconfirmed)
In this commit, we implement the newly defiend WalletKitServer gRPC
service. We use the same template w.r.t build tags as the existing
signrpc service.
In this commit, we add a new sub-RPC server to the existing set of gRPC
servers. This new sub-RPC server is the WalletKit. It's a utility
toolkit that contains method which allow clients to perform common
interactions with a wallet such as getting a new address, or sending a
transaction. It also includes some supplementary actions such as fee
estimation.
One thing to note in the RPC file is that we _import_ the existing
signer.proto file in order to get at some existing proto definitions
which are useful in our use case.
In this commit, we add the ComputeInputScript which will allow callers
to obtain witnesses for all outputs under control of the wallet. This
allows external scripting of things like coin join, etc.
In this commit, we add the glue infrastructure to make the sub RPC
server system work properly. Our high level goal is the following: using
only the lnrpc package (with no visibility into the sub RPC servers),
the RPC server is able to find, create, run, and manage the entire set
of present and future sub RPC servers. In order to achieve this, we use
the reflect package and build tags heavily to permit a loosely coupled
configuration parsing system for the sub RPC servers.
We start with a new `subRpcServerConfigs` struct which is _always_
present. This struct has its own group, and will house a series of
sub-configs, one for each sub RPC server. Each sub-config is actually
gated behind a build flag, and can be used to allow users on the command
line or in the config to specify arguments related to the sub-server. If
the config isn't present, then we don't attempt to parse it at all, if
it is, then that means the RPC server has been registered, and we should
parse the contents of its config.
The `subRpcServerConfigs` struct has two main methods:
`PopulateDependancies` and `FetchConfig`. The `PopulateDependancies` is
used to dynamically locate and set the config fields for each new
sub-server. As the config may not actually have any fields (if the build
flag is off), we use the reflect pacakge to determine if things are
compiled in or not, then if so, we dynamically set each of the config
parameters. The `PopulateDependancies` method implements the
`lnrpc.SubServerConfigDispatcher` interface. Our goal is to allow sub
servers to look up their actual config in this main config struct. We
achieve this by using reflect to look up the target field _as if it were
a key in a map_. If the field is found, then we check if it has any
actual attributes (it won't if the build flag is off), if it is, then we
return it as we expect it to be populated already.
In this commit, we create a lnrpc.SubServerDriver for signrpc. Note that
this file will only have its init() method executed if the proper build
flag is on. As a result, only if the build flag is set, will the RPC
server be registered, and visible at the packge lnrpc level for the root
server to manipulate.
In this commit, we add a full implementation of the new SignerServer sub
RPC service within the main root RPC service. This service is able to
fully manage its macaroons, and service any connected clients. Atm, this
service only has a single method: SignOutputRaw which mimics the
existing lnwallet.Signer interface within lnd itself. As the API's are
so similar, it will be possible for a client to directly use the
lnwallet.Signer interface, and have a proxy that sends the request over
RPC, and translates the proto layer on both sides. To the client, it
doesn't know that it's using a remote, or local RPC.
In this commit, we add the scafolding for the future sub-server RPC
system. The idea is that each sub server will implement this particular
interface. From there on, a "root" RPC server is able to query this
registry, and dynamically create each sub-sever instance without
knowing the details of each sub-server.
In the init() method of the pacakge of a sub-server, the sub-server is
to call: RegisterSubServer to claim its namespace. Afterwards, the root
RPC server can use the RegisteredSubServers() method to obtain a slice
of ALL regsitered sub-servers. Once this list is obtained, it can use
the New() method of the SubServerDriver struct to create a new
sub-server instance.
Each sub-server needs to be able to locate it's primary config using the
SubServerConfigDispatcher interface. This can be a map of maps, or a
regular config structr. The main requirement is that the sub-server be
able to find a config under the same name that it registered with. This
string of abstractions will allow the main RPC server to find, create,
and run each sub-server without knowing the details of its configuration
or its role.
In this commit, we add a new proto generation script to match the one in
the main lnrpc package. This script differs, as we don't need to
generate the REST proxy stuff (for now).
In this commit, we introduce a new sub-package within the greater RPC
package. This new sub-package will house a new set of sub-RPC servers
to expose experimental features behind build flags for upstream
consumers. In this commit, we add the first config for the service,
which will simply expose the lnwallet.Signer interface over RPC.
In the default file, we have what the config will be if the build tag
(signerrpc) is off. In this case, the config parser won't detect any
times, and if specified will error out. In the active file, we have the
true config that the server will use. With this new set up, we'll
exploit these build flags heavily in order to create a generalized
framework for adding additional sub RPC servers.
In this commit, we modify the AbandonChannel REST endpoint to avoid
conflicting with the CloseChannel's. Otherwise, if a debug build of lnd
is being used, there's no way of closing channels through the REST API
as it's been overwritten by AbandonChannel.
By passing a pubkey into SendToRoute, it becomes unnecessary for lnd to
query the channel graph to retrieve the hop pubkey. This allows routes
over private channels that are not present in the graph.
In this commit, we address a slight regression in the defaults provided
by the OpenChannel RPC with regards to spending unconfirmed outputs to
fund funding transactions. We now add a new boolean parameter to
OpenChannelRequest: SpendUnconfirmed. If set, we'll use this to
indicate to the server that the funding transaction of the channel to be
created can spend the wallet's unconfirmed outputs to fund it. This
addition is needed because otherwise, if the caller doesn't specify a
MinConfs parameter to the request, then a default of 0 will be used,
which is not ideal.
In this commit, we remove the unnecessary NewWitnessAddress RPC. We do
this as, at the moment, we only expose the wallet to generate witness
addresses. Now that the RPC has been removed, its REST endpoint has been
assigned to the NewAddress RPC, which should be the de facto way of
having the wallet generate any type of supported address.
Fixes#1986.
Using AbandonChannel, a channel can be abandoned. This means
removing all state without any on-chain or off-chain action.
A close summary is the only thing that is stored in the db after
abandoning.
A specific close type Abandoned is added. Abandoned channels
can be retrieved via the ClosedChannels RPC.
In this commit, we extend the current SubscribeInvoice streaming RPC
call. We add two new values to the InvoiceSubscription message:
add_index and settle_index. These fields have also been added to the
current Invoice message. Each time a new invoice is added, the add index
will be incremented. Each time a new invoice is settled the settle index
will be incremented. The new field on the InvoiceSubscription message
allow callers to specify the last add index and the last settle index
they know of. With this new addition, callers will now be able to
reliably receive notifications for new received payments.
Care has been taken to ensure that these changes are backwards
compatible. If callers don't specify either of the new fields, then they
won't receive any notification backlog at all.
Fixes#862.
- Extend SendRequest and QueryRoutesRequest protos
- newRoute function takes fee limit and cuts off routes that exceed it
- queryRoutes, payInvoice and sendPayment commands take the feeLimit inputs and pass them down to newRoute
- When no feeLimit is included, don't enforce any feeLimits at all (by setting feeLimit to maxValue)
In this commit, we add a `private` field to the `AddInvoice` RPC's
request to denote whether the invoice being created should include
routing hints for private channels to assist the payer in reaching the
destination.
Changes in gRPC `channelbalance` service response message
of adding `pending_open_balance` parameter with sum of
channels open pending balances denominated in satoshis
In this commit, we add a new method to the RPC service:
ForwardingHistory. This method will allow callers to query for the
completed payment circuits in a particular time slice, skip a series of
events, and also paginate within a time slice.
In this commit, we revamp the WalletUnlocker service to now have a
two-stage init process.
The first (optional) is for the user instantiating a new lnd instance to
call the GenSeed method with an optional aezeed passphrase. The response
to this will be a freshly generated aezeed mnemonic along with the
original enciphered seed.
The second step will be the actual wallet initaliztion. By separating
this step from seed generation, UI's will be able to ensure that the
user has written down the seed, before proceeding and committing the
seed to the internal wallet. The new method InitWallet accepts a wallet
passphrase, the aezeed mnemonic, and the optional passphrase.
This commit adds wallet_best_block_timestamp to the gRPC interface.
This is done in order to allow clients to calculate progress while
lnd syncs to the blockchain. wallet_best_block_timestamp is exposed
via the GetInfo() rpc call. Additionally, IsSynced() returns the
WalletBestBlockTimestamp as the second value in the tuple
that is returned, providing additional detail when querying about the
status of the sync. The BtcWallet interface has also been updated
accordingly.
This commit was created to support the issue to
[Add progress bar for chain sync] (lightninglabs/lightning-app#10) in
lightning-app
Fixes#481.
Prior to this commit, payments stored in the channel DB only kept a
record of the payment hash. This is a problem as the preimage is what
serves as proof of payment and a user should be able to look up this
value in the future (not just immediately after payment).
Instead of storing both the payment hash and the preimage, we store the
preimage only since the hash can be derrived from this using a SHA256.
In the RPC listpayments command, we now give the preimage in addition to
the payment hash.
This commit changes the listinvoices and lookupinvoice endpoints to
avoid collisions when making requests.
We can still retrieve a list of pending invoices with `listinvoices` by
appending the parameter `pending_only=true` to the request URL.
This commit renames the UpdateFee RPC call together
with associated types to UpdateChannelPolicy. In addition
to fees, now also timelock delta can be specified using
this call.
In this commit, we remove the blocks_till_open from
PendingChannelsResponse as in its current state, the values that are
assigned to this field don’t accurately reflect the naming. This has
caused a good bit of confusion amongst users lately. As a result, we’re
temporarily removing this field until we have proper incremental
notifications within the chain notifier.
In this commit we rename the lnrpc.PendingChannelRequest and
lnrpc.PendingChannelResponse to
lnrpc.PendingChannelsRequest/lnrpc.PendingChannelsResponse. We do this
as we strive to ensure that the naming scheme across the RPC interface
is consistent.
In this commit, we expose the new fee control features to the relevant
commands on the command line. This will allow users to have a greater
degree of control of the fees they pay when: sending coins on chain,
opening a channel, or closing a channel.
In this commit, we modify the OpenChannel, CloseChannel, SendCoins, and
SendMany RPC’s to be able to allow users to manually specify their
fees. Users can either specify a target number of confirmations, or a
target value for manual sat/byte.
This commit adds the service WalletUnlocker, which is to be used
for creating a wallet password at first time startup, and unlocking
the wallet. The service exposes the RPC methods CreateWallet and
UnlockWallet.
This commit adds fields that are supported by the BOLT-11 invoice
format to the Invoice and PayReq protos. These fields are
timestamp, expiry, fallback address, description and
description hash.
This commit removes the revocation_delay field from the HTLC proto as
we no longer need this field since the switch to 2-layer HTLC’s. The
2-layer HTLC construction no longer has the CSV delay directly in the
HTLC script itself.
This commit adds to new RPC’s to the Lightning service: UpdateFees and
FeeReport. Additionally, we also update to the latest version of protc,
golang protobuf, and the gRPC gateway.
This commit removes the num_confs parameter within the
OpenChannelRequest struct as it’s no longer applicable with the new
funding workflow. In the new funding workflow, it’s the responder that
decides how many confirmations are required.
In order to not close the payment stream on payment error the additional
field have been added in payment response. Now error from stream Recv()
function means that something has happend inside the client and we unable
to process any payment farther, and error inside the payment response
means, that something wrong has happend with payment itself.
This commit allows users to sign messages with their node's private key
with the SignMessage interface. The signatures are zbase32 encoded for
human readability/paste-ability. Others users can verify that a message
was signed by another node in their channel database with the
VerifyMessage interface.
This commit adds simple non-blocking stop command to lncli, with an
appropriate proto update and implementation within the rpcserver. When
invoked the interrupt handler routine in signal.go with begin the graceful
shutdown of lnd.
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
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 .
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.
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.
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.
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 removes the remote_funding field from the OpenChannel
message as dual funding channels aren’t yet supported at the wire level
within the spec (although the daemon is able to handle them properly).
In place we now add the ‘push_sat’ field which allows the initiator to
push over a certain amount to the responder as part of the initial
state.
This commit adds a number of new RPC’s which allow users to query data
that’s now exposed as part of the new routing package: DescribeGraph,
GetChanInfo, GetNodeInfo, QueryRoute, GetNetworkInfo, and SetAlias.
As a result the former ShowRoutingTable command has been removed as the
underlying graph representation has changed.
This commit expands the data returned by the current GetCurrentHeight
to also return the current best block hash, expanding the method into
GetBestBlock. Additionally, the current best BlockHash is also now
displayed within the GetInfo RPC call.
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.
This commit extracts the channel information that was previously
returned within the ListPeers command to a new RPC command:
ListChannels. Additionally, any pending HTLC’s within the open channel
are also displayed.
This commit adds a new RPC command: `channelbalance` which returns the
sum of all available channel capacity across all open channels. The
total balance is currently returned in units of `satoshis`. Additionally
the `networkHarness` has been modified slightly to allow specifying the
additional "extra" command line parameters when creating the initial
seed nodes. Minor refactoring within the integration tests has been
undertaken in order to increase code re-use across tests.
Closes#29.
