Source-linked AI summary
Enabling Threshold Custody for the Lightning Network with Nested Threshold Multi-Signatures
Paul Gerhart, Nadav Kohen, Jesse Posner, Matias Furszyfer
TL;DR
Lightning channel endpoints rely on vulnerable single online keys, while existing threshold schemes do not fit inside MuSig2’s fixed nonce and message flow. The paper formalizes nested threshold multi-signatures and presents Iceberg, a threshold MuSig2 construction that preserves the ordinary participant interface. Iceberg is proven secure and integrated into a production Lightning node, where a 2-of-4 endpoint sustains over 93% of an unmodified endpoint’s theoretical maximum payment throughput.
Problem
Lightning endpoints rely on single online keys, but existing threshold constructions do not support placing a threshold group inside MuSig2’s fixed nonce and signer interface.
Method
The paper formalizes nested threshold multi-signatures and instantiates the primitive with Iceberg, which operates a threshold group as one MuSig2 participant.
Results
Iceberg is proven unforgeable, deployed as a production Lightning-node integration, and a 2-of-4 endpoint sustains over 93% of an unmodified endpoint’s theoretical maximum payment throughput.
Takeaways & Limitations
Iceberg enables either Lightning endpoint to use threshold custody unilaterally without changing Bitcoin, the Lightning protocol, or its counterparty.
Takeaways & Limitations
The prototype assumes co-location on a low-latency local network, covers the active payment path, and does not yet support several channel operations or multiple in-flight HTLCs without growing cost.
Abstract
from arXiv · showhide
The Bitcoin Lightning Network secures hundreds of millions of dollars, yet channel endpoints rely on vulnerable single online keys. Although threshold signatures are routinely used to protect on-chain Bitcoin, no practical deployment has been possible for Lightning channels. This is because thresholdizing a Lightning party requires nesting a threshold signature scheme inside of an established two-party MuSig2 protocol without altering its nonce exchange or message flow. In this work, we resolve this limitation by formalizing nested threshold multi-signatures, a new cryptographic primitive for thresholdizing one participant inside a multi-signature protocol. As an instance of this primitive, we present Iceberg, the first construction for nested threshold MuSig2 signatures. Iceberg enables one side of a Lightning channel to operate as a $t$-of-$n$ threshold group while appearing to the counterparty as a standard MuSig2 participant. As a result, threshold custody can be deployed unilaterally on today's Lightning Network without requiring any modifications to Bitcoin, the Lightning protocol, or channel counterparties. We prove the security of Iceberg, integrate a prototype into a production Lightning node, and benchmark its performance. Our measurements show that thresholdizing a Lightning channel incurs only modest overhead, since a threshold group tolerating one corrupted member sustains over $93\%$ of the payment throughput of an unmodified endpoint.
1 Introduction
Lightning channels protect funds with MuSig2, but each endpoint still depends on a single online key. Iceberg introduces nested threshold multi-signatures so one endpoint can become a threshold group while remaining compatible with deployed Lightning.
- Motivation: $490 million was locked in public Lightning channels in December 2025, across roughly 15,000 public nodes and tens of thousands of channels.The reported public-channel figures are lower bounds because most channels are private.
- Lightning channel structure: A Lightning channel uses one aggregate MuSig2 key for funding and repeated 2-of-2 signatures for private balance updates and closure.Only the funding and closing transactions reach the chain; intermediate updates remain off-chain.
- Motivation: A single online endpoint key remains a single point of failure, while Lightning’s need for online signing prevents ordinary cold-storage protection.Compromise or loss of the key can make channel funds unrecoverable.
- Technical gap: Thresholdizing one Lightning participant is difficult because its threshold signer must fit inside MuSig2 without changing the fixed nonce exchange or message flow.Lightning fixes the session nonce before the transaction exists, preventing a threshold signer from freely changing its signing set afterward.
- Contribution: Iceberg formalizes nested threshold multi-signatures and provides the first construction for threshold-signing partial MuSig2 signatures.The construction is designed to place a t-of-n threshold group inside an existing multi-signature protocol.
- Deployment and evaluation: Iceberg is a drop-in MuSig2 replacement that supports unilateral threshold custody without modifying Bitcoin, Lightning, or the channel counterparty.Its first-round output matches the message of a single MuSig2 participant, and the funded channel remains an ordinary single-key Taproot output.
2 Technical Overview
Iceberg embeds a threshold group into one side of Lightning’s existing MuSig2 channel without changing the counterparty’s view or the channel’s two-round message flow. Its design addresses offline signers, fixed pre-message nonces, live-state agreement, and small deployment groups while providing a security proof.
- Design goal: Iceberg makes a thresholdized endpoint occupy one MuSig2 key slot while the counterparty and chain see ordinary MuSig2 and single-key spends.The group presents one key, nonce, and partial signature to the outer session.
- Deployment parameters: Each threshold t tolerates t −1 corruptions, requires 2t −1 online signers, and needs at least n ≥3t −2 group members.The group-size condition follows from the Byzantine agreement needed for live-state consensus.
- Protocol constraints: Lightning’s first round commits the group nonce before the message exists, and that nonce cannot change if the signing quorum later changes.This constraint requires the group to produce the same nonce for any qualifying quorum.
- Protocol constraints: A corrupt minority must not sign superseded commitments, so the group must agree on the current commitment state before signing.Otherwise, the counterparty could invoke Lightning’s penalty mechanism against the channel.
- Security and prior approaches: Existing nested MuSig2 handles only n-of-n signing, so it cannot provide the t-of-n threshold needed to tolerate offline signers.Iceberg instead introduces nested threshold multi-signatures and proves security through a share-conversion reduction.
- Construction: Iceberg uses replicated secret sharing and deterministic nonce derivation so different qualifying quorums can continue the same session across the two rounds.The construction keeps the nonce precomputation compatible with offline members and adds no rounds to MuSig2.
3 Preliminaries
The preliminaries define multi-signatures, MuSig2, VPSS, the communication model, and the security notion underlying Iceberg. MuSig2 uses two-round Schnorr signing, while VPSS supplies deterministic, verifiable shares that can be reused across public tags.
- Communication model: The construction uses pairwise authenticated channels between outer endpoints and threshold members, plus an untrusted aggregator to facilitate communication.Using another party as aggregator can leak privacy.
- Multi-signatures: A multi-signature lets ordinary-key signers produce one signature verifiable under a single aggregate key, remaining indistinguishable from a single key on chain.Its interface includes key generation, key aggregation, interactive signing, and verification.
- MuSig2: MuSig2 signs in two rounds: a message-independent nonce exchange followed by message-dependent binding, challenge, and partial-signature computation.The partial signatures sum to a Schnorr signature under the aggregate key.
- Security: Iceberg’s security notion extends nested MuSig2 security to include an internal corruption threshold, changing quorums across rounds, and channel-forced session-state agreement.Its unforgeability reduces to the EUF-CMA security of NestedMuSig2 under standard assumptions.
- VPSS: VPSS distributes long-lived t-of-n shares that deterministically derive verifiable pseudorandom sharings for each public tag without interaction.For quorum parameter µ ≥2t −1, verifiability and uniqueness hold information-theoretically.
4 Nested Threshold Multi-Signatures
Nested threshold multi-signatures place a t-of-n group inside one participant slot of an unchanged outer multi-signature protocol. The construction defines interfaces and security conditions so the group’s aggregated messages behave like those of a single outer signer.
- Definition: A nested threshold multi-signature lets a t-of-n group occupy one signer slot while leaving the outer multi-signature execution unchanged.Unlike conventional threshold signatures, it thresholds one participant inside an existing multi-signature protocol.
- Syntax: The primitive is defined for a two-round outer scheme with key aggregation KeyAgg and verification Verify.One nesting level is formalized, with deeper nestings described as generalizations.
- Interfaces: PreRound and PreAgg produce a message-independent group contribution, while SignRound and SignAgg produce the group’s second-round outer message.Aggregation condenses member shares into the single messages expected by the outer session.
- Correctness: Once combined with co-signers’ messages, the result is an ordinary signature verified under the outer aggregate key.The nested scheme therefore has no separate verification algorithm of its own.
- Correctness: Correctness requires every qualifying quorum to produce the same outer-session messages as a single signer holding the group secret key.The condition applies to every quorum of at least μ honest members.
- Security: The security game restricts each session identifier to one signed message across honest members, modeling consensus on the live state.The adversary controls outer signers and the network while statically corrupting fewer than t members.
5 Our Scheme
Iceberg instantiates nested threshold multi-signatures for MuSig2 by making a replicated threshold group appear as one ordinary signer. Its deterministic nonce handling preserves the outer protocol’s first-round message, and the final signature remains a standard MuSig2/Schnorr signature.
- Overview: Iceberg is a nested threshold multi-signature scheme designed to operate inside an unchanged outer MuSig2 session.The paper directs readers to Figure 4 for the protocol pseudocode.
- Setup and key generation: Key generation shares a secret among members, aggregates their public contributions into group key X, and places X in the outer key list.To the outer session, the group therefore looks like one ordinary signer.
- Nonce precomputation: Nonce precomputation derives deterministic per-session nonce shares and aggregates them into bound nonces before the message exists.Every qualifying quorum computes the same nonces, and absent members can later recompute their shares from their secret shares.
- Signing: In signing, members combine inner and outer binding factors using the group key, message, outer context, and aggregate nonces.The outer context includes the group’s position, co-signer keys, and outer aggregate nonces.
- Aggregation and verification: SignAgg combines quorum partial signatures into the group’s second-round message, which the outer session combines into an ordinary Schnorr signature.For Lightning, ν = 2 and nesting depth Λ = 2, leaving the BIP 327 MuSig2 session unmodified.
6 Security
The security analysis reduces Iceberg’s unforgeability to the EUF-CMA security of NestedMuSig2 through an intermediate scheme. The resulting theorem and corollary establish security under the stated random-oracle and algebraic-group assumptions.
- Reduction to Icebergbase: The proof first reduces Iceberg to Icebergbase, replacing share interpolation with replicated-share aggregation while preserving keys, nonces, and signatures.The reduction converts shares between the two schemes and treats the transformation as a wrapper.
- Reduction to NestedMuSig2: The second reduction views Icebergbase as a depth-two NestedMuSig2 session and embeds the challenge key in one hidden summand.The reduction programs key aggregation so the summand aggregate equals the group key.
- Simulation: The simulation forwards nonce and signing queries for the challenge summand to the NestedMuSig2 oracles while computing all other values honestly.Cached responses maintain consistency for repeated session identifiers.
- Forgery translation: A forgery translates when fewer than t − |corrupt| honest members signed the forged message for each session identifier.Under that condition, an appropriate challenge summand was never queried on the forged message.
- Security theorem: If NestedMuSig2 is EUF-CMA secure, Iceberg is TS-MS-EUF-CMA secure in the random oracle model for the specified hash functions.This is the paper’s Theorem 2.
- Corollary: For ν = 2 and depth-two sessions, Iceberg nested in unmodified BIP 327 is secure in the algebraic group model and random oracle model under the stated assumptions.Corollary 3 additionally assumes hardness of the algebraic one-more discrete logarithm problem for GrGen.
7 Prototype and Evaluation
The prototype integrates Iceberg into eclair as a MuSig2-compatible endpoint and evaluates correctness, communication, computation, and payment throughput across threshold configurations. Thresholdization adds fixed per-payment work, while channel logic remains the dominant bottleneck and benchmarked scope excludes several channel operations.
- Micro benchmarks: At (3, 7), a group’s internal traffic costs 2 208 bytes per payment, while the counterparty still receives 66 bytes in round one and 32 in round two.The external wire format remains that of a single BIP 327 signer.
- Drop-in replacement: Iceberg integrates behind eclair’s existing secp256k1-kmp interface, replacing single-signer outputs without changing channel logic or message flow.The group supplies a public key, public nonce, and partial signature wherever eclair previously obtained them from one signer.
- Drop-in replacement: 473 eclair channel tests pass unchanged, and the timing build passes all seventeen correctness checks.Replay also reproduces public shares, group keys, nonces, and signatures byte for byte across five threshold configurations.
- Thresholdized Lightning throughput: 17.4 payments per second is the bare-channel baseline, versus 16.3 for (2, 4) and 15.2 for (3, 7) on one core.Matching the bare rate requires 6.7 to 29.1 percent more machines, or 9.9 to 38.0 percent with member verification.
- System bottleneck: 14.3% of a payment’s CPU time is added by a (3, 7) group, despite its isolated signing being 53 times slower than one participant.The live-payment group costs 6.5 times the replaced signer because fixed secp256k1-kmp binding overhead affects both.
- Scope and limitations: The evaluation assumes co-location on a low-latency network and measures payments with a single HTLC; mutual close, force close, splicing, announcements, and other paths are not wired to Iceberg.Costs grow with the number of HTLCs in flight because each HTLC needs its own group signature.
8 Conclusion and Future Work
Iceberg nests a threshold group inside MuSig2 so the counterparty sees a single signer’s message flow, enabling unilateral threshold custody without changing Bitcoin, Lightning, or the counterparty. The work also identifies broader questions about which multi-signature protocols support nesting and how an open channel can tolerate group changes.
- Conclusion: Iceberg lets either endpoint, or both independently, use threshold custody while the counterparty observes standard MuSig2 behavior.The authors prove security and integrate the construction into eclair; a 2-of-4 endpoint sustains over 93% of an unmodified endpoint’s theoretical maximum payment throughput.
- Future work: The nesting approach raises an open question: which other multi-signature protocols admit nested thresholdization and what properties they require.For Lightning, future work includes proactive share refresh, repairing lost member shares, and changing group membership while a channel remains open.
Ethics Considerations
The paper frames its primary benefit as removing Lightning’s single online-key failure point without requiring changes from the adopting party’s counterparty, protocol, or chain. Its evaluation is controlled and non-live, and the authors characterize the construction as defensive with low assessed concrete-harm risk.
- Stakeholders: The primary stakeholders are Lightning endpoint operators and users whose funds those endpoints hold, with implementation maintainers and the wider Bitcoin community also affected.Adversaries are identified as indirect stakeholders who might study thresholdized-endpoint defenses.
- Potential benefits: Threshold custody removes the adopting endpoint’s single online-key failure point without requiring the counterparty, protocol, or chain to change.The benefit accrues to the party that adopts the construction and does not depend on others acting.
- Potential harms and dual use: The construction introduces no attack techniques or exploits, and the authors assess the risk of enabling concrete harm as low.The analyzed nonce-reuse failure mode is described as a textbook Schnorr-signature property motivating a design decision.
- Research methodology and data handling: The evaluation uses in-memory databases and no mainnet channels, real funds, third-party nodes, personal data, or human subjects.The experiments run on the authors’ own machines in a controlled environment.
- Decision to publish: The authors justify publication because the work strengthens custody for a system carrying institutional value while introducing no new offensive capability.They state the prototype’s limits to avoid presenting it as a production system.
A Deferred Preliminaries
This section recalls the security framework for nested multi-signatures and the security results used to analyze Iceberg. It also reviews VPSS1, which supports replicated sharing and local conversion to Shamir shares.
- Security framework: Nested multi-signature security requires all leaves of a cosigner tree to cooperate in producing the aggregate signature.The security game gives the adversary concurrent access to signing oracles and requires a forgery involving the challenge key.
- Security framework: The EUF-CMA definition permits adversarial control of every signer except one honest signer across concurrent signing sessions.A forgery must use the honest key in an aggregate signature on a message not previously requested under that cosigner tree.
- Security framework: Iceberg’s security is reduced to the EUF-CMA security of NestedMuSig2.The recalled scheme has results in the random oracle model and in the random oracle plus algebraic group model.
- Security results: NestedMuSig2[GrGen, ν = 8, D = 2] is EUF-CMA secure in the random oracle model under hardness of AOMDL.The theorem applies to signing sessions and forgeries with maximum depth 2.
- Security results: NestedMuSig2[GrGen, ν = 2, D = 2] is EUF-CMA secure in the algebraic group model and random oracle model under hardness of AOMDL.This result also restricts signing-session and forgery depth to at most 2.
- Secret sharing: VPSS1 generates arbitrarily many replicated shared secrets from pseudorandom-function seeds and locally converts them into Shamir shares.The share conversion requires no communication after replicated sharing.
B Additional Figures
The additional figures present protocols and algorithms used throughout the nested multi-signature construction, including VPSS variants, Icebergbase, and NestedMuSig2.
- Secret-sharing protocols: Figure 7 presents VPSS0, a VPSS1 variant without share conversion.Its subset notation follows Figure 8.
- Secret-sharing protocols: Figure 8 recalls the VPSS1 protocol from Arctic.The figure provides the notation used for subsets in the related protocol descriptions.
- Iceberg construction: Figure 9 presents Icebergbase[GrGen, ν, t] and highlights its changes relative to Iceberg[GrGen, ν, t].The figure uses the subset notation introduced in Figure 8.
- Nested signatures: The SignAgg operation is included among the protocol algorithms shown in the additional figures.
- Nested signatures: Figure 10 presents the nested multi-signature scheme NestedMuSig2[GrGen, ν].Public parameters returned by Setup are implicitly supplied to the other algorithms.