multi: Forward Blinded Payments (funding)

Apr 27, 2023

https://github.com/lightningnetwork/lnd/pull/7376

Host: calvinrzachman  -  PR author: carlaKC

Notes

• Lightning Network Spec - Route Blinding Proposal PR: https://github.com/lightning/bolts/pull/765
  • Concept Doc: https://github.com/lightning/bolts/blob/master/proposals/route-blinding.md
• This PR review club will focus on Carla’s PR to equip LND with the ability to forward HTLCs which are part of a blinded route: https://github.com/lightningnetwork/lnd/pull/7376
  • The first 15 commits (everything up until commit 67bfc14 - lncli: add blinded route cli flags to query routes) belong to an alternate PR for pathfinding to blinded routes: https://github.com/lightningnetwork/lnd/pull/7267
  • Feel free to have a look around, but we’ll have more than enough narrowing our primary focus to the set of commits below.
• If you’d like to chart a course through the codebase, start your search in the htlcswitch and hop package:
  • hop/iterator.go
    • The hop.Iterator interface and its HopPayload() method
    • The sphinxHopIterator type which concretely implements the hop.Iterator interface
    • The OnionProcessor type and its DecodeHopIterators(…) method.
      • Wraps a sphinx.Router which provides the decrypt and next blinding point functionality.
    • type BlindingKit and the deriveForwardingInfo(…) function.
  • hop/payload.go
    • The NewPayloadFromReader(…) function.
  • htlcswitch/link.go
    • link.processRemoteAdds(…)
• Have some familiarity with the contents and structure of a blinded route:
  • https://github.com/lightning/bolts/blob/master/04-onion-routing.md?plain=1#L202-L207
  • https://github.com/lightning/bolts/blob/master/04-onion-routing.md?plain=1#L452-L483
  • For complete route blinding payload TLV definitions see record/blinded_data.go.
• You can run the integration test using the following command: make itest icase=forward_blinded temptest=true. This leaves node logs in lntest/itest/.logs-tranche0.
• Blind HTLC Forwarding Summary: https://github.com/lightningnetwork/lnd/issues/7298#issue-1523135402

NOTE: There are some in-progress workarounds in this PR as it relates to the persistence of information (ex: blinding point) needed to process blind HTLCs following a node/channel restart. The approach here is not finalized and indeed is likely to be updated. One candidate path forward will be to perform a database migration to “TLV-ify” the channeldb.HTLC type so it can be expanded to contain additional fields as new protocol features (not just route blinding!) are added. For more detail and discussion, please see this issue: https://github.com/lightningnetwork/lnd/issues/7297. We will proceed with the PR as is for now as we can still get some exposure to the route blinding concepts and htlcswitch package. Plus, we can always do more route blinding stuff in the future!

Questions

• What aspect of the Lighting Network protocol does the route blinding protocol seek to improve?
• At a high level, how does the proposal attempt to improve recipient anonymity on the Lightning Network?
• Did you review the PR? If yes, what’s your overall verdict? (ACK, NACK, concept ACK, unknown) Recall that a sender encrypts the hop payload for a given forwarding node using a key derived from a shared secret established via ECDH between themselves and the forwarding node. In route blinding, the sender performs this ECDH using a blinded/tweaked version of the forwarding node’s ID public key.
• Does a forwarding node in a blinded route know a priori (ie: without information specific to the route) “its” blinded node ID public key? If not, how does the forwarding node obtain the information needed to compute the blinded version of its node ID public key?
• What all is the route blinding point used for?
• What is a hop.Iterator and what information does it provide to the ChannelLink?
  • HINT: What is the primary responsibility of the iterator’s HopPayload() method?
• How does the sphinxHopIterator access the sensitive (node ID) key information it needs during decryption of the route blinding payload?
• What is the purpose of the payment_constraints field in the route blinding payload? Why go above and beyond the validation we already apply to forwarded HTLCs?
• What are some of the characteristics of a blinded route which influence the size of the anonymity set it offers? How might the anonymity set change over time? Does this change as multiple blinded routes are created?
• Though it’s not handled by this PR currently, what is the spec recommended way to increase anonymity set sizes?
• Does route blinding require BOLT-12 invoices?