In this commit, we extend the `BuildRoute` method and RPC on the router
sub-server to accept a raw payment address which will be included as
part of an MPP payload for the finla hop. This change actually also
allows users to craft their own MPP paths using BuildRoute+SendToRoute.
Our primary goal however, was to fix some broken itests since we now
require the payAddr to be present for ALL payments other than key send
payments.
Previously, the verbose output of listsweeps would fail if we did not
find some sweeps in our wallet's listtransactions output. This could be
the case for sweeps that were rbf-ed, so the endpoint would fail. This
commit also updates the listsweeps endpoint to always check against the
wallet, so that we do not return these discarded sweeps that never
confirmed.
Add more fields to channel acceptor response so that users can have more
fine grained control over their incoming channels. With our chained
acceptor, it is possible that we get inconsistent responses from
multiple chained acceptors. We create a conjugate repsponse from all the
set fields in our various responses, but fail if we get different, non-
zero responses from our various acceptors. Separate merge functions are
used per type so that we avoid unexpected outcomes comparing interfaces
(panic on comparing types that aren't comparable), with casting used
where applicable to avoid code duplication.
This commit adds an optional error message to the channel acceptor's
reponse to allow operators to inform (or insult) unsuccessful channel
initiators as to the reason for their rejection.
This field is added in addition to the existing accept field to maintain
backwards compatibity. If we were to deprecate accept and interpret a
non-nil error as rejecting the channel, then received a response with
accept=false and a nil error, the server cannot tell whether this is a
legacy rejection or new mesage type acceptance (due to nil error),
so we keep both fields.
This will prevent the subservers from writing macaroons to disk
when the stateless_init flag is set to true. It accomplishes
this by storing the StatelessInit value in the Macaroon Service.
This commit adds the --stateless_init flag to all three wallet unlocker
operations. Once you initialize a wallet stateless, you need to set
this flag for every further wallet unlocker operation. Otherwise you
risk non-encrypted macaroon information to leak to the underlying
system.
The 'payment already exists' case is common in restart scenarios. With
this commit it is no longer necessary to string-match on the error
message. Implementation is identical to SendPaymentV2.
The internal lock ID that the wallet kit subserver uses to lock inputs
for itself shouldn't be allowed to be used when locking inputs manually
over the RPC.
As a convenience method for users to look up what RPC method URIs exist
and what permissions they require, we add a new ListPermissions call
that simply returns all registered URIs (including internal and external
subservers) and their required permissions.
To make sure we can use the abandonchannel RPC for getting rid of
externally funded channels who's funding transaction was never
published, we allow the RPC to be used on non-dev builds for externally
funded and pending channels only.
In this commit, we update the hop hint selection to account for the fact
that with MPP, a single payment may consume multiple channels. As is, if
a user only has two 0.5 BTC channels, and tries to make a 1 BTC channel,
then the current logic won't include any hop hints.
To solve this, we first add all the channels which in isolation can
carry the payment in question. We then do another pass that accumulates
channels until either we reach our hop-hint limit, or the total
bandwidth that we've accumulate is greater than 2x the payment amount.
