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