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.
This commit adds two functional options to the zpay32.Decode function.
`WithKnownFeatureBits` allows the caller to overwrite the default set of
known feature bits used by the function.
`WithErrorOnUnknownFeatureBit` allows the caller to instruct the
function to error out if the invoice that is decoded contaijns unknown
feature bits. We then use this new error-out option from the
`rpcServer`'s `extractPaymentIntent` method.
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.
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.
This commit is a large refactor that moves over various responsibilities
from the ChannelRouter to the graph.Builder. These include all graph
related tasks such as:
- graph pruning
- validation of new network updates & persisting new updates
- notifying topology update clients of any changes.
This is a large commit but:
- many of the files are purely moved from `routing` to `graph`
- the business logic put in the graph Builder is copied exactly as is
from the ChannelRouter with one exception:
- The ChannelRouter just needs to be able to call the Builder's
`ApplyChannelUpdate` method. So this is now exported and provided to
the ChannelRouter as a config option.
- The trickiest part was just moving over the test code since quite a
bit had to be duplicated.
In preparation for adding a clean Graph DB interface, we create a
version of FetchLightningNode that doesnt allow a caller to provide in a
transaction.
In this commit, we completely remove the Router's dependence on a Graph
source that requires a `kvdb.RTx`. In so doing, we are more prepared for
a future where the Graph source is backed by different DB structure such
as pure SQL.
The two areas affected here are: the ChannelRouter's graph access that
it uses for pathfinding. And the SessionSource's graph access that it
uses for payments.
The ChannelRouter gets given a Graph and the SessionSource is given a
GraphSessionFactory which it can use to create a new session. Behind the
scenes, this will acquire a kvdb.RTx that will be used for calls to the
Graph's `ForEachNodeChannel` method.
This commit adds a blinded_paths field to the PayReq proto message. A
new helper called `CreateRPCBlindedPayments` is then added to convert
the zpay32 type to the existing `lnrpc.BlindedPaymentPath` type and add
this to the `PayReq` in the `DecodePayReq` rpc method.
Fixes the problem that inbound base fee and fee rate are overwritten
with 0 if they are not specified in PolicyUpdateRequest. This ensures
backward compatibility with older rpc clients that do not yet support
the inbound feature.
This commit moves `DetermineFeePerKw` into the `Estimate` method on
`FeePreference`. A few callsites previously calling `DetermineFeePerKw`
without the max fee rate is now also temporarily fixed by forcing them
to use `Estimate` with the default sweeper max fee rate.
