At Strike, we're constantly innovating to push the boundaries of Bitcoin and the Lightning Network (LN) and enhance our customers’ experience. Today, we're excited to announce our support for BOLT 12 Offers, a revolutionary technology that enables a more private, versatile, and user-friendly way to send and receive sats over the Bitcoin Lightning Network.

This blog post dives deep into our journey of integrating BOLT 12 into Strike. It's a technical exploration targeted towards both Bitcoin enthusiasts and our valued customers.

What is BOLT 12?

Introduced in September 2020 by Rusty Russell, the BOLT 12 specification provides an improved version of the current BOLT 11 standard for LN payments. If you’re familiar with LNURL - which Strike also supports! - then BOLT 12 should sound familiar on the surface. It enables features that significantly enhance the LN experience:

• Reusable QR Codes: Unlike BOLT 11 Invoices, which are generally single-use, BOLT 12 Offers can be scanned and paid multiple times. This makes them ideal for static displays like on websites, flyers, or billboards, eliminating the need to constantly generate and distribute new invoices.
• Enhanced User Security: BOLT 12 leverages onion messages, a cryptographic technique that conceals the path taken by payments within the LN. This improves the personal security of LN payments through increased privacy.
• Advanced Functionality: BOLT 12 opens doors for new native functionality like refunds or ATM-style withdrawals that were previously impossible on the Lightning Network without the use of supplementary layers such as LNURL.

Our BOLT 12 Implementation Journey

Our exploration of BOLT 12 began with an internal research paper that we wrote back in September 2021. We were intrigued by the potential benefits that BOLT 12 had to offer for improved LN payment experiences.

We devised plans for integrating BOLT 12 functionality into Strike, but the early stage nature of the proposal at that time, the fact that it would be a long time before it would be implemented into LND, combined with various other factors forced us to refocus efforts on other core functionality and play a wait-and-see game to give time for things to further evolve.

Between 2021 and 2022 members of the Bitcoin community continued to iterate on the BOLT 12 proposals, develop implementations, and champion the technology. Whilst some Lightning node implementations were quick off the mark to integrate, LND - the primary node implementation that we use at Strike -  took a more cautious and deliberate approach, focusing more on core system stability. The Lightning Labs team developed a comprehensive phased roadmap to implementing BOLT 12, integrating some of the fundamental building blocks bit by bit over a longer period of time. To this day, LND still does not support BOLT 12 though it does now support many of the core component parts and is well on the way to full native BOLT 12 support.

Upon the arrival of LNDK in March 2023, a tool spearheaded by Carla Kirk-Cohen and developed in conjunction with the Spiral team, our interest in BOLT 12 was rekindled. Described as "An experimental attempt at using LDK to implement BOLT 12 features for LND”, it essentially plugs into LND's existing APIs, enabling use of LDK’s built-in BOLT 12 support with LND.

Technical Deep Dive

The integration involved several key components:

• LND: The gRPC API exposed by the target LND node built with the appropriate rpc subservers.
• LDK: Imported as a dependency in our application layer to provide BOLT 12 Offer encoding and decoding.
• LNDK: While LNDK’s architectural overview playfully refers to LNDK as "Frankeinstein's monster," it’s actually a very clever solution. LNDK acts as a shim, leveraging LDK's modular lightning library and connecting it to LND's gRPC API. This allowed us to reuse the existing BOLT 12 implementation within LDK.

LNDK At a Glance

LNDK, the clever bridge that enables Strike to leverage BOLT 12 functionality within our existing LND infrastructure, deserves a closer look. Here's a high-level overview of its architecture and some key functionality that made it the tool of choice for our integration.

Modular Design for Flexibility

As mentioned earlier, LNDK acts as a shim, connecting LND's gRPC API with the modular Lightning library from LDK. This design offers several advantages:

• Component Reusability: By leveraging LDK's existing BOLT 12 implementation, LNDK avoids the need to reinvent the wheel. This streamlines development and ensures compatibility with the broader Lightning Network ecosystem.
• Clear Separation of Concerns: The separation between LND's core functionality and LDK's BOLT 12 support provides a relatively clean implementation which simplifies some elements of maintenance.

Onion Messaging and Offer Payments

One of the core functionalities of BOLT 12 is its use of onion messages. These cryptographic messages enable two nodes on the Lightning Network to communicate securely and privately.

The following diagram depicts how the various components interact from a high level:

Here's a simplified breakdown of how Strike uses LND, LDK and LNDK to facilitate onion message routing and the BOLT 12 protocol:

1. Payment Request: The Strike user initiates a payment by scanning a BOLT 12 Offer QR code or entering a human readable DNS address from where a BOLT 12 Offer can be fetched using BIP 353.

2. LDK Offer parsing: LDK is used to parse the BOLT 12 Offer to extract payment details.

3. Onion Message Construction: LNDK utilizes LDK's libraries and LND’s gRPC APIs to construct onion messages containing the invoice request details.

4. Relaying the Onion: The constructed onion message is then relayed through the Lightning Network by LND, traversing various nodes until it reaches the destination node specified in the Offer, where the onion message is unwrapped, revealing the request embedded in the message.

5. Retrieving a Blinded Path: The destination node uses onion messaging to send back an Invoice that includes a blinded path detailing how it can be paid.

6. Sending the Payment: LNDK interacts with LND's gRPC API to initiate the payment process.

The following diagram depicts the payment flow from a high level:

Phased Implementation Plan (3 Phases):

Given the number of moving parts, we started by outlining a three-phased approach to roll out BOLT 12 functionality within Strike. At a high level, the plan was as follows:

1. LNDK Testing and Deployment
   Establish core BOLT 12 infrastructure and functionality for internal testing and observation.
2. LNDK Platform & API Integration
   Extend Strike's platform and APIs to expose BOLT 12 functionality throughout our environment.
3. Strike Apps Integration
   Integrate BOLT 12 payment features into the Strike products.

By following this phased approach combined with insights from our earlier investigations, we felt we could ensure a controlled and efficient integration of BOLT 12 functionality within Strike.

Proof of Concept Implementation

The first step was to go from concept, to proof of concept and there were a number of technical hurdles we had to overcome along the way.

BOLT 12 Playground
We established a development environment for testing BOLT 12 payments using various combinations of nodes (LND, CLN, Eclair, and LDK-Node) and channels (direct, single hop, multi-hop, cross-implementation). We chose to open source our new BOLT 12 Playground to make it available to the wider development community. This playground proved invaluable for streamlining the testing process and facilitating collaboration.

API Integration
We worked closely with the Spiral team and LNDK contributors to enhance LNDK with a gRPC server and TLS implementation that provided a well-defined and secure interface for our application to interact with the underlying BOLT 12 functionality exposed by LNDK.

Native BOLT 12 Decoding
We leveraged LDK's generated C# bindings to enable BOLT 12 Offer and Invoice decoding directly within our .NET codebase, enabling us to limit our interactions with the LNDK daemon in favour of native code paths where possible.

Onwards...
Within a few days, we had a functional proof of concept demonstrating the ability to pay BOLT 12 Offers directly from our Strike backend systems. With this success, we were confident in moving forward with productionizing the solution.

From Proof of Concept to Production

The next - and certainly more time consuming - challenge involved transforming the proof of concept into a robust and secure system ready for real-world use within Strike's production environment. Here, we provide some insights into that effort:

Productionizing LNDK
We actively participated in shaping many features of LNDK to ensure it met our requirements and had the flexibility needed to be used in our production environment. This involved several iterations on the design, ultimately resulting in a gRPC interface secured by TLS and leveraging a tightly scoped LND macaron for authentication. We also added more granular endpoints for each phase of the BOLT 12 flow.

Challenges and Workarounds
Working closely with the LDK and LNDK developers, we were able to address issues that we found along the way, helping to bring these libraries to a stable state. Multiple new releases of LNDK, LDK, and the LDK C# bindings were cut along the way, until we had all of the necessary functionality working as we needed.

Infrastructure Deployment
For each LND node that we run, we deployed a LNDK sidecar, ensuring each LND instance has a dedicated LNDK counterpart for handling BOLT 12.

Onion Messaging Support in LND
Our LND nodes were running on version 0.17, which lacked built-in support for onion messaging - a critical component for LNDKs BOLT 12 functionality. As we weren't ready to upgrade to LND v0.18 at the time, we opted to backport the relevant changeset from v0.18 to v0.17. This ensured compatibility with BOLT 12 while maintaining stability within our existing infrastructure. In the process, we were able to help shape the LND 0.18 release (which was in its final RC phase at the time), ensuring that it shipped with everything needed to support onion messages out of the box, simplifying the process for other node operators in the future.

Production-Ready Application Code
Our proof-of-concept code underwent a significant transformation. The codebase was broken down into smaller, more focused components. This improved maintainability and facilitated a smoother integration with Strike's existing architecture. At a high level, this comprised of:

• Adding supporting libraries like a BOLT 12 Parser, a DNSSEC implementation for secure DNS lookups, and a gRPC facade for interacting with the LNDK gRPC server.
• Integrating with our existing LND node pool for managing LND node connections and distributing load across our systems.
• Finally, integrating the entire solution with our core systems, APIs, and business and consumer products to enable BOLT 12 payments from Strike!

Strike's BOLT 12 Future

Whilst we have successfully achieved our goal of enabling BOLT 12 payments from Strike, our initial integration only supports a basic Offer payment flow. However, it paves the way for exciting and more advanced BOLT 12 features over time.

We're committed to staying at the forefront of Bitcoin and Lightning Network innovation. We'll continue to work with the broader community to push the boundaries and provide you with the best possible experience.

We hope this blog post provides an interesting look behind the scenes of our BOLT 12 integration journey! As you can see, in our case the implementation took a fair amount of work given we were trailblazing and helping to develop LNDK in the process. However, with much of this groundwork now done and out there in the open source universe, we’ve proven that there is a viable path to deliver a BOLT 12 experience with LND, today.

If you'd live to give it a try, you can donate to the Human Rights Foundation's BOLT 12 Offer by scanning the QR Code below, or by paying to their BOLT 12 Lightning Address - bolt12@hrf.org

We’re excited to see the continued evolution of BOLT 12 as more services and node operators upgrade over the coming months and years.

If you have any questions, feel free to reach out to us!