marketing

NOTES-alt.md (14866B)

---

 # Speaker notes and sources — dg-fisma-2026-alt
 
 The **alternative** deck, for the case where DG FISMA turns out to want GNU
 Taler and the NGI TALER technical results rather than the Digital Euro
 Regulation.  Decide which deck to run in the first two minutes of the meeting;
 `dg-fisma-2026` is the other one.
 
 21 slides, ~20 minutes.  Slide 19 ("Where this touches your files") is the
 bridge: if the room pulls towards the digital euro, switch decks there.
 
 Everything below was checked against primary sources in October 2026.  Several
 claims that circulate in our own older decks **do not survive checking** — the
 "Do not say" list at the end is not hypothetical, it is a list of things we
 have actually been putting on slides.
 
 ---
 
 ## Slide 2 — What GNU Taler is
 
 - "In development since 2015": first commit in `exchange.git` is 2015-01-08
   ("initial import for mint").  `taler-typescript-core` starts 2015-11-25.
 - "Over a million lines across some twenty repositories": counted over
   exchange, merchant, taler-typescript-core, libeufin, anastasis, sync, donau,
   challenger, taler-android, taler-ios, taler-docs — ~1.54m lines of
   `.c/.h/.ts/.kt/.java/.py/.swift/.rs/.sql/.js`.  Conservative phrasing on
   purpose; do not quote a precise figure.
 
 ## Slide 3 — Three operations
 
 - The point the draft trilogue deck got wrong: **the exchange detects
   double-spending, not the merchant.**  If anyone in the room has seen that
   deck, this is the correction.
 
 ## Slide 5 — The engine
 
 - Withdrawal blinding is information-theoretic.  **Refresh is not** — per D5.3,
   an exchange or eavesdropper without a quantum computer could link a dirty
   coin to its refreshed derivative in exponential time.  Do not claim
   information-theoretic unlinkability for the whole protocol.
 
 ## Slide 6 — Asymmetric privacy
 
 - Tinn, *Management Science*, 2025, on asymmetric privacy being
   welfare-optimal.  Same citation as in the other deck.
 
 ## Slide 7 — Who gets what out of it
 
 - Structure borrowed from Tanja's ECB deck of 16 April 2026 (customer /
   merchant / government benefits, each with a "things to note" caveat).  Keep
   the caveat line: it is what makes the rest credible.
 
 ## Slide 9 — Age restriction
 
 - Özgür Kesim, Christian Grothoff, Florian Dold, Martin Schanzenbach,
   *Zero-Knowledge Age Restriction for GNU Taler*, **ESORICS 2022**, LNCS,
   DOI 10.1007/978-3-031-17140-6_6.  **CHECK** the volume number and page range
   against Springer before printing a full bibliographic entry.
 - Design document DD 24, `Implementation status: Implemented`.  Implementation
   evidence: exchange 2022-03-01 and 2022-03-28, wallet 2022-04-19.  Shipped in
   the normative exchange protocol (`WithdrawRequest.max_age`,
   reveal-withdraw); test vectors published in
   `exchange/src/util/tv_age_restriction.json`.
 - Mechanism: the age commitment is a vector of M Edx25519 public keys;
   restricting to group *m* means withholding the private keys for slots > *m*.
   Bound to the coin by signing `FDH(C_p, h_Q)` under the denomination key.
   Refresh carry-over is enforced by cut-and-choose, so a cheat succeeds with
   probability 1/κ.
 - **Honest caveat, say it if asked:** implemented but **not switched on in any
   deployment** — it is an exchange-operator opt-in, and DD 24 notes the
   operator must then stick with the decision.  The open question is legal
   recognition of a cryptographic attestation in place of an ID check, which is
   exactly the thing this room could move.
 
 ## Slide 10 — Subscriptions and discounts
 
 - **Merged in `merchant` master**, not a branch — correct this if you have said
   otherwise before.  Normative since merchant protocol **v21**; token
   fountains since **v43**; current implemented version v44.  Provisioned in
   the reference demo deployment (`sandcastle-ng`).
 - Mechanism: wallet generates an EdDSA key pair per token, blinds the public
   key, merchant blind-signs with the token-family key (RSA or Clause-Schnorr).
   Redemption = unblinded issue signature + a signature under the token key.
   Double-spend caught by a spent-token registry
   (`merchant_do_insert_spent_token`).
 - **Do not over-claim:** each token is **one use**.  A twelve-month
   subscription is twelve tokens.  "One credential, unlimited unlinkable uses"
   is not the design.
 - Still unmerged: the wallet UI (DD 94, Partial) and declarative semantic token
   families (DD 101, Experimental/Prototype).  Asset or share tokens (DD 100)
   are **Not started** — do not mention them as existing.
 - Sources: `taler-docs/core/api-merchant.rst`,
   `core/merchant/post-private-tokenfamilies.rst`,
   `exchange/src/include/taler/taler_crypto_lib.h` ("Token crypto primitives").
 
 ## Slide 11 — Donau
 
 - Donation Authority operated by or on behalf of the tax authority; holds the
   register of recognised charities and their yearly volume limits.
 - Donor identifier `DI = H(TAXID, S)` with a secret salt `S`.  Per-unit
   blinded `UDI` pairs are signed by the charity, verified and blind-signed by
   the Donau.  At year end the donor submits the receipts and receives one
   Ed25519 statement over `(DI, total, year)`; the validator recomputes
   `H(TAXID, S)` from the salt the donor supplies.
 - So: the charity never learns who gave; the authority never learns which
   charity received which donation, and never sees `TAXID` itself.
 - **Timing caveat** the paper itself raises: receipts must not be submitted at
   a time strongly correlated with the donation, or the unlinkability between
   issuance and submission weakens.  Know this; do not volunteer it.
 - Status: service implemented (protocol v2), Debian-packaged, merchant
   integration merged, stood up in the reference deployment.  Wallet-side
   partial.  **No tax authority runs one.**
 - **CHECK before citing:** the paper in `donau/doc/usenix-security-2025/` is an
   anonymised submission draft with open TODOs — **do not say "published at
   USENIX Security 2025"**.  Safe: "documented in a peer-review submission and
   in NGI TALER deliverable D3.4", or cite the BFH thesis.
 
 ## Slide 12 — Paivana
 
 - `paivana-httpd`: an HTTP reverse proxy gating a target site behind a Taler
   payment.  Prices come from merchant templates whose POSIX regex is matched
   against the whole URL.  Unpaid visitors get a Mustache paywall page; after
   payment the proxy sets a keyed-hash access cookie over (expiry, website,
   client address) and streams the upstream response.
 - The paywall page carries a `Paivana` HTTP header "to also facilitate agentic
   payments" — that is the basis for the AI-agent claim, and it is the whole of
   it.  Do not inflate it.
 - **Do not repeat the Paivana marketing claims** that circulate elsewhere —
   "audited by Swiss Regulator", "~100,000 TPS", "150,000 users", a "$3–5T
   market".  They are unsourced or contradicted by project documents.  This is
   why Paivana is absent from the other deck.
 
 ## Slide 13 — Oral Information Management
 
 - Freetown, 2025: 21 women, 6 local languages; 4 had completed primary school;
   6 could read a five-digit ordinal number.  After a 24-hour gap, 8 tasks:
   16 completed all 8 with no errors, 4 with two tries and no help, 1 did not
   complete.  Joint work with MyOralVillage (myoralvillage.org).
 - Source: `marketing/presentations/comprehensive/oim.tex`, reused in the
   lugcamp and interledger decks.
 
 ## Slide 14 — Offline
 
 - Partially offline (merchant offline, customer online, OTP from the PoS key)
   is implemented and used for vending; see Huang et al., SUERF 2023, and
   `comprehensive/offline.tex`.
 - The CAP argument and the hardware-vulnerability timeline are the same
   material as slides 8–9 of the other deck.  If this room wants the timeline,
   switch decks — it is a whole slide there.
 
 ## Slide 15 — Anastasis
 
 - Core secret encrypted under a master key; master key split across an open set
   of escrow providers under a user-chosen policy; recovery by authentication
   challenges (security question, SMS, video ID, IBAN transfer).  Works without
   the user remembering anything of high entropy.
 - Source: `anastasis/doc/anastasis.texi`, §Introduction and §Adversary models.
 - Status: provider backend, client libraries, CLI and GTK app implemented.  Do
   not claim a production provider network.
 
 ## Slide 16 — Post-quantum
 
 **Tanja wrote the source document.  Let her own this slide and the Q&A on it.**
 
 - D5.3, *Impact of Quantum Computers on GNU Taler for WP5*, Tanja Lange and
   Jonathan Levin, rev. 1.0, 28 November 2024, EU ref. Ares(2024)8484648,
   public.  Local copy:
   `taler-www/static/presentations/d5.3-ngi-ImpactOfQuantumComputersOnTaler.pdf`.
 - The quoted assessment, verbatim: *"The protocols in GNU Taler exclusively use
   factoring- and discrete logarithm-based public key cryptography.  This means
   that the cryptographic protocols in GNU Taler are very susceptible to attacks
   with a quantum computer."*
 - The two clocks: forging denomination keys needs a quantum computer **at
   attack time** (D5.3: "not currently considered particularly severe");
   refresh/linking ECDH allows **retroactive deanonymisation** from a database
   obtained later, which D5.3 calls *"a severe vulnerability … that requires
   fixing long before quantum computers arrive"*.
 - The dual-use obstacle, D5.3 §3.5: *"Among the currently proposed post-quantum
   signature schemes, none innately has this dual-use property."*
 - The candidate: Beullens, Lyubashevsky, Nguyen, Seiler, ACM CCS 2023 —
   ~22 kB signature, two round trips, versus 256 bytes for RSA-2048 blind
   signatures today.  D5.3 itself gives no sizes; these are from the paper.
 - Project self-assessment, `2026-pqc/pqc.tex`: inventory **done**; alternative
   refresh formulation **done (\*)**, where the asterisk is *"suitable
   constructions exist, but currently available primitives introduce additional
   limitations implementations have to work around"*; primitive recommendations
   **work in progress**; *"no standard implementations exist"* for the required
   blinding and k-unique signatures.  Estimated 18–24 months, ≈€750k.
 - **CRITICAL — do not say "PQ refresh is implemented".**  DD 62 (PQ refresh) is
   `Design status: Superseded`, superseded by exchange protocol v32, which uses
   ECDHE transfer public keys.  Shipped code at exchange HEAD
   (`src/util/crypto.c`) calls `GNUNET_CRYPTO_ecdh_eddsa()`.  **Pre-quantum
   Curve25519 is what runs today.**
 - Clause-Blind-Schnorr is **also** pre-quantum.  It is not a hedge.
 
 ## Slide 17 — Where it runs, and what is built
 
 - **eNetzbon**, Basel, since 2024, through the Cyclos adapter
   (`taler-rust/adapters/taler-cyclos`).  **No merchant, user or volume figure
   is sourced anywhere** — do not quote one.  Note D2.1 (May 2025) does not
   mention Netzbon at all.
 - **Taler Operations AG**: FINMA written confirmation of the sandbox exemption,
   December 2022 (applied September 2022); BankV Art. 6 ¶2; public deposits
   ≤ CHF 1m; VQF SRO membership since **7 March 2024** (GwG Art. 14).
   Operational limits: ≤ CHF 2,500/month and ≤ CHF 15,000/year per direction,
   ≤ CHF 1,000 per transaction.  Source: D2.1 Swiss Sandbox Report, 28 May 2025.
   The operator's own notice on taler-ops.ch, verbatim: *"Taler Operations is
   not supervised by the Swiss Financial Market Supervisory Authority
   (FINMA)."*  and *"Escrowed customer assets are not subject to deposit
   insurance but held in a segregated bank account."*
 - **First fiat merchants:** P15 CoNetWorking Space, Biel/Bienne, 6 January 2026
   (first shop to accept eCHF); be-bop.io, PVH Éditions and le Coffice from
   20 May 2026 via the be-BOP integration.
 - **Magnet Bank:** internal alpha.  Local decks give launch dates ranging from
   Q3'2025 through Q2'2027; **Magnet Bank itself has published none**, and its
   project page gives no timeline.  The EU grant period ends 30 November 2026,
   so a 2027 launch is after grant close — expect that question.
 - **Bank connectivity:** libeufin EBICS dialects are exactly
   `valiant, raiffeisen, postfinance, gls, maerki_baumann`; nexus-manual says
   tested with Postfinance (CHF), GLS (EUR), Raiffeisen (CHF), Maerki Baumann
   (CHF), Valiant (CHF).  Magnet Bank and Cyclos and Wise are **separate Rust
   adapters**, not libeufin.
 - **28,500 TPS:** Boss & Grothoff, *GNU Taler Scalability*, BFH BSc thesis,
   15 June 2022, on INRIA Grid'5000 (Dahu cluster, Grenoble; 32 nodes, 2×Xeon
   Gold 6130, 10 Gbps, partitioned PostgreSQL, 200 exchange processes).  Full
   end-to-end mix including refresh.  **Run at 1024-bit RSA** — the thesis says
   production would want ≥2048 and argues the gap is recoverable by switching
   Libgcrypt→OpenSSL, but that is an argument, not a measurement.  Hence
   "at reduced key sizes" on the slide; if pressed on production key sizes the
   honest answer is **unverified**.
 - ~2,000 TPS for Switzerland and ~100,000 TPS for a 500-million-person economy
   are **Giesecke+Devrient rules of thumb** from a private conversation,
   reported in the same thesis.  Not a measured requirement, not an NGI TALER
   KPI.
 
 ## Slide 18 — Roadmap
 
 - Taken from the project's own technical roadmap (lugcamp/interledger decks),
   minus anything the checks above contradicted.
 
 ---
 
 ## Do not say
 
 1. **"Post-quantum design"** unqualified, or "PQ refresh is implemented".
    DD 62 is superseded; running code is ECDH.  Correct phrasing exists in
    `2025-bis/bis.tex`: *"Post-quantum design (not fully implemented)"*.
 2. **"100,000 TPS capability"**, or that it was a project requirement.
 3. **"28,500 TPS on a single server"** or "using 2 servers" — both appear in
    our own decks (`2024-harbinger`, `2026-dielinke`) and both are wrong.  It
    was a distributed cluster, at 1024-bit keys.
 4. **"Regulated CHF"**, **"cleared by FINMA"**, **"audited by the Swiss
    regulator"** — all three appear in our decks.  FINMA confirmed the model
    falls *outside* licensing, which is the opposite of a clearance.
 5. **"3× in production in Switzerland"** — one of the three (LeFrancPaysan) is
    a prospect.  The honest count is two.
 6. Any **Netzbon** merchant, user or volume number.
 7. A **Magnet Bank launch date attributed to the bank**.
 8. Phrasing that makes GLS, Raiffeisen, Postfinance or Valiant sound like banks
    that offer Taler.  An integration means a Taler operator can hold an account
    there.
 9. **"Published at USENIX Security 2025"** for the Donau paper.
 10. Paivana's circulating marketing numbers.
 11. **"Without patents"** — one has since been filed on the offline design.
 
 ## Still to check before the meeting
 
 - ESORICS 2022 volume number and page range for the age-restriction paper.
 - Whether D5.4 (the second PQC report) has been submitted; D5.3 says it is the
   first of two.
 - Whether anything has been announced about Magnet Bank since the v1.4 release
   note of 4 February 2026.