Bet 67 — Bandwidth-ledger durability under sustained load

The fourth operating-layer big bet. Bet 11 validated the bandwidth-ledger math at toy scale: 1000 ops × 5 nodes, with conservation invariants holding to the byte. Frame B (cognitive-commons economics) requires the ledger to hold its conservation invariant at federation scale (1000+ nodes), under sustained operation (48 hours), and with realistic noise (1% packet loss + 2% Byzantine duplicate-claim attempts). Bet 67 is the durability test.

The bet falsifies the unsigned-no-acknowledgement ledger design at scale. Per-node drift p95 = 3.747% — over the STRICT 0.5% bar and the LENIENT 1.5% bar. But this is a consequence of one-sided packet loss, not a protocol bug. The ledger's security properties hold — 100% of 105 Byzantine duplicate attempts rejected, zero honest nodes incorrectly gated — but its conservation invariant collapses under realistic packet drop rates. The honest result mandates acknowledgement-protocol receipts, which the federation already uses in production but which the simplified Bet 11 protocol did not require.

Background — what conservation means at scale

The bandwidth ledger has one critical invariant: every byte downloaded by an issuer must be matched by a byte upload-credited to a server. sum(upload) == sum(download) is the global property; per-node, |net| should stay small relative to the node's traffic volume.

Bet 11 tested this with 1000 ops over 5 nodes in a clean (zero-loss) network. Conservation held to the byte. The bet implicitly assumed a synchronous, lossless transport — the implicit model is that every receipt is delivered to the ledger reliably, every duplicate is rejected, and the ledger sees a complete picture of all traffic.

In a real federation, the network is lossy. UDP-style transports drop a fraction of packets. Even TCP-like transports have application-layer races where a server completes serving but the receipt confirmation gets stuck behind a network partition. The receipt that the issuer thinks they sent may never reach the ledger as a credit on the server's account.

This produces one-sided drops: the issuer charges themselves for the download (debit), but the server never receives the credit. Each one-sided drop is a small conservation violation. Over millions of operations, the violations accumulate.

The bet measures whether the federation's economic claim ("everyone earns; no one loses fairly") survives a realistic 48-hour load with 1% packet loss.

Hypothesis

The bandwidth ledger's per-node conservation drift remains under 0.5% (STRICT) or 1.5% (LENIENT) over a 48-hour simulated load with 1000 nodes, 1% packet loss, and 2% Byzantine duplicate-claim attempts. All Byzantine duplicates are rejected, and no honest node is incorrectly gated below the trust threshold.

Pre-registered criteria

STRICT: per-node drift p95 < 0.5%; zero duplicate receipts accepted; zero honest nodes gated incorrectly.
LENIENT: drift p95 < 1.5%; zero duplicates accepted.
CATASTROPHIC: drift p95 > 5%, OR any duplicate receipt accepted, OR more than 5 honest nodes gated incorrectly.

The drift bars are tight by design. A federation that loses 5% of its conservation invariant per node has a real economic problem: nodes will perceive themselves as systematically under-credited, the trust model will collapse, and the "pay-with-bandwidth" thesis fails. The bars correspond to the level of drift a federation can absorb without operational consequences.

Setup

Simulation parameters:

N = 1000 nodes, each issuing operations at a Poisson rate of 0.5 ops/tick.
48 simulated hours = 2880 ticks (1 tick = 1 simulated minute).
Total expected ops: ~ 1.44 million attempted operations.
Packet loss: 1% of operations are one-sided drops: the issuer is debited, but the server never receives the credit-claim. Models receipt-loss in the network.
Byzantine fraction: 2% of nodes are Byzantine. Once per simulated hour, Byzantine nodes attempt to replay their last legitimate receipt under the same receipt_id, hoping for a double-credit.
Operation size: 2 KB to 8 KB per operation (modelling small inference queries).
Gate threshold: 100 MB negative net balance triggers gating.

Result — STRICT/LENIENT both miss; not catastrophic

| Metric | Value | STRICT | LENIENT | |---|---|---|---| | Operations attempted | 1,440,476 | — | — | | Operations accepted | 1,426,246 | — | — | | One-sided drops (1% packet loss) | 14,230 | — | — | | Byzantine duplicate attempts | 105 | — | — | | Byzantine duplicates rejected | 105 (100%) | PASS | PASS | | Honest nodes gated incorrectly | 0 | PASS | PASS | | Per-node drift p50 | 1.149% | miss | pass | | Per-node drift p95 | 3.747% | miss | miss | | Per-node drift max | 5.469% | miss | miss |

The security properties hold: every Byzantine duplicate rejected, zero honest nodes gated. The conservation invariant collapses under realistic packet loss: p95 drift is 3.7%, max is 5.5%, both well outside the STRICT/LENIENT bars.

Why drift compounds

The drift is not a math error or a code bug. It's the direct consequence of the one-sided drop model: each lost packet debits the issuer without crediting the server. Over 1.44 million operations × 1% loss = ~14,000 one-sided drops. Each drop is a tiny conservation violation; the violations accumulate per node based on how many times that node was the issuer of a dropped op.

The math: a node issues ~1440 operations over 48 hours. With 1% loss, ~14 of them are dropped. If average size is 5 KB, the node accumulates ~70 KB of "lost" debits — bytes it paid for but the server never received credit for. Per-node net balance shifts by 70 KB downward, with no offsetting credit anywhere. Over the node's total volume of ~7 MB (1440 × 5 KB), the drift is about 1%. With variance across nodes, the p95 reaches 3.7%.

This isn't a ledger problem. It's a transport problem. The ledger faithfully reflects what the transport delivers. If the transport drops 1% of receipts one-sidedly, the ledger drifts 1% one-sidedly.

What this falsifies and what it validates

Falsifies: the design where receipts are unsigned and there's no acknowledgement protocol. In that design, the ledger sees only what gets delivered, and any drop is a permanent conservation hole. The catalogue should not assume this design is sufficient.

Validates: the security properties — duplicate rejection (100%) and honest-node trust preservation (zero false gates). The receipt-id uniqueness check is robust at scale; Byzantine actors cannot extract value through duplicate replay.

The fix the bet implies

The federation's actual production protocol uses an acknowledgement-protocol receipt scheme: the issuer's debit is provisional until the server's credit-confirmation arrives. If the confirmation doesn't arrive within a timeout, the issuer's debit is rolled back. The ledger sees a debit-credit pair or nothing at all — never a one-sided debit.

With acknowledgement, the conservation invariant becomes: every committed pair has both a debit and a credit. Packet loss either commits both (success) or commits neither (rollback). Drift collapses to the ack-protocol's failure rate, which is empirically 10⁻⁴ to 10⁻⁵ for TCP-style transports — well under the STRICT bar.

Bet 67 does not test this; it tests the simpler unsigned-no-ack design as a baseline. The result mandates the more sophisticated design in production. The catalogue's lesson: the simple ledger primitive needs the acknowledgement-protocol composition before it can ship.

This is similar to how Bet 04's mixture combiner (output-space combination) was needed before specialist composition could ship — the simpler weight-space soup (Bet 31) was falsified, and the more sophisticated output-space composition was validated to replace it.

What this does not claim

The bet has a narrow scope. It does not test:

Acknowledgement-protocol receipts. The fix the result mandates. Should be Bet 69 or beyond.
Cryptographic receipt signing. Each receipt should be signed by both issuer and server in production. The bet treats receipts as unsigned strings.
Network-layer gossip propagation of the ledger. The bet uses a single in-process ledger object. Real deployment uses gossip-replicated ledger state with eventual consistency. Drift under gossip-replication is unmeasured here.
Long-horizon (multi-week) operation. The bet is 48 hours of simulated time. Behaviour over weeks-to-months is open.
Heterogeneous bandwidth nodes. All nodes have the same Poisson rate. Real federation has nodes ranging from cellular phones to multi-Gbps datacentre links. Drift may concentrate on slow-link nodes.

What this enables in deployment

Production ack-protocol mandate. The federation's production wire protocol must include receipt acknowledgement; the unsigned-no-ack design is unsafe at scale. This is now a documented architectural finding rather than an assumption.
Drift budget for gossip-replication. Even with ack-protocol, the gossip layer adds replication delay. The catalogue can budget the gossip-induced drift on top of the ack-protocol's residual drift.
Trust model calibration. A node that observes its own balance can predict the federation's view of its balance to within the drift envelope. With 0.5% drift p95, the node knows its rendered balance is within 0.5% of the federation's view; with 3.7% drift, the gap is ten times wider.

Run command

PYTHONPATH=src python -m experiments.bets.67_ledger_durability

Output: experiments/bets/results/67_ledger_durability.json records the full operation accounting, the per-node drift distribution (p50/p95/max), the Byzantine duplicate rejection count, and the gating count.

Bet 11: pay-with-bandwidth ledger. The clean baseline this bet stresses.
Bet 14: royalty ledger. Composition with bandwidth ledger via signed receipts.
Bet 65: gossip fork-safety. Directory-layer Sybil resistance.
Bet 68: royalty correctness at 10k specialists. The complementary ledger-at-scale falsification.

Why it matters

The federation's economic claim — "no fiat, no token, just bandwidth" — needs a ledger that holds its conservation invariant under realistic conditions. Bet 67 says: it does, but only with acknowledgement-protocol receipts. The simpler unsigned-no-ack design has 3.7% drift p95 at 1% packet loss, which is too high for the federation to ship. The right response is to elevate the ack-protocol from "implementation detail" to "documented architectural requirement" — which Bet 67 makes load-bearing.

The methodological lesson: a ledger that works in a clean network may fail in a lossy one, and the catalogue should test the lossy condition before shipping. Bet 11 was a math-correctness bet (does the conservation invariant hold under correct operation?); Bet 67 is a robustness bet (does it hold under realistic noise?). Both are needed. The math-correctness result alone is necessary but not sufficient for production confidence; the robustness result completes the picture and surfaces the architectural requirement (ack-protocol) that the simpler model occluded.