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.
Adds `DeletePayment` to the channeldb, which allows to delete a single payment. If only failed HTLCs for this payment should be deleted it can be specified by the bool `failedHtlcsOnly`.
In this commit we add an extra config for enabling logging to an
external file when using embedded etcd. This can be useful when running
integration tests to see more details about etcd related issues.
This PR changes a link in the section Developer Resources from dev.lightning.community (unmaintained) to docs.lightning.engineering.
It also specifies more clearly what readers can expect to find there.
selectHopHints is the function which constructs hophints otherwise found
in an invoice created with the private flag.
In this commit, we expose that functionality a little more to workaround
needing to create an invoice to retrieve routing hints. Of course, this
is not a perfect solution as the functionality is exposed exclusively to
go users.
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.
We'll want to re-use the PSBT funding functionality from the wallet kit
sub server in the main RPC server. To be able to dynamically obtain an
instance of the wallet kit server we need to know its name under which
it registers itself in the list of sub server. We export the name so we
don't have to hard code it in the main server.
This commit fixes a buggy scenario where:
- a spend of the desired outpoint occurs
- RegisterSpend is called, not immediately notifying
- caller performs a historical dispatch, calling UpdateSpendDetails
- caller is notified on the Spend channel
- re-org occurs
- caller is not notified of the re-org
We fix this by correctly populating the spendsByHeight map when
dispatchSpendDetails is called. This mirrors the confirmation case.
In this commit, we modify the existing logic that defaults to implicit
commitment type negotiation to support explicit negotiation if the new
feature bit is set. This change allows us to ditch the notion of a
"default" commitment type, as we'll now use feature bits to signal our
understanding of a commiment type, but allow peers to select which
commitment type they actually wish to use.
In addition, this explicit negotiation removes the need for using the
required bit of any commitment types. Instead, if an implementation
wishes to no longer support a commitment type, they should simply stop
advertising the optional bit.
This commit adds the ability for a channel initiator/responder to
determine whether the channel to be opened can use a specific commitment
type through explicit negotiation. It also includes the existing
implicit negotiation logic to fall back on if explicit negotiation is
not supported.
yyforyongyu