In this commit, we add a new field to the WalletBalance call that
permits users to account for the set of outputs that may be locked due
to a pending transaction. Without this field any time users locked
outputs for things like PSBT signing, then they disappear from the
WalletBalance call, which may cause a panic.
In this commit, we increase the legacy fee limit threshold (the amount
below which we'll allow 100% of funds to go to fees for the non-v2 RPC
calls) from 50 sats to 1k sats.
When updating the channel routing policy, we encounter an inaccurate
precision error when calculating the routing fee. The issue stems from
the way the IEEE 754 standard works.
The solution here is to add a uint64 parameter (as mentioned in the
issue) and keep the float64 fee_rate parameter but rounding the product
of the base and fee rate.
This commit adds a new unique intercept message ID that is different for
each message sent to an RPC middleware. This will allow us to re-purpose
the existing request ID field into its original intention, which was to
have a unique ID for a full gRPC request/response pair or gRPC stream as
a whole.
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.
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.
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.
To avoid a naming conflict with etcd, we rename our very generic
rpc.proto to lightning.proto to match the service name that's declared
within. This will break many external tutorials and possibly also our
API docs but the change needs to be done eventually.
