A profile file can contain multiple profile entries. Each
entry has a name, a set of default options to use and an optional list
of macaroons in a jar. The profile file can be
serialized/deserialized to and from JSON.
To fix the compiler of some IDEs complaining about types and functions
it cannot find, we rename all files that contain tests back to lnd_xxx_test.go to make
sure they are compiled correctly.
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 the permission system even more fine-grained, we want to allow
users to specify exact gRPC URIs in the macaroon permissions instead of
just broad entity/action groups.
For this we add the special entity "uri" which allows an URI specific
permission to be defined as "uri:/lnrpc.Lightning/GetInfo" for example
instead of the more coarse "info:read" which gives access to multiple
URIs.
In this commit, we update the `sample-lnd.conf` example config file to
be up to date with all the new configuration parameters we've added over
the past few release.
This commit changes the logic when garbage collecting forwarding
packages such that they are removed once when the function is called,
and then again upon subsequent ticks. This allows us to bump the
peer timer to 1 hour to limit the number of db transactions happening
in lnd. The forwarding packages need to be removed initially as
otherwise a flappy node will never have them garbage collected.
As a follow-up to #4560 we actually need to hold the reservation mutex
during the full loop where we count the pending reservations. Otherwise
the results might become inaccurate for concurrent funding flows.
We change the external funding test to now test two more things: First
that we can open multiple externally funded channels without needing to
lift the default --maxpendingchannels setting. Then we test that we can
use the safer pending_funding_shim_only flag of the AbandonChannel RPC
to get rid of the never confirming external channels.
As a preparation to test accepting multiple externally funded channels
at the same time, we extract the deriveFundingShim function from the
external funding integration test.
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.
Externally funded channels are expected by the user and explicitly
registered through the use of a funding shim and should therefore not
count towards the max pending channel count which is primarily there to
mitigate DoS attacks.
Currenlty the maxHtlcs value is recomputed after receiving
accept_channel. This works when the derivation is deterministic, howver
we now allow the user to manually override this value from open_channel.
As such, we must retain the chosen value in memory throughout the
funding process, otherwise the initiator would revert to the
deterministic derivation and the two endpoints will disagree on the
correct max-htlcs value in their view of the other's policy.
