To make it possible to use a remote lnrpc server as a signer for our
wallet, we need to change our main interface to sign the message instead
of the message's digest. Otherwise we'd need to alter the
lnrpc.SignMessage RPC to accept a digest instead of only the message
which has security implications.
The FundingPsbtFinalize step is a safety measure that assures the final
signed funding transaction has the same TXID as was registered during
the funding flow and was used for the commitment transactions.
This step is cumbersome to use if the whole funding process is completed
external to lnd. We allow the finalize step to be skipped for such
cases. The API user/script will need to make sure things are verified
(and possibly cleaned up) properly.
This commit updates call-sites to use the proper dust limits for
various script types. This also updates the default dust limit used
in the funding flow to be 354 satoshis instead of 573 satoshis.
To further separate the channel graph from the channel state, we
refactor the AddrsForNode method to use the graphs's public methods
instead of directly accessing any buckets. This makes sure that we can
have the channel state cached with just its buckets while not using a
kvdb level cache for the graph.
At the same time we refactor the graph's test to also be less dependent
upon the channel state DB.
As a preparation to have the method for querying the addresses of a node
separate from the channel state, we extract that method out into its own
interface.
In this commit, we take an initial step towards converting the existing
breach arbiter and utxo nursery logic into contract resolvers by moving
the files as is, into the `contractcourt` pacakge.
This commit is primarily move only, though we had to massage some
interfaces and config names along the way to make things compile and the
tests run properly.
Fixes#5796.
Some historical channels might not have the forwarding packages
recorded. And since the error might be silenced, the historical channel
might be nil.
With the middleware handler in place, we now need to add a new gRPC
interceptor to the interceptor chain that will send messages to the
registered middlewares for each event that could be of interest to them.
The RPC DeletePayment allows deleteing single payment from its ID. When calling with `FailedHtlcsOnly` set in the request only failed HTLCs of this payment will be deleted.
We'll want to re-use the abandon channel functionality for the batch
funding, as a cleanup in case the funding is aborted before publishing
any transaction.
This field will be examined later down the stack along with the set of
feature bits to determine if explicit channel commitment type
negotiation is possible or not.
Adds an optional tx parameter to ForAllOutgoingChannels and FetchChannel
so that data can be queried within the context of an existing database
transaction.
As a preparation to not have a local and remote version of the database
around anymore, we rename the variables into what their actual function
is. In case of the RPC server we even directly use the channel graph
instead of the DB instance. This should allow us to extract the channel
graph into its own, separate database (perhaps with better access
characteristics) in the future.
If the wallet recovery chain rescan was aborted before it finished, the
user would need to remember to use a positive recovery_window value the
next time they unlock the wallet for the rescan to continue. Because
forgetting to do so could lead to an incomplete wallet state (and
therefore potential missing funds) we rather don't allow shutting down
lnd through the RPC while a rescan is in progress.
This won't prevent any user from manually signaling Ctrl+C to kill lnd.
But that user might also check the log and see there's still something
going on that's preventing lnd from shutting down.
An often requested feature is to use the abandonchannel API in regular
builds and not only dev builds to get rid of stuck channels that had
their funding transaction invalidated.
The initial reason for putting the call behind the build flag was a
safety concern to make sure nobody uses this on active channels by
accident.
Fixes#5325.
Corrects a problem introduced in #5281 that caused the synced_to_chain
flag in the GetInfo call to never become true when the router subsystem
is running in Neutrino mode (channel validation turned off).
With this patch, we'll fail out earlier in the cycle in case of
some wonky parameters, and not leave zombie payments in the router
which currently are not cleaned up.
GetNodeInfo retrieves the policies for every edge the node belongs to.
When these policies are retrieved from the database, they're returned
in the following order: the first policy is the outgoing policy from the
node, and the second is the incoming policy to the node. This ordering
is not consistent with the ordering we have within our other RPCs like
GetChanInfo and DescribeGraph, where policies are sorted based on the
smaller public key of the nodes within an edge.
We fix this by maintaining the same order as our other RPCs.
The router has a lot of work to do for each block. So it might be
possible that it isn't yet up to date with the most recent block,
even if the wallet is. This can happen in environments with high CPU
load (such as parallel itests). Since the `synced_to_chain` flag in
the response of this call is used by many wallets (and also our
itests) to make sure everything's up to date, we add the router's
state to it. So the flag will only toggle to true once the router was
also able to catch up.
Since we want to support AMP payment using a different unique payment
identifier (AMP payments don't go to one specific hash), we change the
nomenclature to be Identifier instead of PaymentHash.
In this commit, we add strict zombie pruning as a config level param.
This allow us to add the option for those that want a tighter graph, and
not change the default composition of the channel graph for most users
over night.
In addition, we expand the test case slightly by testing that the self
node won't be pruned, but also that if there's a node with only a single
known stale edge, then both variants will prune that edge.
This commit adds a []*lnrpc.NodeAddress typed node_addresses field
on the NodeUpdate message of SubscribeChannelGraph to mirror the
addresses field in the LightningNode message of DescribeGraph.
Fixes https://github.com/lightningnetwork/lnd/issues/4084
This commit deprecates/replaces the old field `sat_per_byte` with
`sat_per_vbyte`. While the old field suggests sat per byte, it’s
actually using sat per virtual byte. We use the Hidden param to hide all
the deprecated flags. These flags won't show up in help menu onwards,
while stay valid that can be passed from cli. Thus bash scripts
referencing these fields won't be broken.
This commit achieves what we have been building up to: running the
WalletUnlockerService and the LightningService on the same gRPC server
simultaneously!
To achieve this, we first create the RPC server in a "interface only"
way, only creating the struct and setting the dependencies we have
available before the wallet has been unlocked. After the wallet has been
unlocked and we have created all the subsystems we need, we add those to
the RPC server, and start the sub-servers.
This means that the WalletUnlockerService and the LightningService both
will be registered and available at all times on the gRPC server.
However, before the wallet has been unlocked, the LightningService
should not be used since the RPC server is not yet ready to handle the
calls. Similarly, after the wallet has been unlocked, the
WalletUnlockerService should not be used. This we will ensure in
following commits.
We don't have to define the external subserver config more than once, so
it is not needed to be defined for every listener. Instead we move it to
the ListenerConfig.
This adds a new package rpcperms which houses the InterceptorChain
struct. This is a central place where we'll craft interceptors to use
for the GRPC server, which includes macaroon enforcement.
This let us add the interceptor chain to the GRPC server before the
macaroon service is ready, allowing us to avoid tearing down the GRPC
server after the wallet has been unlocked.
In order to be able to register the subservers with the root grpc server
before we have all dependencies available, we wrap them in an
GrpcHandler struct. This struct will initially hold an empty reference
to the subservers, which allows us to register with the GRPC server, and
later populate and create the subserver instance.
This allows to use FowardingHistory rpc method to receive the data exactly
as it's stored in lnd and to synchronize incrementally the history to an
external database.
This commit uses the new coop-close-target-confs value as the default to
use for a nodes self initiated channel closures if the conf-target flag
for the channel closure is not set. The defaults for both these options
is 6 so this shouldnt change current behaviour.
