delvingbitcoin

bLIP: BOLT 11 Invoice Blinded Path Tagged Field

bLIP: BOLT 11 Invoice Blinded Path Tagged Field

Original Postby ellemouton

Posted on: June 26, 2024 00:10 UTC

This discussion revolves around a proposed bLIP (Bitcoin Lightning Improvement Proposal) focused on enhancing privacy and reliability in lightning payment delivery through the introduction of a new tagged field for BOLT 11 payment invoices.

This field aims to communicate encoded blinded path information to payers, leveraging the benefits of route blinding as outlined in the BOLT 4 specification and further explored within the BOLT 12 Offers proposal. The primary motivation behind this proposal is to enable the use of blinded paths without waiting for the widespread adoption of the more comprehensive changes suggested by the Offers proposal, which includes onion messaging among other updates requiring a significant network upgrade.

The proposal outlines the technical specifications for implementing the new feature, including the addition of a bolt11_blinded_path feature bit within the experimental range to indicate support and understanding of the new tagged field. The structure of the field itself draws heavily from the encoding techniques described in the Offers proposal, detailing the inclusion of various data points such as fee rates, CLTV expiry deltas, and a series of encrypted data elements that facilitate the creation of private payment routes.

A key aspect of the proposed implementation is the careful consideration of compatibility and transition strategies. For instance, the document suggests measures to ensure backward compatibility with existing BOLT 11 invoice readers, which are designed to skip unknown fields, thereby allowing the continued processing of invoices that include the new tagged field. Additionally, the proposal anticipates a temporary role for this improvement, serving as an interim solution until the broader adoption of the Offers protocol and its associated invoice format negates the need for such a carve-out within BOLT 11.

Furthermore, the document discusses several technical and operational considerations necessary for the practical application of blinded paths in payment processing. These include restrictions on the number of hops in a path due to size limitations, both in terms of the data_length encoding and the maximum capacity of QR codes, should the invoice be transmitted in this form. An example invoice string provided in the appendix illustrates the application of these guidelines, demonstrating how the new field can accommodate multiple blinded paths within the constraints identified.

The proposal concludes with an open call for feedback on several unresolved questions aimed at refining the approach to communicating critical path information, optimizing space within the invoice structure, and enhancing the security and integrity of the invoice signing process. Among these topics are discussions on the best methods for conveying maximum CLTV expiry values, the potential for simplifying the representation of introduction nodes within blinded paths, and the implications of introducing an experimental tagged field range specifically for BOLT 11 in anticipation of its eventual obsolescence.