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.
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.
This commit adds all the logic for building a blinded path (from a given
route) and packaging it up in a zpay32.BlindedPaymentPath struct so that
it is ready for adding to an invoice. It also includes logic for padding
a path with dummy hops.
Note that in this commit, the logic for choosing an actual path to us
that can then be used in a blinded path is abstracted away. This logic
will be fleshed out in a future commit.
This commit adds a helper function that will be used to adjust a hops
policy values by certain given increase and decrease multipliers. This
will be used in blinded paths to give policy values some buffer to avoid
easy probing of blinded paths.
This commit adds a function that can be used to compute the accumulated
path policy for a blinded path as defined in the spec:
db278ab9b2/04-onion-routing.md (L255)
This commit adds a helper function called `padHopInfo` along with a test
for it. This function will be used later on when building a blinded
path. It is used to ensure that all encrypted blobs of a blinded path
that we construct are padded to the same size.
