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 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.
We need a new feature bit for BOLT11 invoices in order to indicate that
they contain the new blinded path tagged field. Tagged fields pre-date
TLV and so nodes who dont understand them will simply skip them.
Therefore the feature bit helps them to fail fast.
Previously we may get a floor feerate when calling `EstimateFeePerKW`
due to the fee estimator not finishing its startup process, which gives
us an empty fee map.
This is now fixed to return an error if the estimator is not started.
This commit adds a new expected field, `min_relay_feerate`, in the
response body returned from the API source, allowing the API to specify
a min relay feerate to be used instead of the FeePerKwFloor.
This change is backwards compatible as for an old API source which
doesn't specify the `min_relay_feerate`, it will be interpreted as zero.
This test was previously working because we'd mine an extra block to
confirm the coins inside `FundCoinsUnconfirmed` when it's a neutrino
backend, as shown in
https://github.com/lightningnetwork/lnd/blob/fdd28c8d888792ea8fde3c557ba9f2594e0a6ec8/lntest/harness.go#L1431
Since neutrino has trouble seeing unconfirmed balance, we now send some
coins to the wallet, confirm those, then do a self-transfer so the node
will have unconfirmed outputs to perform the test.
This commit makes sure the sweep requests are received before mining
blocks to trigger the actual sweeping.
In addition, `testFundingExpiryBlocksOnPending` is updated to deal with
the old `channel link not found` issue.
Elle Mouton