mirror of
https://github.com/lux-apps/papers.git
synced 2026-10-30 18:15:21 +00:00
zeekayandHanzo Dev
70f6883235
A July commit removed eight papers on the premise "no license — DEX/non-custodial only". That premise is wrong: Lux operates an ATS, a broker-dealer, a transfer agent and a bank, and this material is resold at lux.financial. The merge that brought main in preserved the removal because the commit stated a reason, which is how a stale reason outlives the fact it rested on. Back, at the versions main carried — main never received the removal, so its copies are the later ones: the ATS architecture, the security-token standard, smart order routing, institutional custody, MPC custody, post-quantum securities, the SSB partnership and the CoinBridge brief. 83 files. Co-authored-by: Hanzo Dev <[email protected]>
155 lines
6.6 KiB
TeX
155 lines
6.6 KiB
TeX
\section{Threshold MPC vs.\ On-Chain Multi-Signature}
|
|
|
|
\label{sec:mpc-vs-multisig}
|
|
%% =====================================================================
|
|
|
|
The choice between threshold multi-party-computation signing and
|
|
on-chain multi-signature constructions is the most consequential
|
|
single design decision in this architecture. This section makes that
|
|
decision explicit and defends it.
|
|
|
|
\subsection{The Two Constructions}
|
|
|
|
\paragraph{On-chain multi-signature.} The wallet exposes a public
|
|
script (Bitcoin: P2WSH or Taproot script-path; Ethereum: a smart
|
|
contract such as Gnosis Safe). The script encodes the threshold
|
|
$t$-of-$n$ and the public keys of all $n$ signers. Spending requires
|
|
$t$ valid signatures, each from a distinct on-chain key, presented in
|
|
the witness or contract call.
|
|
|
|
\paragraph{Threshold MPC.} The wallet exposes a single public key.
|
|
The corresponding private key has never existed in one place: it was
|
|
generated as $n$ shares via a distributed key-generation protocol,
|
|
and is used by an interactive multi-party signing protocol that
|
|
produces a single canonical chain signature. The chain sees one
|
|
signature; the threshold structure is invisible.
|
|
|
|
\subsection{Comparison}
|
|
|
|
\begin{table}[h]
|
|
\centering
|
|
\small
|
|
\begin{tabular}{p{4.5cm}p{5cm}p{5cm}}
|
|
\toprule
|
|
\textbf{Property} & \textbf{On-chain multisig} & \textbf{Threshold MPC} \\
|
|
\midrule
|
|
Privacy & Threshold and signers are visible on chain &
|
|
Wallet looks like a single-key wallet \\
|
|
Chain fees & 2--5x base txn (Bitcoin P2WSH) or 30--80k gas extra
|
|
(Gnosis Safe) & Single-sig fees \\
|
|
Cross-chain consistency & Each chain has different multisig semantics;
|
|
audit and policy must be reimplemented per chain &
|
|
One signing pipeline; same code for BTC and ETH \\
|
|
Throughput & Limited by multisig contract gas or witness size &
|
|
Limited by MPC round-trip latency only \\
|
|
Forward security & Compromise reveals which signer signed &
|
|
Aggregate signature carries no per-share attribution \\
|
|
Policy disclosure & The set of signers and the threshold are public &
|
|
Policy lives off-chain \\
|
|
On-chain code surface & Smart-contract wallet is itself attack
|
|
surface (cf.\ Parity Multisig 2017 freeze) &
|
|
No smart-contract wallet \\
|
|
Quantum hedge integration & Difficult; contract-bound to ECDSA &
|
|
Can be paired with M-Chain ML-DSA audit log (LP-006 \cite{lp006}) \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\caption{Multisig vs.\ threshold MPC.}
|
|
\label{tab:mpc-vs-multisig}
|
|
\end{table}
|
|
|
|
\subsection{Why MPC for an Eight-Billion-Dollar Fund}
|
|
|
|
Three properties dominate the decision.
|
|
|
|
\paragraph{Privacy of policy.} An on-chain $3$-of-$5$ Bitcoin wallet
|
|
publishes, in every spend, the five public keys and the threshold.
|
|
An adversary planning a targeted attack now knows exactly which five
|
|
signers to compromise and exactly the threshold to clear. With
|
|
threshold MPC the same fund publishes one address and one signature;
|
|
the adversary observes nothing about the custody policy. For a
|
|
public-figure, sovereign, or large-pension custodian this is
|
|
materially important.
|
|
|
|
\paragraph{Cross-chain uniformity.} Bitcoin multisig (P2WSH or
|
|
Taproot script-path), Ethereum multisig (Gnosis Safe), and the
|
|
multisig idioms of the Lux X-Chain and C-Chain do not share semantics.
|
|
Each chain's multisig has its own fee profile, its own upgradability
|
|
risk, and its own auditing surface. Threshold MPC over secp256k1
|
|
produces a single canonical signature acceptable to every secp256k1
|
|
chain; one signing pipeline in \texttt{luxfi/mpc} signs Bitcoin,
|
|
Ethereum, all EVM chains, and the Lux X-Chain identically.
|
|
|
|
\paragraph{Future-state quantum-resistant migration.} When the
|
|
post-quantum migration window opens, a fund holding ECDSA-signed
|
|
addresses must roll its custody. The migration target on Lux is the
|
|
M-Chain BLS+ML-DSA hybrid signing path (LP-006 \cite{lp006},
|
|
LP-020 \cite{lp020}). Threshold MPC's chain-invisibility means that
|
|
the migration is operationally a key rotation; on-chain multisig
|
|
contracts would need a contract-level migration with all the upgrade
|
|
risk that entails.
|
|
|
|
\subsection{The CGGMP21 Choice for ECDSA}
|
|
|
|
ECDSA threshold signing is harder than threshold Schnorr or
|
|
threshold BLS because ECDSA's nonce inversion is non-linear in the
|
|
secret. We adopt CGGMP21 \cite{cggmp21} for the following reasons.
|
|
|
|
\begin{enumerate}[nosep]
|
|
\item \textbf{UC-secure with identifiable abort.} A misbehaving
|
|
party is identified, not merely detected, which is a hard requirement
|
|
when shares are owned by independent legal entities.
|
|
\item \textbf{Non-interactive online phase.} Pre-signing computes
|
|
ahead of time; the live signing latency is dominated by network
|
|
round-trips rather than zero-knowledge proofs.
|
|
\item \textbf{Proactive refresh.} Shares can be refreshed without
|
|
changing the public key, which lets us rotate signing-side credentials
|
|
on the regular operational cadence (Section~\ref{sec:ops}) without
|
|
emitting a chain transaction.
|
|
\item \textbf{Implementations are public and audited.} The
|
|
\texttt{luxfi/mpc} implementation is the canonical Go codepath; it
|
|
is audited and has a published test-vector suite.
|
|
\end{enumerate}
|
|
|
|
\subsection{The FROST Path for Schnorr}
|
|
|
|
Where the chain accepts Schnorr signatures (Bitcoin Taproot
|
|
key-spend, Lux M-Chain BLS-aggregate path), FROST \cite{frost} is
|
|
preferred over CGGMP21:
|
|
|
|
\begin{itemize}[nosep]
|
|
\item Two-round signing with a one-round commit phase.
|
|
\item No range proofs and no MtA blowup.
|
|
\item Native Schnorr (BIP-340) so the on-chain signature is
|
|
indistinguishable from a single-key Taproot key-spend.
|
|
\end{itemize}
|
|
|
|
For the present architecture FROST is used on Bitcoin Taproot
|
|
key-paths and CGGMP21 is used on Ethereum and EVM chains. Both
|
|
codepaths share the same ceremony, attestation, and audit-log
|
|
surfaces; only the signing primitive differs.
|
|
|
|
\subsection{Why Not Both?}
|
|
|
|
A defensible alternative is to run on-chain multisig as a backup
|
|
recovery vehicle (e.g.\ a $3$-of-$5$ on-chain multisig at the cold
|
|
tier, signed off only when the MPC pipeline is unavailable). We
|
|
evaluated this and rejected it:
|
|
|
|
\begin{itemize}[nosep]
|
|
\item It doubles the audit surface and the ceremony surface.
|
|
\item The on-chain multisig leaks the cold-tier signing graph at
|
|
the moment it is published, even if it is never used.
|
|
\item The same disaster-recovery property is achieved by the
|
|
sealed-envelope shard scheme (Section~\ref{sec:dr}) without any
|
|
on-chain footprint.
|
|
\end{itemize}
|
|
|
|
\subsection{Conclusion}
|
|
|
|
Threshold MPC is selected for all three tiers. The custody policy
|
|
is invisible to the chain. The signing pipeline is one pipeline
|
|
across BTC, ETH, and Lux. The migration to a post-quantum signing
|
|
primitive is a key rotation rather than a contract migration.
|
|
|
|
%% =====================================================================
|