# PP290 — Tables, abits and jbit flows

Jeffery Lyn Huckstead · Cerebral Graphix · 28 September 2026 · site release v3.3 · unpublished working note, no DOI assigned

Status words: **PROVED** (argument given here), **COMPUTED** (finite replayed checks with a receipt), **OPEN** (not established), **DESIGN** (a choice or proposal, not a result). Nothing here concerns the Riemann hypothesis. "Riemann" is the name of a published rule-based card player; RH STATUS: OPEN.

## 1. What v3.3 adds

1. **Poker 51 tables** (`/area-51/poker-51/table/`). Five-card draw for 2–5 people on the 51-card deck, played on a separate table service that deals, so no browser holds another player's cards. Tables are opened and shared by link. Players buy in with jbits and are paid out when they leave.
2. **Riemann at a table, with abits** (§3). Any seated player can add Riemann. It plays with abits matched to that player's stack, and it can neither win nor lose anyone's jbits.
3. **Blackjack 51 · two spots** (`/area-51/blackjack-51/table/`). Standard casino multi-spot procedure. Every hand is face up, so the second spot is visible before the first is played. With one spot, the new engine reproduces the unchanged classic engine v2.0.0 card for card.
4. **Table logs.** A hand history on the solo Poker and classic Blackjack pages, built from records those pages already keep, and on both new tables.

## 2. Table rules and the five-seat bound

Rules file: `area-51/poker-51/poker51-multi-v1.js` (`poker51-table-v1`). The same file runs in the page and in the service.

- **Ante and deal.** 1 jbit ante, five cards each.
- **Betting.** Two betting rounds with a draw of 0–5 cards between them. A round opens with a check or a bet of 1, 2, 4 or 8. Raises are by the opening amount, at most two per round. An all-in for less than a full raise does not reopen raising.
- **Showdown.** Exact side pots. Odd cents go in turn from the seat after the button. All hands are shown after the hand.

**Proposition 2.1 (PROVED).** With at most five seats the 51-card deck never runs out. *Proof.* Five hands use 25 cards. Each player replaces at most 5, so at most 25 more, making 50 ≤ 51. ∎

Replay: `tests/v3_3/verify-poker51-multi-v1.mjs`, **COMPUTED** over 20,000 seeded hands with 2–5 seats. It checks:

- exact conservation to the cent, and a payout identity for every player: payout = put − paid out + received;
- side pots against an independent exact fractional split, within the odd cents;
- the odd-cent order;
- no duplicate cards, 2♣ never dealt, byte-identical replays, and refusal of illegal moves.

Coverage includes:

| What | Hands |
|---|---|
| Side pots | 10,969 |
| Split pots | 1,244 |
| Incomplete all-in raises | 1,459 |
| Raise caps reached | 2,588 |
| Mid-hand leaves | 3,489 |

## 3. Abits

**Definitions.** Seats are humans (h) or Riemann (R). A human seat holds a *stack* s_h of jbits and *held* jbits e_h ≥ 0, which are jbits of h that R has won and holds for h. It also has an *abit score* a_h ≥ 0, which is shown but never bet. R holds a stack S_R of abits. When h adds R, S_R := s_h. After each hand the pot is paid contributor by contributor (the `flows` of the rules file). For each human h, let z_h be the chips R paid h, and y_h the chips h paid R. The ledger then applies:

- if y_h > z_h: e_h += y_h − z_h (h's stack has already lost those chips);
- if z_h > y_h: repay r = min(z_h − y_h, e_h), e_h −= r, move the rest x = z_h − y_h − r from s_h to a_h.

When R leaves, s_h += e_h, e_h := 0 and a_h := 0 for every h, and S_R vanishes. R leaves in four cases: it is removed, its spawner leaves, S_R < 1 jbit, or the table closes. A human who leaves is paid s_h + e_h.

**Theorem 3.1 (PROVED).** For every human h, at every moment between hands, s_h + e_h = buy-in_h + (chips h received from humans) − (chips h paid to humans). So each human's cash-out is their buy-in plus their net result against other humans, and R creates and destroys no jbits.

*Proof.* The quantity T_h = s_h + e_h starts at buy-in_h. Consider the effect of one hand on T_h.

- A flow between two humans changes their stacks by opposite amounts and touches no e.
- A net flow y − z > 0 from h to R lowers s_h by y − z in the chip settlement and raises e_h by the same amount. T_h is unchanged.
- A net flow z − y > 0 from R to h raises s_h by z − y in the chip settlement. The ledger then moves x of it from s_h to a_h and r of it from e_h into s_h, where x + r = z − y. So s_h ends up changed by z − y − x = r, e_h changed by −r, and T_h is unchanged.

When R leaves, e_h is added to s_h, which leaves T_h unchanged. So T_h changes only by human-to-human flows. The sum over humans of those flows is zero, so no jbits enter or leave the human side through R. ∎

**Corollary.** Against Riemann alone, a player ends every session exactly where they started. Their abit score records how they did, and then vanishes.

Replays, all **COMPUTED**:

- **Seeded sessions.** 1,500 seeded table sessions: 13,074 hands, 9,299 with Riemann, 2,287 Riemann departures and 585 mid-hand leaves. Every human's cash-out equals buy-in plus net against humans.
- **Two-hand fixture.** A player buys in with 10 jbits and Riemann gets 10 abits. Riemann wins 5 jbits from the player, which are held for them. The player then wins 1 jbit back, which is repaid from the held jbits. Removing Riemann restores 10 jbits.
- **Service tests and a local run.** The service's own tests exercise the same rule through the Worker and the Durable Object. A local `wrangler dev` run showed it too. A second player bought in with 4 jbits, won 4 from the tester and then lost all 8 chips to Riemann. It was paid out 8 jbits.

## 4. Trust model

- The table service (a Cloudflare Worker with one Durable Object per table) holds every hand, because it deals.
- Each browser receives only its own cards until the hand ends. **COMPUTED:** 154,498 views scanned in the seeded sessions, plus the service tests.
- Each deal is committed as SHA-256(salt:deck) before play. The salt and deck are published in the log afterwards, and any browser can recompute the hash.
- Seat tokens are 32 random bytes, stored only as hashes. Actions carry ids, so a repeated request changes nothing.
- **Not protected.** The jbit bank lives in each browser, so the service cannot verify that a buy-in was really paid. It caps a buy-in at 100 jbits. Jbits have no monetary value. This is a research table, not a secure casino.

## 5. Where jbits come from and go

The economy is per browser. Every movement has a receipt in the shared bank (`wallet-core-v2-0b3.js`).

| Flow | Rule | Direction |
|---|---|---|
| Opening bank | 8 jbits | source, once |
| Recovery timer | +1 per 5 min 10 s while bank + Finance holdings < 8 | source |
| Memory 51 recall | +2 per correct unassisted answer, up to 8 per UTC day | source |
| Solo Poker and classic Blackjack against Riemann | antes, stakes and payouts against a fixed dealer rule | sink on balance (the house side) |
| Blackjack odds view, next-hit call, Ⅰ peek | 1, 1 and 6 jbits | sink |
| Finance weather positions (√2 power tower) | see below | redistribution with a floor |
| Poker 51 tables, human against human | no rake | transfer, zero-sum |
| Riemann at a table | abits (§3) | neutral by Theorem 3.1 |

**Riemann's edge.** The v0.2 simulations found every tested strategy losing on average against the one-round v0.2 Riemann (**COMPUTED**, historical). Returns against the two-round v0.3 policy and at multi-player tables are **OPEN**.

**The tower is the fastest lever.** For a fresh Finance position, `finance-jbit-tower-v2_1_0.js` multiplies the stake by 1 + p on a rise and 1 − p on a fall, where p is the power tower of √2 of the index move in basis points, minus 1. **COMPUTED** from the shipped code:

| Index move | 1 bp | 2 bp | 3 bp | 5 bp | 10 bp | 20 bp |
|---|---|---|---|---|---|---|
| Rise | ×1.414 | ×1.633 | ×1.761 | ×1.893 | ×1.984 | ×2.000 |
| Fall | ×0.586 | ×0.368 | ×0.239 | ×0.107 | ×0.016 | ×0.000 |

Because m(x) + m(−x) = 2, the curve is neutral in expectation for a symmetric move; what it changes is spread. Within a few basis points most positions end near ×0 or ×2. **Argument, not measured (OPEN to measure).** Combined with the recovery timer, which refills a bank at zero but never trims one above 8, a neutral high-spread game should mint on balance. Losses are truncated and refilled; gains are kept. So the tower's leverage acts as a monetary lever as well as a game setting. Raising it widens the spread, and the timer then refills the losers at a flat rate.

**Known leak (DESIGN, recorded).** The v2.0b3 timer counts Finance holdings but not jbits sitting at a Poker table. While you play at a table it can refill your bank toward 8, just as it would if you had lost those jbits. The effect is bounded by the timer rate and the cap. The shared wallet modules were left unchanged in v3.3; a later wallet version can count table stacks as holdings.

## 6. A "Fed" view (DESIGN)

The right balance sheet compares jbits printed per hour (timer and recall) with jbits burned per hour, broken down by game (Riemann tables, Blackjack information prices, Finance positions closed below stake). Transfers (human tables) move jbits without changing the total and belong in a separate column. Every quantity already has a receipt source and kind in the bank, so a per-browser dashboard is a read-only report over `wallet.entries`. A site-wide view would need browsers to report, which v3.3 does not do. The table service could publish its own aggregate, which by §3 is transfers only.

## 7. A long-term regime: reserve on gains, delete on loss (DESIGN, OPEN)

Proposed in discussion: instead of letting money slosh between winners and losers, a market would hold back part of each gain in reserve and delete losses outright. Expected effects:

- **A deflationary bias at every settlement.** A settled prediction market is roughly zero-sum, so deleting losses and releasing gains only in part shrinks the supply.
- **Cooler speculation.** Being wrong costs the system, not only the loser, and the reserve works like a tax on turnover.
- **Pro-cyclical risk.** Money disappears fastest when many are wrong at once, exactly when liquidity is scarcest. This is the opposite of a central bank's response in a panic, and it echoes Irving Fisher's debt-deflation spiral of the 1930s.
- **Hoarding.** Holding money gains value while wagering risks deletion, so circulation slows.

It therefore needs something that prints back: a floor, the timer, or reserves released slowly.

Area 51 is a safe place to try it. It could run as a transparent, opt-in regime in the Finance weather market, with the money supply and circulation shown on the §6 dashboard. Nothing of this is implemented in v3.3.

## 8. Open

1. Strategy returns at multi-player tables, and against the v0.3 two-round Riemann.
2. Whether Riemann's multi-player extensions are sensible; they are labelled design choices in `poker51-multi-riemann-v1.js`.
3. Counting table stacks as holdings in a future wallet version (§5).
4. Measuring the tower-plus-timer minting argument (§5) over real or simulated sessions.
5. A second person taking a Blackjack spot through the same table service.

## 9. Files and checks

- **Rules.** `area-51/poker-51/poker51-multi-v1.js`, `poker51-multi-riemann-v1.js`, `area-51/blackjack-51/blackjack51-table-v1.js`.
- **Service.** `services/table51/`: `src/worker.js`, `src/room.js`, `src/table-state.js`, `wrangler.toml`, `DEPLOY_TABLE_SERVICE.md`, `test/room.test.mjs`.
- **Pages.** `area-51/poker-51/table/`, `area-51/blackjack-51/table/`, `area-51/assets/table-log-v1.js`.
- **Checks, from the site root, with Node 20+ and no packages:**
  ```sh
  node tests/v3_3/verify-poker51-multi-v1.mjs
  node tests/v3_3/verify-blackjack51-table-v1.mjs
  node services/table51/test/room.test.mjs
  ```
  Receipts: `tests/v3_3/VERIFY_POKER51_TABLE_v1.json`, `tests/v3_3/VERIFY_BLACKJACK51_TABLE_v1.json`, `services/table51/test/ROOM_TEST_RECEIPT.json`. The Blackjack verifier compares 65,016 seeded one-spot rounds with the unchanged v2.0.0 engine and checks 20,000 multi-spot rounds.