In this commit, we add `msats` to the return value of `DecodePayReq` to
ensure we always show full value information as we're moving to do
generally for all RPC calls that deal with off-chain amounts.
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 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.
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 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.
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.
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.
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.
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.
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.
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 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.
