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

Abstract: 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.

• The paper introduces nested threshold multi-signatures, allowing a $t$-of-$n$ group to take one signer slot of an existing multi-signature protocol without altering the protocol itself, secure up to a threshold of $t$ members
• The Iceberg construction integrates a $2t-1$ quorum with a fixed nonce for the first round, allowing a group to operate under Iceberg rules in the same round without interference from the static threshold
• The prototype established minimal overhead for thresholdized Lightning channels demonstrating a greater than 93% throughput in key configurations

The Lightning Network holds substantial value—roughly 5,600 BTC (about $490 million) in public channels as of December 2025—yet every channel endpoint is guarded by a single online signing key, a single point of failure that cannot be mitigated by cold storage because channel operation requires continuous signing. The paper under review introduces **nested threshold multi-signatures**, a new cryptographic primitive that allows a$t$-of-$n$ group to occupy one signer slot of an existing multi-signature protocol, and presents Iceberg, the first construction for thresholdizing one participant of an unmodified BIP 327 MuSig2 session. Because the group presents exactly one key, one nonce, and one partial signature, threshold custody can be adopted unilaterally by either channel endpoint with no change to Bitcoin, the Lightning protocol, or the counterparty.

Motivation and problem setting

On-chain Bitcoin custody routinely uses $t$-of-$n$ threshold signatures, but this protection has not been deployable for Lightning channels. On legacy channels, widening one side into a threshold script would require protocol changes on both peers, enlarge transactions, and leak key-management structure on chain. Taproot channels make matters stricter: the funding output is a single aggregate MuSig2 key spent by one ordinary Schnorr signature, leaving nothing visible to widen. Any usable threshold must therefore live inside one MuSig2 participant.

The core technical obstacle is the nonce. In simple taproot channels, each side commits its MuSig2 nonce a full round-trip before the commitment transaction exists, and once sent, the nonce cannot be revised. If the group's signing quorum changes between rounds—as it must be allowed to when members go offline—the nonce must remain valid. Existing schemes fail here: FROST-family constructions bind the aggregate nonce to the signing quorum; stateless deterministic-nonce schemes such as Arctic derive nonces from the message, which does not yet exist; and fully stateless signers could be tricked into signing superseded channel states, triggering Lightning's penalty mechanism.

Design

Iceberg rests on three design decisions that map directly onto constraints imposed by the Lightning environment:

1. Replicated secret sharing for quorum-independent values. The secret key $\sk = \sum_{\mathcal{S}} \phi_{\mathcal{S}}$ is split into one summand per $(t-1)$-subset, with each member holding all summands whose subset excludes it ($\binom{n-1}{t-1}$ shares). Nonces are derived deterministically via verifiable pseudorandom secret sharing (VPSS, following Arctic), so any qualifying quorum recomputes the same nonce from long-lived shares, and members absent in the first round can still sign in the second.
2. State-seeded pre-message nonces. Since the message is unavailable at nonce-commitment time, the nonce derivation is seeded with the session identifier, which includes the strictly increasing commitment number known before the transaction is assembled. This yields a fixed-yet-fresh nonce at no added cost.
3. Consensus on the live state. Deterministic nonces are safe only if no session identifier is ever signed under two messages; otherwise two partial signatures with distinct challenges expose the key. Iceberg cannot prevent reuse within the construction (the outer session is unmodified BIP 327 with $\nu=2$, so adding nonces is impossible), so it relies on Byzantine agreement on the current commitment number—a requirement any thresholdized channel already needs to avoid the penalty mechanism. This forces an honest supermajority, hence $n \geq 3t - 2$: a threshold $t$ tolerates $-of-$0 corruptions, requires a signing quorum of $-of-$1, and needs a minimal group of $-of-$2 (e.g., $-of-$3, $-of-$4, $-of-$5).

Security

The paper defines TS-MS-EUF-CMA security for nested threshold multi-signatures, generalizing the nested multi-signature model of Kohen: the adversary controls all outer co-signers, statically corrupts up to $-of-$6 group members, opens concurrent sessions, and may switch the signing quorum between rounds, subject to the consensus assertion that each session identifier is signed on at most one message.

Security is proven in two steps. First, a share-conversion lemma reduces Iceberg to a variant without share conversion, mapping replicated shares onto Shamir shares information-theoretically. Second, a straight-line reduction embeds the EUF-CMA challenge key into a single secret summand unknown to the adversary, programs the aggregation hash so the summand keys aggregate to the group key, and simulates the challenge summand via the nested multi-signature signing oracles. Unforgeability of Iceberg follows from EUF-CMA security of the underlying nested scheme, inheriting both its ROM result (with $-of-$7 at depth 2) and its ROM+AGM result (with $-of-$8, matching BIP 327), under hardness of AOMDL. The loss is negligible: $-of-$9 for $t$0 summands.

Implementation and evaluation

The prototype implements Iceberg over secp256k1 behind eclair's secp256k1-kmp bindings, so the production node obtains keys, nonces, and partial signatures from the group wherever it previously obtained them from a single signer, with no change to channel logic. Correctness was verified against Bitcoin's script interpreter on both sides of live channels, byte-for-byte replay against a reference implementation across five configurations, and sessions in which the second-round quorum differs from the first—confirming the nonce never changes.

Key measurements:

Configuration	Added cost per payment	Relative	Throughput (payments/s, one core)
bare MuSig2	—	—	17.4
$t$1	$t$2	$t$3	16.3
$t$4	$t$5	$t$6	15.2
$t$7	$t$8	$t$9	13.4

A 2-of-4 endpoint thus sustains over 93% of an unmodified endpoint's throughput. Wire traffic to the counterparty remains exactly BIP 327 (66 bytes first round, 32 bytes second); internal group traffic is 2,208 bytes per payment at $n$0, and per-member storage ranges from 100 bytes at $n$1 to 2,692 bytes at $n$2.

An instructive discrepancy emerges in the bottleneck analysis: micro-benchmarks show the group signs $n$3 slower than a single participant at $n$4, yet payment compute grows only $n$5. Decomposing a payment shows commitment updates dominate (59.6%), and within the live flow the group costs only $n$6 the signer it replaces—an effect attributed to fixed overhead of the language bindings affecting both signers. Cryptographic cost measured inside payments matches end-to-end slowdowns to within $n$7.

Limitations and open questions

Several limitations are stated plainly. The evaluation excludes inter-member network latency, assuming co-location on a low-latency local network, though a deployment adds one round trip per round across six first rounds and two second rounds per payment. The prototype covers only the active payment path: mutual close, force close, splicing, and channel announcements are not wired to a threshold signer, and announcements additionally require an ECDSA signature over the funding key, which Iceberg does not produce. Cost scales linearly with HTLCs in flight since each requires its own signature. Security assumes static corruptions (reduced from adaptive via a guessing argument justified by small signer sets), synchronous communication, honest majority, and the consensus mechanism; replicated sharing incurs $n$8 shares per member, affordable only for small groups. Two open questions are posed explicitly: which other multi-signature protocols admit nesting and with what required properties, and how much a group may change while a channel stays open—proactive share refresh, share repair, or membership/threshold changes—all of which must preserve the aggregate funding key.

Conclusion

Iceberg demonstrates that threshold custody for Lightning is achievable today by nesting a threshold group inside an existing multi-signature protocol rather than replacing it, with formal security inherited from nested MuSig2 and overhead low enough—a 2-of-4 endpoint retaining over 93% of baseline throughput—to be practical on current hardware. The construction resolves a long-standing open problem in the Bitcoin ecosystem while leaving the broader question of which multi-signature structures support such nesting open.