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.
With this change we allow adding hop hints when adding an invoice, even
if its amount is zero.
A couple of new unit test case have been added, and the
`testInvoiceRoutingHints` itest was expanded to account for this
scenario.
In order to reduce the number of calls to the db we try to process as
few channels as we can + try to not do extra work for each of them.
- First fetch all the channels. Then, filter all the public ones and
sort the potential candidates by remote balance.
- Filter out each potential candidate as soon as possible.
- Only check the alias if the channel supports scid aliases.
- Because we sort the channels by remote balance, we will hit the
target amount, if possible, as soon as we can.
We do not want to leak information about our remote balances, so we
shuffle the hop hints (the forced ones go always first) so the invoice
receiver does not know which channels have more balance than others.
AddInvoice,AddHoldInvoice now issue invoices that include our
peer's aliases. Some extra sanity checks are included to ensure we
don't leak our confirmed SCID for a private channel.
This commit was previously split into the following parts to ease
review:
- 2d746f68: replace imports
- 4008f0fd: use ecdsa.Signature
- 849e33d1: remove btcec.S256()
- b8f6ebbd: use v2 library correctly
- fa80bca9: bump go modules
Previously, we'd always add up to the maximum number of hop hints
(and beyond!) when selecting hop hints in our first pass. This
change updates hop hint selection to always stick to our hop hint
limit, and to the "hop hint factor" that we scale our invoices by.
This change will result in selecting fewer channels in our first
pass if their total inbound capacity reaches our hop hint factor.
This prevents us from revealing as many private channels as
before, but has the downside of providing fewer options for
payers.
