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.
When iterating edges, pathfinding checks early whether using an edge
would violate the requested total fee limit for a route. This check is
done on the net amount (an amount the inbound fee is calculated with).
However, a possible next hop's fee discount leads to a reduction in fees
and as such using the net amount leads to assuming a higher cumulative
fee than the route really has, excluding the path erroneously. We
perform the fee limit check on the amount to send, which includes both
inbound and outbound fees. This should be possible as the first hop's
outbound fee is zero and therefore doesn't have to be checked in the
end.
Add an itest that tests the addition of dummy hops to a blinded path. By
testing that invoices containing such a path can be paid, it also tests
the peeling of dummy hops by the receiver.
Make various sender side adjustments so that a sender is able to send an
MP payment to a single blinded path without actually including an MPP
record in the payment.
Update one of the route blinding itests to do a full end-to-end test
where the recipient generates and invoice with a blinded path and the
sender just provides that invoice to SendPayment.
The tests also covers the edge case where the recipient is the
introduction node.
The route blinding itests are now updated so that recipient logic is
tested. The creation of a blinded route is also now done through the
AddInvoice API instead of manually.
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
fdd28c8d88/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.
For the final hop in a blinded route, the SCID and RelayInfo fields will
_not_ be set. So these fields need to be converted to optional records.
The existing BlindedRouteData constructor is also renamed to
`NewNonFinalBlindedRouteData` in preparation for a
`NewFinalBlindedRouteData` constructor which will be used to construct
the blinded data for the final hop which will contain a much smaller set
of data. The SCID and RelayInfo parameters of the constructor are left
as non-pointers in order to force the caller to set them in the case
that the constructor is called for non-final nodes. The other option
would be to create a single constructor where all parameters are
optional but I think this makes it easier for the caller to make a
mistake.
index
When abandoning a channel, we remove it from the graph and then add it
to the zombie channel index. However, if we then process a ChannelUpdate
for this channel it will result in us calling `processZombieUpdate`
which will delete the edge from the zombie index. The abandon channel
itest currently asserts that a channel is no longer in the graph by
asserting that when querying for the channel we get a "marked as zombie"
error but to account for the above series of operations, we now also
allow it to just not be found at all ("edge not found").
We may get a flake like the following,
```
lnd_route_blinding_test.go:468:
Error Trace: /Users/runner/work/lnd/lnd/itest/lnd_route_blinding_test.go:468
/Users/runner/hostedtoolcache/go/1.22.3/arm64/src/runtime/asm_arm64.s:1222
Error: Received unexpected error:
rpc error: code = Canceled desc = context canceled
Test: TestLightningNetworkDaemon/tranche15/144-of-156/bitcoind/disable_introduction_node
```
This happens when the test successfully finishes, the parent context is
canceled, causing the child context to return an error. We fix it by
ignoring it in the goroutine.
