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.
For security reasons, browsers are limited in the header fields they can
send when opening a WebSocket connection. Specifically, the macaroon
cannot be sent in the Grpc-Metadata-Macaroon header field as that would
be possible for normal REST requests. Instead we only have the special
field "Sec-Websocket-Protocol" that can be used to transport custom
data. We allow the macaroon to be sent there and transform it into a
proper header field for the target request.
This commit clamps all user-chosen CLTVs in LND to be at least 18, which
is the new conservative value used in the sepc. This minimum is applied
uniformly to forwarding CLTV deltas (via channel updates) as well as
final CLTV deltas for new invoices.
This reduces the flakiness of the CPFP test by asserting the wallet has
seen the unspent output before attempting to perform the walletkit's
BumpFee method.
Previously the attempt to bump the fee of the target transaction could
be made before the wallet had had a chance to fully process the
transaction, causing a flaky error.
This is useful when we wish to have a channel frozen for a specific
amount of blocks after its confirmation. This could also be done with an
absolute thaw height, but it does not suit cases where a strict block
delta needs to be enforced, as it's not possible to know for certain
when a channel will be included in the chain. To work around this, we
add a relative interpretation of the field, where if its value is below
500,000, then it's interpreted as a relative height. This approach
allows us to prevent further database modifications to account for a
relative thaw height.
