mirror of
https://github.com/lux-apps/papers.git
synced 2026-10-30 18:15:21 +00:00
zeekay
abf99d05fc
Restructured from flat .tex/.pdf files into per-paper subdirectories. Added Antje Worring as co-author on all papers. Synced PDFs to pdfs/ for download site.
130 lines
4.2 KiB
TeX
130 lines
4.2 KiB
TeX
\section{Per-Chain Analysis}
|
|
|
|
|
|
\subsection{Bitcoin}
|
|
|
|
\subsubsection{Key Generation and Address Derivation}
|
|
|
|
Bitcoin generates an ECDSA key pair $(sk, pk)$ on secp256k1. The
|
|
address is derived through two hash layers:
|
|
|
|
\begin{enumerate}[nosep]
|
|
\item $h_1 = \text{SHA-256}(pk)$
|
|
\item $h_{160} = \text{RIPEMD-160}(h_1)$
|
|
\item $\text{address} = \text{Base58Check}(\text{version} \| h_{160}
|
|
\| \text{checksum})$
|
|
\end{enumerate}
|
|
|
|
\subsubsection{Public Key Exposure}
|
|
|
|
The public key $pk$ is \emph{not} revealed when receiving Bitcoin. The
|
|
address is a hash of $pk$, and hash preimage resistance protects $pk$
|
|
even if the address is known. The public key is revealed only when
|
|
\emph{spending}---the transaction includes $pk$ for signature
|
|
verification.
|
|
|
|
\subsubsection{Quantum Vulnerability Window}
|
|
|
|
The exposure window is the time between transaction broadcast and
|
|
block confirmation ($\sim$10 minutes for one confirmation, $\sim$60
|
|
minutes for six). An adversary must derive $sk$ from $pk$ within this
|
|
window to redirect funds.
|
|
|
|
\begin{remark}
|
|
Bitcoin's recommended practice of single-use addresses provides
|
|
additional protection: once an address's public key is revealed by
|
|
spending, no further funds should be sent to it. Unspent outputs at
|
|
never-used addresses have zero public key exposure.
|
|
\end{remark}
|
|
|
|
\subsection{Ethereum}
|
|
|
|
\subsubsection{Key Generation and Address Derivation}
|
|
|
|
Ethereum generates an ECDSA key pair on secp256k1. The address is
|
|
the last 20 bytes of the Keccak-256 hash of the public key:
|
|
|
|
\[
|
|
\text{address} = \text{Keccak-256}(pk)[12{:}32]
|
|
\]
|
|
|
|
\subsubsection{Public Key Exposure}
|
|
|
|
The public key is \textbf{effectively always exposed}. It can be
|
|
recovered from any ECDSA signature via ecrecover:
|
|
|
|
\[
|
|
pk = \text{ecrecover}(\text{msgHash}, v, r, s)
|
|
\]
|
|
|
|
Once an account has signed any transaction, the public key is
|
|
permanently derivable from the blockchain history.
|
|
|
|
\subsubsection{Quantum Vulnerability Window}
|
|
|
|
The exposure window is \textbf{permanent} for any account that has
|
|
ever sent a transaction. An adversary does not need to race against
|
|
block confirmation---they can extract $pk$ from historical transactions
|
|
at leisure and compute $sk$ offline.
|
|
|
|
\begin{remark}
|
|
Ethereum's account model exacerbates the risk. Unlike Bitcoin's UTXO
|
|
model where each output can use a fresh key, Ethereum accounts are
|
|
long-lived and typically reuse the same key for all transactions.
|
|
\end{remark}
|
|
|
|
\subsection{Solana}
|
|
|
|
\subsubsection{Key Generation and Address Derivation}
|
|
|
|
Solana uses Ed25519 key pairs. Unlike Bitcoin (SHA-256 + RIPEMD-160)
|
|
or Ethereum (Keccak-256), Solana applies \emph{no hash layer at all}:
|
|
the address is the raw public key, base58-encoded.
|
|
|
|
\[
|
|
\text{address} = \text{base58}(pk)
|
|
\]
|
|
|
|
\subsubsection{Public Key Exposure}
|
|
|
|
The public key is \emph{always} visible to anyone who knows the
|
|
address---there is no hash-based protection, even before first spend.
|
|
This is strictly weaker than Bitcoin's UTXO model (pk hidden until
|
|
spend) and equivalent in outcome to Ethereum's permanent exposure.
|
|
|
|
\subsubsection{Quantum Vulnerability Window}
|
|
|
|
Permanent from the moment an address is published. A quantum adversary
|
|
with Shor's algorithm can recover the secret key from the address
|
|
directly, without needing a prior transaction. Solana has the
|
|
\emph{worst} public-key exposure profile of the four chains analysed
|
|
here.
|
|
|
|
\subsection{Cardano}
|
|
|
|
\subsubsection{Key Generation and Address Derivation}
|
|
|
|
Cardano uses separate spending and staking key pairs. Addresses are
|
|
derived via Blake2b-224:
|
|
|
|
\begin{align*}
|
|
\text{PaymentKeyHash} &= \text{Blake2b-224}(\text{PublicSpendingKey}) \\
|
|
\text{StakeKeyHash} &= \text{Blake2b-224}(\text{PublicStakingKey}) \\
|
|
\text{BaseAddress} &= \text{Bech32}(\text{NetworkID} \|
|
|
\text{PaymentKeyHash} \| \text{StakeKeyHash})
|
|
\end{align*}
|
|
|
|
\subsubsection{Public Key Exposure}
|
|
|
|
The spending public key is revealed when signing a transaction.
|
|
Cardano's extended UTXO model allows address reuse, but best practice
|
|
is to derive fresh addresses for each transaction.
|
|
|
|
\subsubsection{Quantum Vulnerability Window}
|
|
|
|
Similar to Bitcoin: the public key is exposed at signing time. However,
|
|
Cardano's faster block times ($\sim$20 seconds) reduce the exposure
|
|
window compared to Bitcoin's 10 minutes.
|
|
|
|
%% ============================================================
|