💻 computer science

Enabling Threshold Custody for the Lightning Network with Nested Threshold Multi-Signatures

This paper introduces "Iceberg," a novel cryptographic construction for nested threshold MuSig2 signatures that enables one side of a Bitcoin Lightning Network channel to operate as a secure $t$ -of- $n$ threshold group without requiring any modifications to the underlying protocol, Bitcoin, or counterparties, while maintaining high payment throughput.

Original authors: Paul Gerhart, Nadav Kohen, Jesse Posner, Matias Furszyfer

Published 2026-08-24

📖 7 min read🧠 Deep dive

CC BY 4.0

Original authors: Paul Gerhart, Nadav Kohen, Jesse Posner, Matias Furszyfer

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

In the digital world of Bitcoin, money moves through two distinct layers. The main layer, known as the blockchain, is a public ledger where transactions are recorded permanently. On top of this sits the Lightning Network, a faster, private system designed to handle thousands of payments per second without cluttering the main ledger. To use this system, two people open a private channel between them, locking their funds under a special digital lock that requires both of their approval to spend. This setup has become vital for major financial institutions, handling hundreds of millions of dollars in value. However, a critical weakness has persisted since the network's inception: the digital keys that control these funds on each side of the channel are held by a single device. If that one device is stolen, hacked, or simply lost, the funds are gone forever. There is no backup, no recovery, and no way to split the authority among several people or machines.

For years, experts have known that the solution lies in "threshold custody," a method where a group of people must agree to sign a transaction, but not every single member needs to be present. This is standard practice for securing large sums on the main blockchain, but it has been impossible to apply to the Lightning Network. The reason is a technical deadlock: the Lightning Network requires a specific, rigid handshake between two parties to update balances, and this handshake does not allow one side to suddenly reveal that it is actually a group of people. If one side tried to use a group key, it would break the protocol, forcing the other person to change their software or the entire network to adapt. This has left the Lightning Network vulnerable, relying on fragile single points of failure while the rest of the financial world moves toward more robust, distributed security.

A team of researchers has now solved this problem by inventing a new cryptographic method called Iceberg. Their work allows one side of a Lightning channel to operate as a secure group of signers while appearing to the other side as a single, ordinary user. Imagine a bank vault that requires three managers to open, but to the outside world, it looks like a single person is turning the key. The researchers achieved this by creating a system where the group's internal agreement happens invisibly, behind the scenes, without ever altering the messages sent to the counterparty. The result is a way to distribute risk and prevent total loss without requiring any changes to the Bitcoin network, the Lightning protocol, or the software used by the other person in the channel.

The core of the innovation lies in how the group handles the digital "nonces," which are random numbers used to create a signature. In the Lightning Network, these numbers must be agreed upon before the specific transaction details are even known. This creates a unique challenge: if the group changes its members between the time the number is chosen and the time the transaction is signed, the signature could fail or become insecure. Previous attempts to solve this either required all members to be online at the same time or forced the group to reveal its internal structure. The Iceberg system overcomes this by using a technique called replicated secret sharing. In this setup, every member of the group holds a piece of the secret key, but the pieces are arranged so that any small majority of the group can reconstruct the necessary numbers, regardless of who is currently online. Crucially, the system derives these numbers in a way that depends only on the state of the channel, not on which specific members are present. This means that if some members go offline or if the group composition shifts, the remaining members can still produce the exact same signature that was promised earlier, keeping the channel secure and functional.

To prove this concept works in the real world, the researchers built a working prototype and integrated it into a production Lightning node, a piece of software used to route payments. They tested the system under various conditions, simulating groups of different sizes and tolerating different numbers of faulty or missing members. The results showed that the new method adds only a tiny amount of time to the payment process. For a group designed to tolerate one corrupted member, the extra time required was just 3.8 milliseconds per payment. This represents a mere 6.7 percent increase in the computational work already required for a standard transaction. Even with larger groups designed to handle more failures, the system maintained high speed, sustaining over 93 percent of the payment throughput of a standard, unmodified channel. This demonstrates that the security of threshold custody can be added to the Lightning Network today without sacrificing the speed that makes the network useful.

The security of this new system was also rigorously proven. The researchers showed that as long as the group has a majority of honest members, it is mathematically impossible for an attacker to forge a signature or steal the funds, even if they control some of the group's devices. The proof accounts for the complex reality of the Lightning Network, where members might go offline, messages might be delayed, and the group might need to agree on the current state of the channel before signing. By formalizing a new type of cryptographic primitive called "nested threshold multi-signatures," the team provided a mathematical guarantee that the group acts as a single, secure entity. This means that institutions and individuals can now deploy this protection unilaterally; they can upgrade their own security without asking anyone else to change their software or without waiting for a network-wide upgrade.

The implications of this work extend beyond just fixing a vulnerability; it changes how we think about securing digital assets in a distributed system. For years, the Lightning Network was seen as a trade-off: speed and privacy came at the cost of relying on single, fragile keys. Iceberg removes that trade-off, allowing the network to scale with the same level of security that large institutions already demand for their on-chain assets. The researchers verified that their system works seamlessly with existing hardware and software, meaning that the transition to this safer model can happen immediately. By integrating the solution into a real-world node and measuring its performance, they moved the concept from a theoretical possibility to a practical tool. The findings confirm that the Lightning Network can now support the kind of robust, multi-party custody that protects against both theft and accidental loss, securing the hundreds of millions of dollars currently flowing through it.

This breakthrough does not rely on changing the fundamental rules of Bitcoin or the Lightning Network. Instead, it works by fitting a complex, multi-person security system inside the simple, single-person slot that the network expects. It is a reminder that sometimes the most effective solutions are not about building something new from scratch, but about finding a way to make existing structures hold more weight. The researchers have shown that with the right mathematical approach, it is possible to hide a group of guardians behind a single face, ensuring that the digital money moving at lightning speed is as safe as the people who use it. The path forward is now clear: the technology exists to protect these funds, and the only barrier left is the decision to adopt it.

Technical Summary: Enabling Threshold Custody for the Lightning Network with Nested Threshold Multi-Signatures

1. Problem Statement

The Bitcoin Lightning Network secures hundreds of millions of dollars in value, yet its security model relies on a fragile foundation: each channel endpoint is controlled by a single online key. This creates a single point of failure, susceptible to both compromise (theft) and loss (inaccessibility). While threshold custody (t-of-n signing) is standard practice for on-chain Bitcoin assets to mitigate these risks, it has not been practically deployable for Lightning channels.

The core technical obstacle is the structure of the Lightning protocol, specifically its reliance on the MuSig2 multi-signature scheme (standardized in BIP 327). In a Lightning channel, two parties (Alice and Bob) lock funds under an aggregate key. To update balances or close the channel, they must exchange nonces and partial signatures in a strict two-round protocol.

The Nonce Constraint: MuSig2 requires the session nonce to be fixed in the first round, before the message (the transaction to be signed) is known.
The Threshold Conflict: If one party (e.g., Alice) is a threshold group, the set of online signers may change between the first round (nonce generation) and the second round (signature generation). Standard threshold signature schemes (like FROST) bind the aggregate nonce to the specific set of signers participating in that round. If the quorum changes, the reconstructed nonce would differ from the one Alice promised to Bob in the first round, breaking the protocol.
Statelessness vs. Safety: Stateless threshold signatures (which derive nonces deterministically from the message) cannot be used because the message is unknown during the first round. Furthermore, fully stateless signers in Lightning would be vulnerable to signing outdated channel states, triggering the network's penalty mechanisms (confiscation of funds).

Consequently, the community has lacked a method to "nest" a threshold group inside an existing MuSig2 session without altering the protocol, the counterparty, or the blockchain.

2. Methodology and Design

The authors propose Iceberg, the first construction for nested threshold MuSig2 signatures. Iceberg allows a t-of-n group to occupy a single signer slot in a MuSig2 protocol, appearing indistinguishable from a standard single-key participant to the counterparty and the blockchain.

The solution relies on three key design decisions to satisfy the constraints of the Lightning environment:

Replicated Secret Sharing (RSS): To ensure the nonce remains consistent regardless of which subset of signers is online, Iceberg uses replicated secret sharing rather than standard Shamir secret sharing. The secret key is split into shares for every subset of $t-1$ members. Each member holds shares corresponding to the subsets they are not in. This allows any qualifying quorum ( $2t-1$ members) to reconstruct the same deterministic nonce shares without needing to communicate with members who were offline during the first round.
Unique Pre-Message Nonces: Since the nonce must be fixed before the message is known, Iceberg derives the nonce deterministically from the session identifier (which includes the channel's commitment number) rather than the message itself. This ensures the nonce is fixed in the first round but unique to each channel state update, preventing key leakage that would occur if the same nonce were reused for different messages.
Consensus on Live State: To prevent the security risk of signing two different messages under the same session identifier (which would leak the key), the protocol relies on the Lightning channel's existing requirement for consensus on the current commitment number. The threshold group must agree on the live state before signing, ensuring that an honest supermajority ( $n \ge 3t-2$ ) prevents a corrupt minority from forcing a second signature on the same state.

Protocol Flow:

KeyGen: The group generates a shared secret key using RSS. The aggregate public key occupies the group's slot in the funding output.
PreRound (Offline): Before the message exists, the group computes nonce shares based on the session identifier. These are aggregated into a single group nonce $R_A$ sent to the counterparty.
SignRound (Online): Once the message and counterparty's nonce are known, the online quorum computes partial signatures using their key shares and nonce shares. These are aggregated into a single partial signature $s_A$ .
Result: The counterparty combines $s_A$ and their own $s_B$ to form a valid MuSig2 signature. The blockchain sees only a standard Schnorr signature under the aggregate key.

3. Key Contributions

Formalization of Nested Threshold Multi-Signatures: The paper introduces a new cryptographic primitive designed to thresholdize one participant within an existing multi-signature protocol without altering the outer protocol's message flow or nonce exchange.
The Iceberg Construction: A concrete, provably secure implementation of nested threshold MuSig2. It is the first scheme to support dynamic quorums (where the signing set can change between rounds) while maintaining the strict nonce requirements of Lightning.
Security Proof: The authors prove the unforgeability of Iceberg under the TS-MS-EUF-CMA security model. The proof reduces Iceberg's security to the security of the underlying NestedMuSig2 scheme, demonstrating that unforgeability holds even if an adversary compromises up to $t-1$ members and controls the outer co-signer.
Production Integration: Iceberg was integrated into eclair, a production Lightning node implementation. The integration required no changes to the channel logic, message flow, or the counterparty's software.

4. Results and Performance

The authors benchmarked Iceberg on a production-grade environment using the secp256k1 curve and the eclair node.

Overhead: Thresholdizing a channel incurs modest computational overhead.
- For a 2-of-4 configuration (tolerating 1 fault), the total added cost per payment is 3.8 ms (specifically 3,844 µs), which represents 6.7% of the total work a payment already costs.
- For a 3-of-7 configuration (tolerating 2 faults), the total added cost is 8.2 ms (specifically 8,246 µs), representing approximately 14.3% of the total payment work.
Throughput: A thresholdized endpoint sustains high throughput. A 2-of-4 group maintains over 93% of the payment throughput of an unmodified endpoint (approx. 16.3 payments per second on a single core vs. 17.4 for a single key).
Scalability: The cost growth is primarily driven by the fault tolerance threshold ( $t$ ) rather than the total group size ( $n$ ), provided $n$ remains within practical bounds (e.g., a dozen devices).
Compatibility: The prototype successfully passed all existing eclair channel tests and verified that the group never revises its nonce even when the signing quorum changes between rounds, satisfying the strict constraints of the Lightning protocol.

5. Significance and Claims

The paper claims that Iceberg enables the unilateral deployment of threshold custody on the Lightning Network today.

No Protocol Changes: Unlike previous proposals that required changes to Bitcoin Script or the Lightning protocol itself, Iceberg works within the existing BIP 327 MuSig2 specification.
No Counterparty Changes: The counterparty (Bob) and the blockchain see only a standard single-key MuSig2 participant. No coordination or software updates are required from the other side of the channel.
Practicality: The performance overhead is low enough that institutions and users can adopt threshold custody immediately without sacrificing the speed or capacity of the Lightning Network.

The authors conclude that Iceberg resolves a long-standing open problem in the Bitcoin community, demonstrating that thresholdizing a Lightning channel is achievable without compromising the protocol's efficiency or security guarantees. They note that future work could explore proactively refreshing shares or changing membership while a channel is open, provided the aggregate key remains constant.