From 5c312833e19d1e50331d8103e1b383080c7bd263 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Hern=C3=A2ni=20Marques?= Date: Sun, 19 Jul 2026 14:49:08 +0200 Subject: [PATCH] =?UTF-8?q?docs:=20=C2=A73b=20mint=205110/P0001=20with=20d?= =?UTF-8?q?ated=20landing=20withdraw=20examples?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Record recurring bank SQL 5110/P0001 as server-side (not mon/wallet), max-search fail band ~824k GOA, and same-day landing recent_withdraws that still show Giga/Mega explorer mints succeeded earlier. --- CLI-AUTOMATION-NOTES.md | 64 ++++++++++++++++++++++++++++++++++++----- 1 file changed, 57 insertions(+), 7 deletions(-) diff --git a/CLI-AUTOMATION-NOTES.md b/CLI-AUTOMATION-NOTES.md index 2f25122..953898f 100644 --- a/CLI-AUTOMATION-NOTES.md +++ b/CLI-AUTOMATION-NOTES.md @@ -67,15 +67,65 @@ Legend: | **Workaround** | Use `LADDER_STEPS≥5` (or higher) so random mids exist; treat zero / absolute-max / max-1-5110 as probes (soft `CEILING_REJECT` in mon ≥1.20.2). | | **Wanted** | Ladder plan docs: pin vs mid semantics; CLI structured error for amount-too-large / zero. | -### 3b. Higher withdraw amounts often fail at mint +### 3b. Mint fails with bank SQL `5110` / `P0001` (server-side; recurring) | | | |--|--| -| **Seen** | Classic GOA ladder high/random mids and ceiling pins — e.g. `GOA:747827072844319` → `FAIL_MINT` / `STOPPED … mint HTTP 500 { code :5110, … P0001 }`; same class of error on max / max-1. | -| **Area** | **bank** / **ops** | -| **Problem** | **Larger amounts** frequently hit bank/libeufin limits (HTTP 500, Taler **5110**, SQL **P0001**). Not specific to pin:max only — mid-high ladder steps fail the same way. Do not treat as wallet/`reserve_pub` when mint never succeeded. | -| **Workaround** | Expect failures above some live ceiling; use max-search / soft ceiling handling; keep mid-range rungs for real withdraw/confirm tests. | -| **Wanted** | Clear amount-too-large from bank (not opaque SQL 500); mon reports ceiling separately from hard fails. | +| **Seen** | **Several times** on GOA (`bank.hacktivism.ch`), classic ladder high/random mids + ceiling pins **and** max-search bisect — not a one-off. Same class of error across 2026-07 runs (magikoopa / mon ladder). | +| **Area** | **bank** (libeufin / taler-corebank + **Postgres**) / **ops** — **not** mon SQL, **not** wallet-cli at mint time | +| **Call site** | mon `POST ${BANK}/accounts/explorer/withdrawals` with `{"amount":"GOA:…"}` only. Wallet/exchange not involved until mint returns 200 + URI. | +| **Response** | HTTP **500**, body e.g. `{ code: 5110, hint: "Unexpected sql error with state P0001" }` | +| **Codes** | **`5110` = `BANK_UNMANAGED_EXCEPTION`** (“no known exception types captured the exception”). **`P0001`** = PostgreSQL SQLSTATE for application `RAISE EXCEPTION` (function/trigger), not a mon bug and not max_wire config alone. | +| **Config check** | Public `/config` still allows huge wires (`max_wire_transfer_amount` ≈ `GOA:4503599627370496.99999999`, `default_debit_threshold` same order). Failing mints are often **far below** that (e.g. ~Kilo-GOA). | +| **API mismatch** | Corebank docs: insufficient funds should be HTTP **409**. Getting **500/5110** means the bank is **leaking** an unmapped SQL error instead of a clean client error. | +| **Problem** | Live mint “ceiling” is **opaque and unstable**. Do **not** treat 5110 as wallet/`reserve_pub` failure when mint never succeeded. Do **not** assume “only absolute pin:max fails” — mid and max-search probes hit the same error. | +| **Workaround (mon ≥1.21)** | Soft `CEILING_REJECT` on 5110/P0001 (classic mids + max pins); **max-ladder** treats mint reject as too-high upper bound and bisects. Keep mid-range rungs for real withdraw/confirm tests. | +| **Wanted (bank)** | Map the SQL condition to a structured error (insufficient funds / amount too large / debit limit) — **not** `BANK_UNMANAGED_EXCEPTION`. Log full `RAISE` text server-side. | + +#### What max-search saw (example run, 2026-07-19) + +Ladder max-search log (magikoopa): + +| Time (local mon log) | Probe | Result | +|----------------------|-------|--------| +| (bisect) | lo ≈ **GOA:822256** (822.256 Kilo-GOA) | still treatable as success path / lower bound | +| probe ~24 | **GOA:824385** (824.385 Kilo-GOA) | mint **HTTP 500 / 5110 / P0001** → soft too-high | +| after | hi := **GOA:824385** | continues bisect | + +So the **live single-mint fail band** was ~**822–825 Kilo-GOA** in that run — **not** “only Tera/Peta pins”. + +#### Landing page shows **much higher** amounts actually gotten (same day) + +Public bank intro stats: `https://bank.hacktivism.ch/intro/stats.json` (and the HTML landing that consumes them). Snapshot **2026-07-19 ~14:47 CEST** (`generated_at_human`). + +**Explorer balance still enormous** (so this is not “pool empty” in the UI sense): + +| Field | Value (snapshot) | +|-------|------------------| +| `balance_explorer` | **4.5036 Peta-GOA** (`GOA:4503599627250215.32499924`) | +| cumulative `withdraws.total_amount` | **4.5036 Peta-GOA** (292 ops) | +| `withdraws.last_24h` | **3.2366 Peta-GOA** (45 ops) | + +**Dated single withdraws that *did* mint** (from `recent_withdraws`, account=`explorer`) — all **before** or around the ~824k fail band above: + +| When (CEST) | Amount (alt) | Raw | +|-------------|--------------|-----| +| **2026-07-19 14:19** | **1.9761 Giga-GOA** | `GOA:1976113563` | +| **2026-07-19 14:19** | **1.4495 Giga-GOA** | `GOA:1449489732` | +| **2026-07-19 14:26** | **201.636 Mega-GOA** | `GOA:201635991` | +| **2026-07-19 14:26** | **144.53 Mega-GOA** | `GOA:144530029` | +| **2026-07-19 14:29** | **3.4099 Mega-GOA** | `GOA:3409891` | +| **2026-07-19 14:29** | **1.8009 Mega-GOA** | `GOA:1800875` | +| **2026-07-19 14:42** | 822.256 Kilo-GOA | `GOA:822256` (matches max-search **lo**) | +| **2026-07-19 14:42** | 424.114 Kilo-GOA | `GOA:424114` | + +Same calendar day, **~1.5–2 hours earlier**, explorer successfully recorded **Giga-GOA** and **Mega-GOA** withdraws — orders of magnitude **above** the ~824k amount that later returned **5110/P0001**. + +**Takeaway:** landing/stats prove higher single withdraws were **possible and recorded**; the 5110 failure is **not** explained by “config max_wire forbids Kilo-GOA” or by the public explorer balance display. Ops should compare **landing `recent_withdraws` + `balance_explorer`** with mon mint 5110 times when filing bank bugs. + +**Earlier mon observations (same error class, larger pins):** classic ladder e.g. `GOA:747827072844319` → mint 500/5110/P0001; absolute max / max-1 ceiling probes — see also classic soft `CEILING_REJECT` and max-ladder hi bound. + +**Exchange intro (context, not the mint path):** `https://exchange.hacktivism.ch/intro/stats.json` — e.g. snapshot same day: `wire_in_amount` ~Peta-GOA scale, `withdraw_amount` ~`GOA:1.79e6` coin-side; bank landing is the right place for **explorer mint** history. --- @@ -287,7 +337,7 @@ If only a few changes land, these unlock the most automation: | ladder explorer | `read_secret` / EXP_PW_FILE | | stage maxima | bank `max_wire` + keys min denom | | force-select | multi-rpub try; soft-skip confirm; empty scrape → WARN not balance fail | -| higher amounts | mint 5110/P0001 common above live ceiling (§3b); classic soft `CEILING_REJECT`; max-ladder bounds hi; report uses alt_unit_names (Tera-GOA …) | +| higher amounts | mint **5110/P0001** recurring server-side (§3b); landing shows much larger **dated** explorer withdraws (Giga/Mega same day); soft `CEILING_REJECT` + max-ladder hi; alt units in report | | pay vs balance | never order more than wallet **available** (soft `SKIP_BALANCE`); pendingIncoming does not count as spendable | | pay wait UX | after withdraw, board lists OK/OK_BANK in **start order** with live wallet `pendingIncoming`/`done` + timer (`LADDER_PAY_WAIT_AVAILABLE_S`, default 90s); same wallet DB as withdraw | | wallet-db path | Prefer `*.sqlite3` (never `*.json` as db path) |