multi: Forward Blinded Payments #7376

carlaKC · 2023-02-01T17:06:52Z

Change Description

This PR adds forwarding of payments in blinded paths to LND, and depends on #7267, #7297.

Opening early for general approach feedback 🙏 and to provide an idea of the scope of the change (many rpc changes are inflating the change delta - it looks worse than it is, promise 😅 ).

There are a few notably missing elements:

Forwarding works without [feature]: Availability of UpdateAddHTLC ExtraData Across Restarts #7297 with a very small workaround, but we'll probably want to store that data properly
As noted in routing: Support Pathfinding to Blinded Routes #7267, we'll need to migrate one of our on-chain resolvers and thread the blinding_point through to it (tbd separately)
Error handling for blinded payments is not included (this will be done in a followup PR to split things up a little)
There can always be more unit tests

Steps to Test

Since LND doesn't produce blinded routes, you'll need the following setup:
Alice (LND) --- Bob(LND) --- Carol (LND) --privatechan-- Dave(CL)

Since we need to retrieve a raw CL invoice, you need another CL node connected to Dave to fetch the invoice from an offer:

dave offer 1000 test -> lno... is your offer
cl fetchinvoice lno... -> lni.... is your invoice
cl decode lni... -> This will give blinded hops/data etc.

You can then pay the blinded invoice from LND:

lncli queryroutes --introduction_point={cleartext_introduction_node_id} --blinding_point={blinding_point} --blinded_hops={blinded_introduction_node}:{introduction_node_data} --blinded_cltv={blinded_route_total_cltv} --amt={invoice_amount} | lncli sendtoroute --payment_hash={payment_hash} -

It's also covered in an itest, which may make life a little easier :')

carlaKC · 2023-02-24T16:27:45Z

Alice (CL) --> Bob(LND) --> Carol (LND) --> Dave(CL) forwarding interop achieved (though acquired with a pretty ungodly setup)!

Run CL with --experimental-offers --dev-fast-gossip + DEVELOPER=1 in configure
Run LND at 918ac69
Open public channels Alice - Bob, Bob-Carol
Open private chanel Carol-Dave (required to force a blinded path for the offer)
Alice / Bob / Carol / Dave lncli updatechanpolicy 1000 1 18 (run into blinded path timelock limit issues with CL otherwise)
P2P Connect Alice to Dave (required to use onion messaging to fetch an bolt 12 invoice)
Dave lightning-cli offer 1000 test -> lno...
Alice: lightning-cli fetchinvoice lno... -> lni...
Alice: lightning-cli pay lni... -> Success!

Going to further split up this PR to ease reivew:

Preparatory PR adding structs, serialization
Forwarding PR with blinded payment logic

Also going to decouple this from #7267 (that will make the itests a little longer because we need to do things manually, but I think it's going to result in a more reviewable PR chain).

calvinrzachman

Cool to make a first review pass for route blinding! You certainly did a much better job than I did at preserving the existing efforts to maintain separation between different components 😄 I like the finesse in hiding the handling of blind hops behind hop.DecodeHopIterators() and the hop.Iterator interface. These were already responsible for batch decrypting onions and providing a “hop iterator” from which we obtain all information needed to forward, so it really does make sense to also put the handling of the nested route blinding payload there as well. This keeps the channel link free from having to worry about whether the hops it processes are normal or blind.

I kept it focused to just the commits which are unique to this PR. I’ll try and dig a bit deeper as I have time to get back into the route blinding stuff very soon. Just a couple things to note so far! Let me know what you think.

calvinrzachman · 2023-03-30T23:10:47Z

lnwallet/channel.go

 		if payDesc.EntryType == Add {
+			if err = lc.remoteUpdateLog.restoreExtraAddData(


So as you say in the commit description, with this change we handle the restoration of partially committed HTLCs from on-disk commitment. This covers us for the case where we restart part way through a commitment dance after adding the HTLC to the local commitment, but prior to sending a signature which covers the HTLC on the remote party's commitment.

I think we also need to handle the restoration of fully committed HTLC’s from forwarding packages so that the blinding point is available for ADDs which are re-transmitted in the incoming link by this code path. This requires both that the LogUpdate we create for the FwdPkg in ReceiveRevocation contains the blinding point and that we pull that blinding point out and put it back in the PaymentDescriptor. An example of that can be found here. Let me know what you think!

lnwire/blinding_point.go

calvinrzachman · 2023-03-30T23:36:44Z

lnwallet/channel.go

@@ -417,6 +423,7 @@ func PayDescsFromRemoteLogUpdates(chanID lnwire.ShortChannelID, height uint64,
 					Height: height,
 					Index:  uint16(i),
 				},
+				BlindingPoint: wireMsg.BlindingPoint.PublicKey,


At least as it pertains to restoring the blinding point from forwarding packages, I think we may need to pair this with placing the blinding point inside the LogUpdate stored in the FwdPkg created by ReceiveRevocation(). Check out my other comment and let me know what you think.

calvinrzachman · 2023-03-31T00:03:00Z

htlcswitch/hop/payload_test.go

@@ -348,7 +348,9 @@ func testDecodeHopPayloadValidation(t *testing.T, test decodePayloadTest) {
 		testChildIndex = uint32(9)
 	)

-	p, err := hop.NewPayloadFromReader(bytes.NewReader(test.payload))
+	p, err := hop.NewPayloadFromReader(
+		bytes.NewReader(test.payload), &hop.BlindingKit{},


Even after removing the amount/timelock TLV here so we pass the route blinding validation step, I get a nil pointer dereference. I think the trouble is that this blinding kit is not fully initialized and is missing deriveForwardingInfo().

We could provide a mock blind hop processor implementation and use hop.MakeBlindingKit(), but I think the more general solution is - now that we do some validation across both onion TLV payload, route blinding TLV payload and TLV extension for UpdateAddHTLC that we cover the payload validation for blind hops in a bit more full fledged test case which provides control over those elements.

carlaKC · 2023-05-25T21:16:20Z

Needs rebase on #7710 - hold off on review for now!

yyforyongyu · 2023-09-28T10:58:51Z

can be rebased!

We'll need to pack feature vectors for route blinding, so we pull the encoding/decoding out into separate functions (currently contained in ChannelType). Though it's more lines of code, we keep most of the ChannelType assertions so that we strictly enforce use of the alias.

This commit adds encoding and decoding for blinded route data blobs. TLV fields such as path_id (which are only used for the final hop) are omitted to minimize the change size.

Add blinding points to update_add_htlc. This TLV will be set for nodes that are relaying payments in blinded routes that are _not_ the introduction node.

If there is a blinding point present in update_add_htlc's TLVs, add it to our payment descriptor struct so that it can be passed through to onion decryption. This code path will be used for nodes that are relaying payments inside of the blinded route (ie, all nodes except the introduction node). When we restore HTLCs from disk, we do not have the data provided in UpdateAddHTLC's TLVs available. This is okay, because once we store the HTLC as part of our commit state, either have the full wire message stored (for acked but not signed htlcs) or a forwarding package with all forwarding information has been produced (for fully locked in htlcs).

When we have payments inside of a blinded route, we need to know the incoming amount to be able to back-calculate the amount that we need to forward using the forwarding parameters provided in the blinded route encrypted data. This commit adds the payment amount to our DecodeHopIteratorRequest so that it can be threaded down to payment forwarding information creation in later commits.

Co-authored-by: Calvin Zachman <[email protected]>

This commit introduces a blinding kits which abstracts over the operations required to decrypt, deserialize and reconstruct forwarding data from an encrypted blob of data included for nodes in blinded routes. The concept of a BlindingKey is separated into a separate struct so that it can be used independently of the kit (which is specifically used to process encrypted blobs). This abstraction will be used later to help determine how we handle errors.

When we have a HTLC that is part of a blinded route, we need to include the next ephemeral blinding point in UpdateAddHtlc for the next hop. The way that we handle the addition of this key is the same for introduction nodes and relaying nodes within the route.

If we received a payload with a blinding point set, our forwarding information should be set from the information in our encrypted blob. This behavior is the same for introduction and relying nodes in a blinded route.

Note: the itest is broken up into multiple commits to make it more readable, they can be squashed post-review.

We don't support receiving blinded in this PR - just intercept and settle instead.

carlaKC · 2023-10-06T15:35:56Z

⚠️ Don't review, going to split out a prep PR with refactoring / basic plumbing.

lightninglabs-deploy · 2023-11-03T18:19:35Z

@yyforyongyu: review reminder
@carlaKC, remember to re-request review from reviewers when ready

carlaKC · 2023-11-08T19:45:18Z

Broke this up into 2 PRs (with a small, third PR for error handling to come).
Replaced by #8159, #8160

carlaKC force-pushed the 7298-forwardblindedroutes branch from 4fb5e84 to 918ac69 Compare February 6, 2023 17:20

calvinrzachman reviewed Mar 31, 2023

View reviewed changes

carlaKC mentioned this pull request Apr 19, 2023

[feature]: Availability of UpdateAddHTLC ExtraData Across Restarts #7297

Closed

carlaKC force-pushed the 7298-forwardblindedroutes branch from 918ac69 to 5bd95c3 Compare May 25, 2023 21:14

carlaKC force-pushed the 7298-forwardblindedroutes branch from 5bd95c3 to 28a7ccf Compare May 25, 2023 21:18

carlaKC force-pushed the 7298-forwardblindedroutes branch from 28a7ccf to 3838130 Compare June 22, 2023 20:06

carlaKC force-pushed the 7298-forwardblindedroutes branch 3 times, most recently from 1466a26 to 18806c1 Compare August 9, 2023 19:20

saubyk added this to the v0.18.0 milestone Aug 10, 2023

saubyk assigned carlaKC Aug 10, 2023

saubyk added P1 MUST be fixed or reviewed blinded paths labels Aug 10, 2023

carlaKC force-pushed the 7298-forwardblindedroutes branch from 18806c1 to 2301dd7 Compare August 24, 2023 08:06

yyforyongyu self-requested a review August 31, 2023 09:50

carlaKC force-pushed the 7298-forwardblindedroutes branch 2 times, most recently from 5736c79 to 69ff187 Compare September 13, 2023 13:50

yyforyongyu changed the base branch from master to 0-18-staging September 28, 2023 10:58

carlaKC and others added 9 commits October 6, 2023 11:21

htlcswitch: remove unused decode hop iterator

74652d6

lnwire: add TLV encoding/decoding for blinded route data blobs

827ed18

This commit adds encoding and decoding for blinded route data blobs. TLV fields such as path_id (which are only used for the final hop) are omitted to minimize the change size.

lnwire: add blinding point to update_add_htlc TLVs

671cf55

Add blinding points to update_add_htlc. This TLV will be set for nodes that are relaying payments in blinded routes that are _not_ the introduction node.

hop: add function for calculating forwarding amount

ef5d4d7

Co-authored-by: Calvin Zachman <[email protected]>

multi: add validation of blinded route encrypted data

6af0108

Co-authored-by: Calvin Zachman <[email protected]>

carlaKC added 10 commits October 6, 2023 11:21

htlcswitch: pass blinding kit to payload creation

c809006

htlcswitch: add validation for blinded route payloads

0a443a2

htlcswitch: set forwarding information from encrypted data

18aef84

If we received a payload with a blinding point set, our forwarding information should be set from the information in our encrypted blob. This behavior is the same for introduction and relying nodes in a blinded route.

multi: advertise route blinding feature bit

aa3cbac

lntest: add setup for blinded route forwarding itest

fc3573e

Note: the itest is broken up into multiple commits to make it more readable, they can be squashed post-review.

lntest: add helper to create blinded route

bbb5143

lntest: add route construction to blinded forwarding test

695966d

lntest: dispatch payment to blinded route

0b1adfd

lntest: add interceptor to blinded forwarding test for workaround

4510819

We don't support receiving blinded in this PR - just intercept and settle instead.

carlaKC force-pushed the 7298-forwardblindedroutes branch from 69ff187 to 4510819 Compare October 6, 2023 15:23

carlaKC mentioned this pull request Oct 11, 2023

BOLT12 #5594

Open

carlaKC mentioned this pull request Nov 8, 2023

[2/3]: Support Forwarding of Blinded Payments #8160

Merged

carlaKC closed this Nov 8, 2023

saubyk removed this from the v0.18.0 milestone Nov 9, 2023

carlaKC mentioned this pull request Feb 8, 2024

Cli: add pay offer command lndk-org/lndk#91

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

multi: Forward Blinded Payments #7376

multi: Forward Blinded Payments #7376

carlaKC commented Feb 1, 2023 •

edited

Loading

carlaKC commented Feb 24, 2023

calvinrzachman left a comment

calvinrzachman Mar 30, 2023

calvinrzachman Mar 30, 2023 •

edited

Loading

calvinrzachman Mar 31, 2023

carlaKC commented May 25, 2023

yyforyongyu commented Sep 28, 2023

carlaKC commented Oct 6, 2023

lightninglabs-deploy commented Nov 3, 2023

carlaKC commented Nov 8, 2023

		if payDesc.EntryType == Add {
		if err = lc.remoteUpdateLog.restoreExtraAddData(

multi: Forward Blinded Payments #7376

multi: Forward Blinded Payments #7376

Conversation

carlaKC commented Feb 1, 2023 • edited Loading

Change Description

Steps to Test

carlaKC commented Feb 24, 2023

calvinrzachman left a comment

Choose a reason for hiding this comment

calvinrzachman Mar 30, 2023

Choose a reason for hiding this comment

calvinrzachman Mar 30, 2023 • edited Loading

Choose a reason for hiding this comment

calvinrzachman Mar 31, 2023

Choose a reason for hiding this comment

carlaKC commented May 25, 2023

yyforyongyu commented Sep 28, 2023

carlaKC commented Oct 6, 2023

lightninglabs-deploy commented Nov 3, 2023

carlaKC commented Nov 8, 2023

carlaKC commented Feb 1, 2023 •

edited

Loading

calvinrzachman Mar 30, 2023 •

edited

Loading