In this commit, we refactor all the other constructors for the input to
use MakeBaseInput. We also add a new set of functional options as well.
This'll be useful later on to ensure that new options are properly
applied to all the input types.
This will be used by external callers to modify the way we resolve
contracts on chain. For a given contract, we'll store an extra "blob",
that will later be presented during the sweeping phase.
This commit updates the traffic shaper's bandwidth query method to
accept the link bandwidth as a parameter. This allows an external
traffic shaper to optionally return the link bandwidth as the payment
bandwidth.
We added the custom data to the pending channels but forgot to also
send the response RPC message to the custom channel parser so it can
turn it into human-readable JSON.
We always need to set the close output in order for us to be able
to calculate the closing keys. Especially if there is only a dust
balance in BTC terms but perhaps a valuable amount in custom channel
funds.
With this commit we populate additional information about the close
outputs (including potential custom channel data) in the close update
RPC message.
This will allow custom channels to find out how the additional close
outputs look like on chain and what data they might commit to.
We also hook up the aux custom data formatter, so it can format the
custom channel data to JSON.
In this commit, we move to add the internal key to the delivery addr. This way, we give the aux chan closer the extra information it may need to properly augment the normal co-op close process.
In this commit, we fix an issue with co-op closes for taproot channels. Before this commit, we'd think that the remote party broadcasted a state very far in the future, and try to execute DLP. The wallet would properly credit the settled funds, but we'd mark the close in the DB as a force close.
To fix this, we also watch for the RBF sequence number we use in this scenario.
This commit introduces a basic integration test for the invoice
HTLC modifier. The test covers scenarios where an invoice is settled with a
payment that is less than the invoice amount, facilitated by the invoice
HTLC modifier.
This commit enhances the itest LND node harness to include support for
the new `HtlcModifier` RPC endpoint.
At the same time we move another method to the correct file.
This commit introduces a singleton invoice HTLC modifier RPC server and
an endpoint to activate it. The server interfaces with the internal
invoice HTLC modifier interpreter, handling the marshalling between RPC
types and internal formats.
This commit updates the invoice registry to utilize the settlement
interceptor during the invoice settlement routine. It allows the
interceptor to capture the invoice, providing interception clients an
opportunity to determine the settlement outcome.
This commit introduces a new invoice htlc interceptor service
that intercepts invoice HTLCs during their settlement phase. It forwards
HTLCs to a subscribed client to determine their settlement outcomes.
This commit also introduces an interface to facilitate integrating the
interceptor with other packages.
To avoid sorting issues with identical HTLCs (equal size, equal payment
hash, equal CLTV), we need to also use the HTLC index to be able to
distinguish between them.
It doesn't make sense to do multiple encode/decode round trips on the
custom data of an HTLC. So we just use the same custom record type
everywhere, which also simplifies some of the code again.
This commit adds an optional data parser that can inspect and in-place
format custom data of certain RPC messages.
We don't add an implementation of the interface itself, as that will be
provided by external components when packaging up lnd as a bundle with
other software.
