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.
With this commit we encode the custom records as a TLV stream into the
custom channel data field of the invoice HTLC.
This allows the custom data parser to parse those records and replace it
with human-readable JSON on the RPC interface.
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 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.
This commit extends the forward HTLC intercept response with fields that
can be used in conjunction with a `ResumeModified` action to modify the
intercepted HTLC p2p message.
Add a new bumpforceclosefee rpc endpoint to the wallet server.
Move the logic from the lncli level to the wallet server rpc level.
This is more in line with a proper client-server design.
wallet lncli: use new bumpforceclosefee endpoint.
Besides using the new bumpforceclosefee rpc endpoint we also enable the
bumping of taproot anchor channels.
This commit removes the call toe `ListLeasedOutputs` in `LeaseOutput` -
the returned info from `ListLeasedOutputs` can easily be accessed via
`FetchInputInfo` and this info is only used at one callsite.
`ListLeasedOutputs` then becomes unnecessary here, plus it's very slow
and needs to be refactored in `btcwallet` instead.
This commit replaces the usage of `FetchInputInfo` with
`FetchOutpointInfo` and `FetchDerivationInfo` to remove unncessary
fetching of the derivation path.
The BlindedPathConfig struct is nice for invoice creation but when we
use the Invoice message for viewing an invoice, it would be nicer to see
an "is_blinded" field.
since `AddInvoiceData` is config _per invoice_ where as `AddInvoiceConfig`
is config for the invoice server itself and so pretty much should stay
the same for the lifetime of LND. This change sets us up for moving some
of the blinded path config options to be changeable per AddInvoice call
rather that having fixed config values in the config file.
Because the Go version used to run the `go list` commands is below the
minimum version specified in the main go.mod file, every time the `make
rpc` command is executed, the Golang runtime is downloaded twice, which
looks like this and takes a couple of seconds at least:
go: downloading go1.21.4 (linux/amd64)
go: downloading go1.21.4 (linux/amd64)
We fix this by using the correct minimum version.
This commit introduces a new type, `BlindedPaymentPathSet`. For now, it
holds only a single `BlindedPayment` but eventually it will hold and
manage a set of blinded payments provided for a specific payment. To
make the PR easier to follow though, we start off just letting it hold a
single one and do some basic replacements.
This commit introduces more sophisticated code for selecting dummy hop
policy values for dummy hops in blinded paths.
For the case where the path does contain real hops, the dummy hop policy
values are derived by taking the average of those hop polices. For the
case where there are no real hops (in other words, we are the
introduction node), we use the default policy values used for normal
ChannelUpdates but then for the MaxHTLC value, we take the average of
all our open channel capacities.
Expose the ability to add blinded paths to an invoice. Also expose
various configuration values.
We also let the lncfg.Invoices struct satisfy the Validator interface so
that we can verify all its config values in one place.
Here we add a new `Blind` option to the `AddInvoiceData` which will
signal that the new invoice should encode a blinded route.
Certain other changes are also made in the case that this invoice
contains a blinded route:
1) the payment address/secret no longer needs to be in the invoice
itself since it will be put in the `PathID` recored of the encrypted
recipient record for our hop.
2) When we sign the invoice, we now use an ephemeral key since we dont
want the sender to be able to derive our real node pub key from the
invoice signature.
3) The invoice's FinalCLTV field should be zero for blinded invoices
since the CLTV delta info will be communicated in the accumulated
route policy values.
