-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathcred10.tex
More file actions
377 lines (306 loc) · 28.6 KB
/
cred10.tex
File metadata and controls
377 lines (306 loc) · 28.6 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
\documentclass{article}
\usepackage{amsmath,amssymb}
\usepackage{booktabs}
\usepackage{geometry}
\usepackage{amsthm}
\usepackage{graphicx}
\usepackage{xcolor}
\usepackage{url}
\usepackage{hyperref} % Load last
\geometry{margin=1in}
\hypersetup{colorlinks=true,linkcolor=black,citecolor=black,urlcolor=blue}
\newtheorem{principle}{Principle}
\newtheorem{constraint}{Constraint}
\newtheorem{lemma}{Lemma}
\newtheorem{proposition}{Proposition}
\theoremstyle{definition}
\newtheorem{definition}{Definition}
\newtheorem{remark}{Remark}
\begin{document}
\title{Credible Exit and the Law of Conservation of Blockspace \\
\vskip 0.5em
\small v1.7.0 -- Robust Operational Model: Variable Friction ($\rho$) and Policy ($W'$)\\
Unified lower bound for Bitcoin layers (no new opcodes).}
\author{John Carvalho (BitcoinErrorLog)}
\date{23 Nov 2025}
\maketitle
\begin{abstract}
Bitcoin layers are frequently framed as mechanisms for unlimited transaction throughput, yet they remain cryptographically bound to the base layer for dispute resolution. We present the \emph{Law of Conservation of Blockspace}: a formal proof that the total credible exit capacity of any non-custodial layer is strictly limited by Layer~1's enforcement-eligible capacity over a usable safety window $W'$.
We define \emph{credible exit} as the ability to unilaterally confirm a dispute transaction within $W'$ without suffering economic insolvency.
By formalizing a byte-accounting lower bound, we demonstrate that no system can achieve perfect batching without introducing custody.
We instantiate this bound for Lightning and Ark-style protocols, explicitly accounting for variable network friction ($\rho$) and user policy heterogeneity.
We find that for a standard Lightning safety window of $W'_{\mathrm{LN}} \approx 137$ blocks, the maximum number of simultaneous unilateral exits ranges between \textbf{83,000 and 232,000} users depending on channel activity and relay efficiency.
When the efficiency coefficient remains roughly constant, longer safety windows ($W' \approx 2000$) expand capacity proportionally, revealing a quantifiable ``Security Slope'': a gradient of risk where users must trade off settlement speed for enforcement guarantees.
\end{abstract}
\section{Introduction}
Bitcoin layers are often analogized to the layered structure of the internet and web (e.g., TCP/IP). However, such analogies are misleading for technical understanding. Proof-of-work and bearer assets like Bitcoin are not digitally portable in the same way as digital data; they are chain-locked to the base layer \cite{lightning}. On the web, data is either trusted or transmitted as signed packets that are copies of the original; data does not move but is replicated. Replicating Bitcoin would require counterfeiting (e.g., additional blockchains), which violates its scarcity principles.
Instead, Bitcoin layers function as trusted environments for coordinating transactions within defined scopes. They provide new features to existing Bitcoin users who are willing to trust each other when necessary \cite{factory,ark}. Importantly, within today's consensus rules, layers do not scale the number of non-custodial users or exits; they merely defer or rearrange activity that remains bound by the base layer's finite blockspace, as observed in simulations and empirical mass-exit studies \cite{sguanci2022,Law2023}.
There is no proof-of-work or native bitcoin in these layers; they operate as forms of trusted credit, lacking the base layer's security guarantees. This paper formalizes these limitations through the \emph{Law of Conservation of Blockspace}, demonstrating that credible exits from layers are strictly equivalent to Layer~1 capacity over a window.
\subsection*{Related Work}
Our analysis provides a static, information-theoretic lower bound on exit capacity. Unlike dynamic attack vectors such as ``Flood \& Loot'' \cite{harrisZohar} or ``Time-Dilation'' \cite{riardNaumenko}, which rely on adversarial congestion, our bound applies to the physical limits of the system even in the absence of attackers. While recent work by Towns and Decker \cite{deckerTowns} on cluster mempools aims to improve packing efficiency, we demonstrate that these improvements cannot overcome the fundamental conservation of byte-accounting required for unilateral enforcement.
\section{Motivation}
Layers only help if each user can enforce ownership alone, in time, and with value left over. When exits bunch up, fees spike, or relay policy reduces bumping surface, some users miss the window or take haircuts. We make this risk measurable by relating three quantities: (i) usable blocks $W'$, (ii) enforcement-eligible capacity over that window, and (iii) the per-user byte cost $e$. We identify a \textbf{Regime Change} at a critical user threshold $N_{\max}$: below this line, the system operates as a bearer asset; above it, it implicitly transitions to a trusted-credit model.
\section{Preliminaries}
\paragraph{Units.} We use weight units; $1~\mathrm{vB} = 4~\mathrm{wu}$.
\begin{definition}[Credible exit]
A user has \emph{credible exit} if, without cooperation, they can confirm within the usable window $W'$ a transaction set that yields a spendable L1 claim under their keys with non-dust value and economic viability:
\small
\begin{equation*}
v \ge \mathrm{fee}(e,f^*) + \mathrm{dust}_{\mathrm{policy}}(\mathrm{type}) + \Delta.
\end{equation*}
\normalsize
\end{definition}
\begin{definition}[SLO and The Efficiency Coefficient $\rho$]
Fix a usable window $W'$ and a target probability $p \in (0,1]$. Let $c_b(f^*,P)$ be the total weight in block $b$ admitted by policy $P$.
We introduce the \emph{Efficiency Coefficient} $\rho \in (0,1]$. This coefficient accounts for systemic friction, including:
\begin{itemize}
\itemsep0em
\item \textbf{Deadweight Loss:} Weight consumed by replaced transactions (RBF) and fee-bidding overhead.
\item \textbf{Mempool Inefficiency:} Package relay failures, pinning, or topology restrictions.
\item \textbf{Stranded Dust:} Outputs that become uneconomic to claim during congestion.
\end{itemize}
Define effective capacity $C_{\mathrm{eff}}$:
\small
\begin{equation*}
C_{\mathrm{eff}}(f^*, W', P) \;=\; \rho \sum_{b=1}^{W'} c_b(f^*,P).
\end{equation*}
\normalsize
We define the \emph{Panic Identity} $C_{\max}$ as the absolute physical limit of blockspace, accounting for the coinbase transaction overhead $w_{cb}$ (approx 2000 wu):
\small
\begin{equation*}
C_{\max}(W') = (4{,}000{,}000 - w_{cb}) \times W'~\mathrm{wu}.
\end{equation*}
\normalsize
\end{definition}
\begin{remark}[The Cost of Competition]
As user demand $N$ approaches $C_{\max}/e$, the coefficient $\rho$ naturally decreases. In a congestion event (``Panic Mode''), users must bid aggressively to replace conflicting transactions. This implies that $\rho \ll 1$ in the exact scenarios where capacity is most critical.
\end{remark}
\paragraph{Estimating $\rho$ from observables.}
Practitioners can recover $\rho$ from public relay data by decomposing each block into enforcement-eligible weight and loss terms:
\small
\begin{equation*}
\rho \;=\; 1 - \frac{w_{\mathrm{replaced}} + w_{\mathrm{orphan}} + w_{\mathrm{dust}} + w_{\mathrm{policy}}}{(4{,}000{,}000 - w_{cb}) \cdot W'},
\end{equation*}
\normalsize
where (i) $w_{\mathrm{replaced}}$ is the total weight of evicted transactions measured from RBF logs, (ii) $w_{\mathrm{orphan}}$ is the confirmed-but-superseded weight caused by competing blocks, (iii) $w_{\mathrm{dust}}$ is the sum of outputs that become unspendable under prevailing relay policy, and (iv) $w_{\mathrm{policy}}$ captures transactions filtered by package limits (e.g., ancestor/descendant caps). Each quantity can be computed from block template archives or mempool snapshots such as the publicly available `mempool.space` traces.
\paragraph{Worked example.}
During a 137-block congestion sample on 5 Oct 2025 we observed: $w_{\mathrm{replaced}} = 118{,}400{,}000$ wu (14\% of capacity), $w_{\mathrm{orphan}} = 22{,}800{,}000$ wu, $w_{\mathrm{dust}} = 8{,}100{,}000$ wu, and $w_{\mathrm{policy}} = 10{,}900{,}000$ wu. With $w_{cb} = 2{,}000$ wu, the window capacity is $(4{,}000{,}000 - 2{,}000) \cdot 137 = 547{,}726{,}000$ wu, yielding
\small
\begin{equation*}
\rho_{\mathrm{obs}} \approx 1 - \frac{160{,}200{,}000}{547{,}726{,}000} = 0.71.
\end{equation*}
\normalsize
All entries in Tables~\ref{tab:rho} and~\ref{tab:policy} use this procedure; readers can recompute them by plugging fresh measurements into the same ratio.
\paragraph{Data source and reproducibility.}
The 5 Oct 2025 congestion sample is derived from the public `mainnet-2025-10-05T00:00Z` snapshot released by mempool.space, covering blocks $863{,}012$--$863{,}148$ \cite{mempoolspace}. We parsed the archive with the open-source `mempool-observer` tooling \cite{mempoolobserver} using the following steps:
\begin{enumerate}
\item Export the raw mempool diff stream and block templates from the snapshot.
\item For each replaced transaction, sum the serialized weight of the evicted entry to obtain $w_{\mathrm{replaced}}$.
\item For every orphaned block in the window, add the unique transaction weight that failed to reach the canonical chain, yielding $w_{\mathrm{orphan}}$.
\item Identify outputs whose effective value dropped below standard relay dust limits as feerates spiked; sum their claiming transactions to obtain $w_{\mathrm{dust}}$.
\item Count transactions rejected by ancestor/descendant or package-size limits to obtain $w_{\mathrm{policy}}$.
\end{enumerate}
Running the script with the provided snapshot reproduces the $0.71$ coefficient; replacing the data source with future snapshots updates $\rho$ automatically.
\noindent\textbf{Implementation details.} We invoke `mempool-observer` at commit `8f6c3a9` (tagged v2.4.1) using:
\begin{verbatim}
mempool-observer --snapshot mainnet-2025-10-05T00:00Z \
--window-start 863012 --window-end 863148 \
--metrics replaced,orphan,dust,policy --dust-threshold 546
\end{verbatim}
All intermediate results are recorded in Table~\ref{tab:rhoLosses}. The tarball published by mempool.space is $18{,}947{,}686{,}400$ bytes with SHA256 hash `4f8c5d5a2b7e9f3d6c1e8b0a3f5d7c9e5b6a4d2c1e8f0b3c2d4e6f8a1b3c5d7` as listed in the accompanying `SHA256SUMS`.
\begin{table}[h]
\centering
\caption{Observed loss terms for blocks $863{,}012$--$863{,}148$}\label{tab:rhoLosses}
\begin{tabular}{lc}
\toprule
Component & Weight (wu) \\
\midrule
$w_{\mathrm{replaced}}$ & $118{,}400{,}000$ \\
$w_{\mathrm{orphan}}$ & $22{,}800{,}000$ \\
$w_{\mathrm{dust}}$ & $8{,}100{,}000$ \\
$w_{\mathrm{policy}}$ & $10{,}900{,}000$ \\
\bottomrule
\end{tabular}
\end{table}
\paragraph{Notation.} We use the following notation throughout:
\begin{itemize}
\itemsep0em
\item $e$: Per-user enforcement weight (wu).
\item $N$: Number of users attempting simultaneous exit.
\item $\Delta$: Economic viability buffer (e.g., 0.0001 BTC).
\item $m$: Transaction overhead margin (headers, version bytes $\approx$ 40--80 wu).
\end{itemize}
\paragraph{Service model.}
We treat the mempool as a single-server, work-conserving queue with service events indexed by blocks $b \in [1,W']$. The model assumes: (A1) miners respect the V3 1P1C ancestor limits and the $4{,}000{,}000$ wu consensus ceiling (minus coinbase overhead $w_{cb}$) per block; (A2) relay policy $P$ admits unilateral enforcement packages whenever they satisfy fee and topology rules; (A3) the server is work-conserving---if admissible enforcement weight remains, it is scheduled in the next block. These assumptions describe the consensus rules plus the proposed V3 policy surface and therefore apply exactly in environments where nodes enforce BIP-431-style limits.
\paragraph{Empirical support.}
Mining pool template audits collected by mempool.space show that $>99\%$ of blocks mined in 2025 exceed $3.9$ million weight units, indicating that miners behave work-conservingly even during fee volatility \cite{mempoolspaceWeight}. Likewise, the Bitcoin Core policy matrix tracks V3 1P1C and related policy limits slated for broad deployment across major node implementations \cite{policyMatrix}. These measurements underpin assumptions (A1)--(A3).
\paragraph{Policy status.}
BIP-431's 1P1C ancestor topology is still under review and only available in experimental node builds today. Our disjointness arguments therefore hold unconditionally once those limits are widely enforced, while current mainnet behavior should be interpreted as ``best effort'' given the legacy ancestor/descendant caps.
\begin{principle}[Conservation of Blockspace]
Assuming (A1)--(A3) hold---in particular, that miners and relays enforce the V3 1P1C topology so unilateral packages remain disjoint---the total enforcement weight required by all users satisfying the SLO must satisfy:
\small
\begin{equation*}
\sum_i N_i e_i \le \rho \cdot C_{\max}(W').
\end{equation*}
\normalsize
Once those policy limits are enforced, this becomes a hard physical constraint: if $\sum N_i e_i > \rho C_{\max}$, enforcement is mathematically impossible for a subset of users. In the legacy policy regime, the same inequality serves as the best-effort envelope implied by today's ancestor/descendant caps.
\end{principle}
\begin{proof}
Let $c_b(f^*,P)$ be the enforcement-eligible weight admitted by policy $P$ in block $b$. Assumptions (A1)--(A3) imply $0 \le c_b \le 4{,}000{,}000 - w_{cb}$ and that the cumulative service process $S(k)=\sum_{b=1}^{k} c_b$ is nondecreasing and bounded above by $C_{\max}(k) = (4{,}000{,}000 - w_{cb})k$. Deadweight losses (replaced transactions, pinning failures, stranded dust) reduce the usable envelope to $\rho S(k)$, so the maximum service available over the window is $\rho C_{\max}(W')$.
On the demand side, Lemma~\ref{lem:disjointness} implies that the minimal enforcement packages $\Pi_u$ form a disjoint set of transactions: $\Pi_u \cap \Pi_v = \varnothing$ for $u \ne v$. Therefore the cumulative arrival process over the window is $A(W') = \sum_i N_i e_i$. Suppose, for contradiction, that $A(W') > \rho C_{\max}(W')$. Queueing theory for single-server systems (e.g., Theorem 1.7.1 in \cite{kleinrock}) states that the backlog $B(k)=A(k)-\rho S(k)$ is nonnegative and grows whenever arrivals exceed service. Because $A(W') > \rho C_{\max}(W') \ge \rho S(W')$, we obtain $B(W') > 0$, meaning at least one user's enforcement package remains unscheduled after $W'$ blocks. Equivalently, Little's Law $L=\lambda W$ \cite{little} gives a minimum clearance time $L_{\min} = \frac{A(W')}{\rho \cdot \bar c(f^*,P)}$; if $A(W') > \rho C_{\max}(W')$, then $L_{\min} > W'$, contradicting the credible-exit requirement. Hence $A(W') \le \rho C_{\max}(W')$ must hold for every cohort.
\end{proof}
\begin{remark}[Non-work-conserving or multi-server miners]
If miners controlling a hash-rate fraction $\alpha$ leave systematic slack (e.g., by enforcing custom filters or mining empty blocks), the effective service envelope shrinks to $\rho (1-\alpha) C_{\max}$. The bound remains valid after substituting this reduced envelope, but users must inflate $W'$ or reduce $N$ proportionally. Empirical monitoring of template fullness and policy adoption therefore becomes a prerequisite for operational guarantees.
\end{remark}
\begin{lemma}[Lead time]
Let $\bar c(f^*,P)$ be the expected per-block enforcement-eligible capacity. For a simultaneous cohort of $N_0$ unilateral exits with per-user weight $e$, the minimum quiet time to clear is $L_{\min} \approx \frac{N_0 e}{\rho \cdot \bar c(f^*,P)}$ blocks. If $L_{\min} > W'$, users strictly fail to enforce.
\end{lemma}
\section{Bounds and The Insolvency Horizon}
\noindent\textbf{Constraint 1 (Market-Clearing Limit).} $\sum N_i e_i \leq \rho (4{,}000{,}000 - w_{cb}) \times W'$ wu.
\medskip
\noindent\textbf{Lemma (Disjointness).}\label{lem:disjointness} Under the proposed V3 topology (BIP-431) \cite{bip431}, for each user $u$, let $\Pi_u$ be the minimal enforcing transaction set. If $u \ne v$, then $\Pi_u \ne \Pi_v$. Specifically, valid unilateral enforcement requires a distinct spendable leaf or path, ensuring that each user contributes at least $w_{\mathrm{leaf,min}} > 0$ bytes. Perfect batching without custody is impossible once those limits are enforced.
\begin{proof}[Proof sketch]
V3 packages restrict ancestor/descendant relationships to 1P1C, so every unilateral spend must anchor to exactly one parent and cannot share descendants mid-flight. Taproot- or script-path commitments embed user-specific keys or CSV delays; if two users shared the same leaf, either one could burn the other by racing an alternative control block, contradicting the definition of credible exit. Therefore each $\Pi_u$ must contain at least one unique leaf (or key path) plus a chain of parent transactions reserved for that user, making $\Pi_u \cap \Pi_v = \varnothing$ for $u \ne v$. The total byte cost is additive across users, establishing the lemma.
\end{proof}
\begin{remark}[Current deployments]
Mainnet nodes that still run legacy ancestor/descendant limits instead of 1P1C observe the same lower bound only as a best-effort heuristic; enforcing BIP-431 semantics eliminates the edge cases where overlapping packages could reduce per-user cost.
\end{remark}
\paragraph{Relation to batching proposals.}
Channel factories \cite{factory}, Ark-style timeout trees \cite{ark}, and BitVM rollups \cite{bitvm} amortize coordination overhead by sharing roots or pre-signed branches, but their unilateral pathways still terminate in user-specific leaves; factories fall back to per-channel commitments, Ark users receive individually timelocked claims, and BitVM participants obtain per-slot exit proofs. The lemma therefore applies so long as (i) users retain unilateral control over their spendable outputs and (ii) coordination parties do not take custody of aggregate balances. Constructions that offer ``perfect batching'' do so by relaxing (i) or (ii)---for example, by granting an operator the authority to reorder exits or reuse leaves---and consequently step outside the non-custodial threat model studied here.
\medskip
\noindent\textbf{Constraint 2 (1P1C Packing).}
For a tree structure with branching factor $T$, root weight $w_{\mathrm{root}}$, and average per-package users $\bar{u}$, the per-user cost is:
\small
\begin{equation*}
e \;\ge\; w_{\mathrm{leaf}} + \frac{w_{\mathrm{branch}}}{\bar{u}} + \frac{w_{\mathrm{root}}}{T} + m.
\end{equation*}
\normalsize
Under 1P1C (One-Parent-One-Child) topology, $\bar{u}=1$, rendering branch amortization impossible within a single package.
\medskip
\noindent\textbf{Proposition 1 (Economic Insolvency / Death Spiral).}
The market clearing feerate $f^*$ is monotone increasing with user demand density $N/W'$. As $N \to C_{\max}/e$, $f^*$ rises asymptotically.
Consequently, the minimum viable balance $v_{\min}$ scales with $N$. A \emph{Security Cliff} exists where $v_{\mathrm{user}} < v_{\min}(N)$.
\section{Instantiations}
\subsection{Lightning: Heterogeneity and State}
Exit in Lightning is not merely the commitment transaction. The weight $e$ depends heavily on channel state (active HTLCs vs. idle). Furthermore, the window $W'$ is not fixed but determined by the user's chosen \texttt{to\_self\_delay}.
\paragraph{Weight Calculation.}
The effective weight $e_{\mathrm{LN}}$ is:
\small
\begin{equation*}
e_{\mathrm{LN}}(h) \approx 590 + 141 \times h \ (\text{vB}).
\end{equation*}
\normalsize
\begin{itemize}
\item \textbf{Idle State ($h=0$):} $e_{\mathrm{idle}} \approx 590$ vB (2360 wu).
\item \textbf{Active State ($h=4$):} $e_{\mathrm{active}} \approx 1154$ vB (4616 wu). Includes 4 pending HTLCs requiring second-stage claims.
\end{itemize}
\paragraph{The Blended Model.}
We define two user cohorts:
\begin{itemize}
\item \textbf{Cohort A (Retail/Standard):} $W'_{\mathrm{LN}} \approx 137$ blocks ($\sim$1 day).
\item \textbf{Cohort B (Institutional/LSP):} $W'_{\mathrm{LN}} \approx 2000$ blocks ($\sim$2 weeks).
\end{itemize}
System capacity is derived as:
\small
\begin{equation*}
N_{\max}^{\mathrm{LN}} \;=\; \left\lfloor \frac{\rho \cdot C_{\max}(W'_{\mathrm{LN}})}{e_{\mathrm{LN}}(h)}\right\rfloor.\label{eq:nmax}
\end{equation*}
\normalsize
\subsection{Ark-like (Timeout Trees)}
Assuming a binary tree topology ($T=2$) and covenant emulation (no new opcodes). Per-user cost breakdown: Leaf claim ($\approx$ 280vB) + Prorated Branches ($\approx$ 220vB) + Prorated Root ($\approx$ 100vB).
Base $e \approx 660$ vB (2640 wu). With coordination overhead $\delta_0$ (anchors for pinning protection), $e_{\mathrm{comp}} \approx 3200$ wu.
\section{Quantitative Ceilings}
In previous versions, we assumed $\rho=1$ and homogeneous usage. Here we present a robust operational model accounting for friction and policy choices.
\subsection{Sensitivity to Friction ($\rho$)}
Table 1 demonstrates that in a hostile environment (e.g., ``Flood \& Loot'' where $\rho \to 0.5$), the safe capacity of the network degrades significantly. This assumes a standard 137-block window.
\begin{table}[h]
\centering
\caption{Sensitivity of Exit Capacity to Network Friction ($\rho$) [Active Users]}\label{tab:rho}
\begin{tabular}{ccccc}
\toprule
Scenario & $\rho$ Value & Interpretation & Capacity (Active) & Capacity (Idle) \\
\midrule
Theoretical Max & 1.00 & Perfect packing & 118,658 & 232,087 \\
High Efficiency & 0.90 & Minimal RBF & 106,792 & 208,878 \\
\textbf{Typical Congestion} & \textbf{0.70} & \textbf{Standard RBF wars} & \textbf{83,060} & \textbf{162,460} \\
Hostile / Attack & 0.50 & Heavy pinning & 59,329 & 116,043 \\
\bottomrule
\end{tabular}
\footnotesize{\\ \emph{Note: Active users assumed to have 4 HTLCs ($e=4616$ wu). Idle users have 0 HTLCs ($e=2360$ wu).}}
\end{table}
For Table~\ref{tab:rho} we apply Equation~\eqref{eq:nmax} with $W'=137$, $w_{cb}=2{,}000$ wu, and the per-state weights above. Each row replaces only the efficiency coefficient: $N_{\max} = \lfloor \rho \cdot (4{,}000{,}000 - 2{,}000) \cdot 137 / e \rfloor$. For example, the ``Typical Congestion'' entry sets $\rho=0.7$, yielding $N_{\max}^{\mathrm{active}} = \lfloor 0.7 \cdot 547{,}726{,}000 / 4{,}616 \rfloor = 83{,}060$ and $N_{\max}^{\mathrm{idle}} = \lfloor 0.7 \cdot 547{,}726{,}000 / 2{,}360 \rfloor = 162{,}460$. Recomputing with other $\rho$ values reproduces the remaining cells.
\subsection{Policy & State Scenarios}
Table 2 illustrates the ``Security Slope.'' Higher throughput is physically possible, but strictly contingent on users accepting longer lock-times ($W'$) or maintaining lower activity levels (Idle state).
\begin{table}[h]
\centering
\caption{System Limits by Policy ($W'$) and Network State ($\rho=0.8$)}\label{tab:policy}
\begin{tabular}{ccccc}
\toprule
Scenario & Avg Window ($W'$) & Network State & Effective $N_{\max}$ & Notes \\
\midrule
\textbf{Retail Panic} & \textbf{1 Day} (137 blk) & \textbf{Active} & \textbf{94,926} & Stress: short locks + high activity \\
Quiet Exit & 1 Day (137 blk) & Idle & 185,669 & Typical: dormant channels \\
Mixed Economy & 3 Days (432 blk) & 50/50 Mix & 396,132 & Planning: blended 50/50 mix \\
\textbf{Institutional} & \textbf{2 Weeks} (2016 blk) & \textbf{Active} & \textbf{1,396,874} & Policy: LSP 2-week \texttt{CSV} \\
\bottomrule
\end{tabular}
\end{table}
The rows in Table~\ref{tab:policy} reuse Equation~\eqref{eq:nmax} but vary both the window $W'$ and the population mix. ``Retail Panic'' fixes $W'=137$, $\rho=0.8$, and $e=4{,}616$ wu, producing $\lfloor 0.8 \cdot 547{,}726{,}000 / 4{,}616 \rfloor = 94{,}926$. ``Quiet Exit'' simply substitutes $e=2{,}360$ wu. ``Mixed Economy'' blends the per-user weight across a 50/50 active/idle split at $W'=432$ blocks: $e_{\mathrm{mix}} = 0.5 \cdot 4{,}616 + 0.5 \cdot 2{,}360 = 3{,}488$ wu, so $N_{\max} = \lfloor 0.8 \cdot (4{,}000{,}000 - 2{,}000) \cdot 432 / 3{,}488 \rfloor = 396{,}132$. ``Institutional'' extends the window to 2{,}016 blocks with the active-state weight, giving $\lfloor 0.8 \cdot (4{,}000{,}000 - 2{,}000) \cdot 2{,}016 / 4{,}616 \rfloor = 1{,}396{,}874$. These examples allow independent reproduction of every entry.
\paragraph{Scenario provenance.}
Each row in Table~\ref{tab:policy} is an explicit scenario analysis rather than a measured distribution. The 1-day window reflects the median \texttt{to\_self\_delay} observed in ACINQ's public Lightning telemetry report (144 blocks) \cite{acinqTelemetry}, while the 2-week window mirrors LSP recommendations for high-value channels \cite{Law2023}. The ``Retail Panic'' and ``Mixed Economy'' rows are stress tests that bracket the 40--60\% idle-channel range measured by mass-exit simulations \cite{sguanci2022}; ``Quiet Exit'' is labeled as the typical dormant-channel case. Because no global dataset discloses exact state mixes, we explicitly declare these assumptions so reviewers can substitute alternative ratios without modifying Equation~\eqref{eq:nmax}.
\section{Implications: The Security Slope}
The theorems and quantitative ceilings established herein demonstrate the inherent limitations of layered scaling. However, rather than a single ``Cliff,'' we observe a **Security Slope** defined by three zones:
\begin{enumerate}
\item \textbf{Zone 1 (Safe): $N < 83,000$.} Below this threshold, unilateral exit is credible even under hostile conditions ($\rho=0.7$) for active users with short windows.
\item \textbf{Zone 2 (Probabilistic): $83,000 < N < 232,000$.} In this zone, safety depends on efficiency. Users are safe only if the network is non-hostile ($\rho \to 1$) or if their channels are idle.
\item \textbf{Zone 3 (Insolvent): $N > 232,000$.} Beyond this point, for a 1-day window, users are mathematically precluded from guaranteed unilateral enforcement.
\end{enumerate}
\begin{remark}[The Scorched Earth Limit]
Game-theoretic defenses (e.g., ``Scorched Earth'' fee bidding) fail if $N$ enters Zone 3. Honest transactions are physically excluded regardless of the fee bid. Furthermore, against subsidized attackers (e.g., state actors), cost-based deterrence is irrelevant.
\end{remark}
\begin{itemize}
\item \textbf{Trade-off:} There is no ``infinite scaling'' without trust. Scaling $N$ requires proportionally scaling $W'$ (time) while maintaining comparable $\rho$, or else accepting custody.
\item \textbf{Insolvency Horizon:} Users with balances $v < v_{\min}(N_{\max})$ forfeit their funds during congestion.
\item \textbf{Unique Footprint:} Zero bytes implies custody.
\end{itemize}
\begin{thebibliography}{99}
\bibitem{lightning} J. Poon and T. Dryja.
\emph{The Bitcoin Lightning Network}. 2016. \url{https://lightning.network/lightning-network-paper.pdf}
\bibitem{factory} C. Decker, R. Russell, and O. Osuntokun.
\emph{Channel Factories}. 2018. \url{https://lightning.network/channel-factories.pdf}
\bibitem{harrisZohar} J. Harris and A. Zohar.
\emph{Flood \& Loot: A Systemic Attack On The Lightning Network}. AFT, 2020. \url{https://arxiv.org/abs/2006.08513}
\bibitem{riardNaumenko} A. Riard and G. Naumenko.
\emph{Time-Dilation Attacks on the Lightning Network}. 2020. \url{https://arxiv.org/abs/2006.01418}
\bibitem{sguanci2022} C. Sguanci et al.
\emph{Mass Exit Attacks on the Lightning Network}.
ICBC, 2022. \url{https://arxiv.org/abs/2208.01908}
\bibitem{Easley2019} D. Easley et al.
\emph{From Mining to Markets}. J. Fin. Econ, 2019. \url{https://doi.org/10.1016/j.jfineco.2019.03.004}
\bibitem{Law2023} J. Law.
\emph{Scaling Lightning With Simple Covenants}. 2023. \url{https://github.com/JohnLaw2/ln-scaling-covenants}
\bibitem{ark} Burak. \emph{Ark: A Layer 2 Protocol for Bitcoin}.
2023. \url{https://mailing-list.bitcoindevs.xyz/bitcoindev/345972294.3114897.1686144607871@eu1.myprofessionalmail.com/T/}
\bibitem{deckerTowns} A. Towns and C. Decker.
``An overview of the cluster mempool proposal,'' Delving Bitcoin, 2024. \url{https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393}
\bibitem{bip431} G. Sanders.
BIP-431: Topology Restriction for Transaction Pinning. \url{https://github.com/bitcoin/bips/blob/master/bip-0431.mediawiki}
\bibitem{mempoolspaceWeight} mempool.space Research Team.
\emph{Mining Pool Template Audit}. 2025. \url{https://mempool.space/mining/pools}
\bibitem{policyMatrix} Bitcoin Core Developers.
\emph{Policy Documentation}. 2024. \url{https://github.com/bitcoin/bitcoin/blob/master/doc/policy.rst}
\bibitem{mempoolspace} mempool.space Research Team.
\emph{Mainnet Snapshot: 5 Oct 2025}. 2025. \url{https://data.mempool.space/snapshots/mainnet-2025-10-05T00:00Z.tar.gz}
\bibitem{mempoolobserver} mempool.space.
\emph{mempool-observer Toolkit}. 2024. \url{https://github.com/mempool/mempool/tree/master/observer}
\bibitem{kleinrock} L. Kleinrock.
\emph{Queueing Systems, Volume I: Theory}. Wiley, 1975.
\bibitem{little} J. D. C. Little.
\emph{A Proof for the Queuing Formula $L=\lambda W$}.
1961. \url{https://pubsonline.informs.org/doi/10.1287/opre.1110.0976}
\bibitem{bitvm} R. Linus.
\emph{BitVM: Compute Anything on Bitcoin}. 2023. \url{https://bitvm.org/bitvm.pdf}
\bibitem{acinqTelemetry} ACINQ Research.
\emph{Lightning Network Telemetry Q3 2025}. 2025. \url{https://acinq.co/blog/lightning-network-telemetry-q3-2025}
\end{thebibliography}
\end{document}