This change instructs the REST proxy server to overwrite its default
JSON marshaler settings. That allows us to set EmitDefaults to true
which will result in all JSON fields returned in REST responses to
be fully populated, even if their values are falsey.
This commit adds PendingOpenChannel to SubscribeChannelEvents stream in
the gRPC API.
This is useful for keeping track of channel openings that Autopilot does.
It can also be used for the non-initator side of a channel opening to keep
track of channel openings.
Returning from the sendPayments method closes the underlying stream, so
we would risk payments still being in flight when returning.
We add the running goroutines to a waitgroup, such that we can wait for
them all to exit before exiting and closing the stream.
In case an error is encountered in the process, we will return directly,
which will close the `reqQuit` channel and prompt the gorpoutines to
shut down.
This commit fixes a problem that could arise when handling a continuous
stream of payIntents. We would risk the client sending a set of payment
intents and closing the stream, but we wouldn't be sure the sendLoop had
read all messages on the `payChan` before exiting with the nil error
from the `errChan`.
Instead, we close the `payChan` to indicate that no more payments are
going to be received.
This commit fixes a potential issue in the bidirectional sendPayment
case, where multiple goroutines could be sending on an errChan with
buffer 1. Instead we select on default as well, as it is enough to
handle the first error that was received.
Intead of checking for shutdown in the receive loop, we let the sendLoop
handle it, as it can return the error directly. This works since the
returning sendLoop will trigger a close of the `reqQuit` channel, which
will ensure the receive loop exits.
The default was increased for the main sendpayment RPC in commit
d3fa9767a9729756bab9b4a1121344b265410b1a. This commit sets the
same default for QueryRoutes, routerrpc.SendPayment and
router.EstimateRouteFee.
In this commit, we implement the currently defined transition methods
for the new `FundingStateStep` method. At this point, we're now able to
serve the "responder" of the externally initiated channel funding flow
by being able to register and cancel a funding flow according to its
expected pending channel ID.
In this commit, we update the `OpenChannel` method to observe the new
`funding_shim` field in the main open channel request. If this is
specified, and is a channel point shim, then we'll create a custom
`chanfunding.Assembler` for the wallet to use in place of the regular
funding workflow.
With this commit, the "initiator" of an external funding flow can now
delegate the remainder of the channel funding workflow to lnd.
In this commit, we start to expose some of the new external funding
functionality over the RPC interface.
First, we add a new `funding_shim` field to the regular `OpenChannel`
method. This can be used by a caller to express that certain parameters
of the funding flow have already been negotiated outside the protocol,
and should be used instead. For example, a shim can be provided to use a
particular key for the commitment key (ideally cold) rather than use one
this is generated by the wallet as normal, or signal that signing will
be carried out in an interactive manner (PSBT based).
Next, we add a brand new method: `FundingStateStep`. FundingStateStep is
an advanced funding related call that allows the caller to either
execute some preparatory steps for a funding workflow, or manually
progress a funding workflow. The primary way a funding flow is
identified is via its pending channel ID. As an example, this method can
be used to specify that we're expecting a funding flow for a particular
pending channel ID, for which we need to use specific parameters.
Alternatively, this can be used to interactively drive PSBT signing for
funding for partially complete funding transactions.
The new transition methods (funding state machine modifiers) in this
commit allow a party to register a funding intent that should be used
for a specified incoming pending channel ID. The "responder" to the
external channel flow should use this to prep lnd to be able to handle
the channel flow properly.
Earlier we used emtpy grpc server options if custom listeners were set.
This was done to disable TLS. Now, we reuse the same server options as
for the regular listeners, in a move towards enabling TLS also here.
In this commit, the channelEventStore in the channel
fitness subsystem is changed to identify channels
by their outpoint rather than short channel id. This
change is made made becuase outpoints are the preferred
way to expose references over rpc, and easier to perform
queries within lnd.
Upgrade logging of channel uptime/lifespan query errors
to returning the error, with the exception of the case
where the channel is known to the store. This error is
logged, due to the potential for race conditions between
the channel event store being notified of a new open
channel and the rpc channel subscription creating a rpc
channel struct (which queries for uptime).
In the process, we also move the feature serialization into the
invoicesrpc package, so that it can be shared between the invoicesrpc
and main rpcserver.
This commit prepares for more manipulation of custom records. A list of
tlv.Record types is more difficult to use than the more basic
map[uint64][]byte.
Furthermore fields and variables are renamed to make them more
consistent.
This commit is adapted from @Bluetegu's original
pull request #1462.
This commit reads an optional address to pay funds out to
from a user iniitiated close channel address. If the channel
already has a shutdown script set, the request will fail if
an address is provided. Otherwise, the cooperative close will
pay out to the address provided.
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.
In this commit, we update the `AbandonChannel` method to also remove the
state from the countract court as well as the channel graph. Abandoning
a channel is now a three step process: remove from the open channel
state, remove from the graph, remove from the contract court. Between
any step it's possible that the users restarts the process all over
again. As a result, each of the steps below are intended to be
idempotent.
We also update the integration test to assert that no channel is found
in the graph any longer. Before this commit, this test would fail as the
channel was still found in the graph, which can cause other issues for
an operational daemon.
Fixes#3716.
