commit 19ea93a7f41070379f36bb9b41b54fdffd8d8fe5
parent 6d9d165c36531f233959e059dd988ceaf8850171
Author: Christian Grothoff <christian@grothoff.org>
Date: Mon, 19 Oct 2026 22:31:14 +0200
b-slides
Diffstat:
8 files changed, 879 insertions(+), 27 deletions(-)
diff --git a/presentations/2026-dg-fisma/Makefile b/presentations/2026-dg-fisma/Makefile
@@ -1,19 +1,22 @@
-# Build the DG FISMA deck. Two pdflatex passes are required, otherwise the
+# Build the DG FISMA decks. Two pdflatex passes are required, otherwise the
# title page and the frame titles do not come out right (see README).
+#
+# dg-fisma-2026 -- the Digital Euro / trilogue briefing
+# dg-fisma-2026-alt -- the GNU Taler technology briefing
-DECK = dg-fisma-2026
+DECKS = dg-fisma-2026 dg-fisma-2026-alt
-all: $(DECK).pdf
+all: $(DECKS:=.pdf)
-$(DECK).pdf: $(DECK).tex taler-macros.tex
- pdflatex -interaction=nonstopmode $(DECK).tex
- pdflatex -interaction=nonstopmode $(DECK).tex
+%.pdf: %.tex taler-macros.tex
+ pdflatex -interaction=nonstopmode $<
+ pdflatex -interaction=nonstopmode $<
clean:
- rm -f $(DECK).aux $(DECK).log $(DECK).nav $(DECK).out $(DECK).snm \
- $(DECK).toc $(DECK).vrb
+ rm -f $(foreach d,$(DECKS),$(d).aux $(d).log $(d).nav $(d).out \
+ $(d).snm $(d).toc $(d).vrb)
distclean: clean
- rm -f $(DECK).pdf
+ rm -f $(DECKS:=.pdf)
.PHONY: all clean distclean
diff --git a/presentations/2026-dg-fisma/NOTES-alt.md b/presentations/2026-dg-fisma/NOTES-alt.md
@@ -0,0 +1,271 @@
+# 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.
diff --git a/presentations/2026-dg-fisma/NOTES.md b/presentations/2026-dg-fisma/NOTES.md
@@ -378,3 +378,33 @@ header wedge, which use TikZ `remember picture`).
Style is `taler-macros.tex` as used by 2026-pqc / 2026-rbi / 2026-dielinke.
`\SUB` appears in the footer of every slide and must fit on one line.
+
+---
+
+# Corrections applied October 2026 (after the deck was first drafted)
+
+- **"Live in Switzerland in regulated CHF, under the FINMA sandbox regime"**
+ → **"Live in Switzerland in CHF under the FINMA sandbox exemption — not
+ FINMA-supervised; AML through a recognised SRO".** The old wording
+ contradicted the "do not say" note already in this file. The operator's own
+ legal notice reads: *"Taler Operations is not supervised by the Swiss
+ Financial Market Supervisory Authority (FINMA)."* FINMA confirmed in
+ December 2022 that the business model falls *outside* licensing under BankV
+ Art. 6 ¶2 — the opposite of a clearance. SRO (VQF) membership since
+ 7 March 2024.
+- **"v1.5"** → **v1.6**, which is the current release.
+- **"28,500 transactions/s measured"** → **"measured at reduced key sizes"**.
+ The Grid'5000 experiments (Boss & Grothoff, BFH 2022) ran 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. If
+ pressed on production key sizes, the honest answer is unverified.
+- **"Hungary 2027 at the earliest"** → **"Hungary in internal alpha, with no
+ launch date announced"**. Our own decks carry launch dates from Q3'2025 to
+ Q2'2027; Magnet Bank has published none, and its project page gives no
+ timeline. Note the EU grant period ends 30 November 2026.
+- Layout: on the "Asymmetric privacy answers AML" slide the two closing
+ bullets were being typeset inside the right-hand column, so they read as a
+ continuation of the "Payee" list. They are now a full-width paragraph.
+
+See NOTES-alt.md for the full sourcing behind these, and for the further
+"do not say" items that came out of the same round of checking.
diff --git a/presentations/2026-dg-fisma/README b/presentations/2026-dg-fisma/README
@@ -1,8 +1,22 @@
-Slide deck for the NGI TALER briefing to DG FISMA (European Commission)
-on the Digital Euro Regulation, October 2026.
+Slide decks for the NGI TALER briefing to DG FISMA (European Commission),
+October 2026. Two decks, because the purpose of the meeting is ambiguous:
-Build with "make" (or run pdflatex twice by hand -- a single pass does not
-lay out the title page and frame titles correctly).
+ dg-fisma-2026 The Digital Euro Regulation. Makes the case that the
+ trilogue is negotiating policy constraints on data the
+ architecture collects anyway, and ends with four asks for
+ the compromise text plus one for the pilot.
-NOTES.md records the sources behind every factual claim on the slides, and
-flags the claims that still need to be checked before the deck is presented.
+ dg-fisma-2026-alt GNU Taler and the NGI TALER technical results, with no
+ digital-euro argument. Use this one if the room turns
+ out to want to learn about the project rather than to
+ discuss the Regulation.
+
+Decide which to run in the first two minutes. Slide 19 of the alt deck
+("Where this touches your files") is the bridge back to the other deck.
+
+Build both with "make" (or run pdflatex twice by hand -- a single pass does
+not lay out the title page and frame titles correctly).
+
+NOTES.md and NOTES-alt.md record the sources behind every factual claim, and
+each carries a "do not say" list of claims that circulate in our own older
+decks but do not survive checking.
diff --git a/presentations/2026-dg-fisma/dg-fisma-2026-alt.tex b/presentations/2026-dg-fisma/dg-fisma-2026-alt.tex
@@ -0,0 +1,532 @@
+\documentclass[aspectratio=169,t]{beamer}
+\input taler-macros
+\usepackage{eurosym}
+\usepackage{array}
+
+\newcommand{\TITLE}{NEXT \\ GENERATION \\ INTERNET}
+\newcommand{\SUB}{GNU Taler: technology and results}
+\newcommand{\AUTHOR}{Tanja Lange, Christian Grothoff, Leon Schumacher}
+\newcommand{\SPEAKER}{Lange, Grothoff, Schumacher}
+\newcommand{\INST}{NGI TALER}
+\newcommand{\DATE}{\\ \ \vspace{0.5cm} \\ October 20\textsuperscript{th} 2026}
+
+% Do not edit this part
+\title{\TITLE}
+\subtitle{\SUB}
+\date{\DATE}
+\author[\SPEAKER]{\AUTHOR}
+\institute{\INST}
+
+\begin{document}
+
+\begin{frame}[plain]
+\maketitle
+\end{frame}
+
+
+% ----------------------------------------------------------------------
+\begin{frame}{What GNU Taler is}
+ \begin{minipage}{0.47\textwidth}
+ {\bf It is}
+ \begin{itemize}
+ \item Free software payment {\bf infrastructure}: wallets, merchant
+ backends, bank integrations
+ \item {\bf Digital cash} --- bearer tokens in an existing currency,
+ issued against a bank debit
+ \item A design where the {\bf payer is unlinkable} and the
+ {\bf payee is identified}
+ \end{itemize}
+ \end{minipage}
+ \hfill
+ \begin{minipage}{0.47\textwidth}
+ {\bf It is not}
+ \begin{itemize}
+ \item A currency, an asset, a store of value
+ \item A blockchain: no mining, no ledger, no consensus
+ \item Decentralised issuance --- that stays with a regulated
+ institution
+ \item One network: anyone may run an instance
+ \end{itemize}
+ \end{minipage}
+
+ \vfill
+ \begin{center}
+ {\small In development since 2015. A GNU package, licensed AGPL/GPL/LGPL.}
+ \end{center}
+\end{frame}
+
+
+% ----------------------------------------------------------------------
+\begin{frame}{Three operations, and that is all}
+ \begin{enumerate}
+ \item {\bf Withdraw.} The wallet asks a regulated operator --- the
+ {\em exchange} --- for coins. The customer's account is debited, and
+ the operator signs coins it {\bf cannot recognise later}.
+ \item {\bf Pay.} The wallet spends coins directly with the merchant. No
+ account, no login, nothing reusable is disclosed.
+ \item {\bf Deposit.} The merchant deposits the coins with the exchange,
+ which detects any double-spend and credits the merchant's account.
+ \end{enumerate}
+ \vfill
+ \begin{center}
+ Double-spending is detected by the {\bf exchange}, not by the merchant
+ --- so the merchant never has to be trusted.
+ \end{center}
+\end{frame}
+
+
+% ----------------------------------------------------------------------
+\begin{frame}{Architecture}
+ \begin{center}
+ \includegraphics[height=5.6cm]{images/operations.png}
+ \end{center}
+\end{frame}
+
+
+% ----------------------------------------------------------------------
+\begin{frame}{The engine: blind signatures and refresh}
+ \begin{itemize}
+ \item {\bf Withdraw.} The wallet blinds a fresh coin key; the operator
+ signs it with a {\em denomination key} encoding the value. It sees the
+ account, never the coin.
+ \item {\bf Spend.} The wallet signs the contract with the coin key. The
+ merchant checks the operator's signature locally, in microseconds.
+ \item {\bf Change.} A partly spent coin is {\bf refreshed} into new
+ coins. The operator verifies that value is conserved and cannot link
+ new to old --- but the owner can, so change cannot move value
+ anonymously.
+ \end{itemize}
+ \vfill
+ \begin{center}
+ {\bf The operator verifies everything and links nothing.}\\[2pt]
+ {\small Every feature in this deck is built from that one property.}
+ \end{center}
+\end{frame}
+
+
+% ----------------------------------------------------------------------
+\begin{frame}{Asymmetric privacy}
+ \begin{minipage}{0.47\textwidth}
+ {\bf Payer}
+ \begin{itemize}
+ \item Unlinkable by construction
+ \item No identity in the payment
+ \item Carries nobody else's data
+ \end{itemize}
+ \end{minipage}
+ \hfill
+ \begin{minipage}{0.47\textwidth}
+ {\bf Payee}
+ \begin{itemize}
+ \item Always identified
+ \item Every receipt attributable
+ \item Income auditable and taxable
+ \end{itemize}
+ \end{minipage}
+
+ \vfill
+ KYC/AML applies where it works: at {\bf withdrawal} and {\bf deposit},
+ inside the regulated perimeter. Anonymity is {\bf one-sided}: there is no
+ anonymous \emph{recipient}, so the laundering direction is closed.
+ \vfill
+ \begin{center}
+ {\small Cash protects the payer \emph{and} hides the merchant. This
+ protects the payer and {\bf exposes} the merchant --- which is also
+ welfare-optimal (Tinn, \emph{Management Science}, 2025).}
+ \end{center}
+\end{frame}
+
+
+% ----------------------------------------------------------------------
+\begin{frame}{Who gets what out of it}
+ \small
+ \begin{itemize}
+ \item {\bf Customer.} Purchase behaviour is private. No account, no
+ login, no sign-up --- so children, tourists and the unbanked are not
+ excluded by onboarding. Payment settles instantly, by QR code or NFC,
+ and is never rejected as suspected fraud.
+ \item {\bf Merchant.} No card data and no buyer information: GDPR and
+ PCI-DSS obligations largely fall away rather than being managed. No
+ chargeback fraud, and costs low enough for small vendors and for
+ micropayments.
+ \item {\bf Public authority.} Privacy is a property of the protocol, so
+ no operator can be compelled to run mass surveillance. Payees must
+ report income to receive it. Issuance, limits, fees and revocation
+ stay with the issuer.
+ \end{itemize}
+ \vfill
+ \begin{center}
+ {\small To note: lose the wallet and you lose the money, as with cash
+ --- but a {\bf thief gains nothing} from a stolen one.}
+ \end{center}
+\end{frame}
+
+
+% ----------------------------------------------------------------------
+\begin{frame}{One primitive, many products}
+ \framesubtitle{Change what the token certifies}
+ \footnotesize
+ \renewcommand{\arraystretch}{1.45}
+ \begin{center}
+ \begin{tabular}{@{}>{\raggedright\arraybackslash}p{5.2cm}@{\quad}>{\raggedright\arraybackslash}p{7.4cm}@{}}
+ {\bf The token certifies \dots} & {\bf \dots and you have} \\
+ \hline
+ a value, in euro or franc & digital cash --- the base case \\
+ a value, and an age bound & age-restricted purchase, without identity \\
+ a right to use one merchant & unlinkable subscriptions and discounts \\
+ an amount given to a charity & a tax-deductible donation receipt (Donau) \\
+ a single HTTP request & pay-per-use web and agent access (Paivana) \\
+ a value, shown without text & a wallet usable without reading or counting \\
+ \end{tabular}
+ \end{center}
+ \vfill
+ \begin{center}
+ {\small Each one is the {\bf same protocol} with a different claim inside
+ the blind signature. None needs a new network.}
+ \end{center}
+\end{frame}
+
+
+% ----------------------------------------------------------------------
+\begin{frame}{Age restriction without identity}
+ \framesubtitle{ESORICS 2022 --- implemented and shipped}
+ \small
+ \begin{itemize}
+ \item A guardian withdraws coins {\bf committed to an age group}.
+ Restricting to group $m$ means {\bf withholding the private keys
+ above $m$}; the commitment is signed into the coin.
+ \item The minor proves ``at least $k$'' for any $k \le m$ by signing
+ with that key. The keys above $m$ cannot be derived.
+ \item The coin does not reveal that it is restricted, or to what. The
+ merchant learns {\bf one bit} --- not a birthdate, a document number
+ or a card.
+ \item The restriction {\bf survives change}: a cut-and-choose proof at
+ refresh leaves a cheating wallet a $1/\kappa$ chance.
+ \end{itemize}
+ \vfill
+ \begin{center}
+ {\small The restriction is tied to the {\bf ability to pay}, not to an
+ identity document --- so no attribute broker and no register of
+ minors. What is missing is {\bf legal recognition} of a cryptographic
+ attestation in place of an ID check.}
+ \end{center}
+\end{frame}
+
+
+% ----------------------------------------------------------------------
+\begin{frame}{Subscriptions and discounts, unlinkably}
+ \small
+ \begin{itemize}
+ \item A merchant defines a {\bf token family}. A contract may
+ {\bf require} tokens and {\bf issue} them: pay once and receive twelve
+ monthly access tokens; buy ten coffees and receive one free.
+ \item The wallet blinds a fresh key per token and the merchant
+ {\bf blind-signs} it, so at redemption the merchant {\bf cannot link
+ the use to the purchase that issued it}. Re-use is caught by a
+ {\bf spent-token registry}, not by identifying the holder.
+ \item Each token is one use: a year's subscription is twelve tokens.
+ \item {\bf Token fountains} hand promotional tokens to a whole group ---
+ a university to its students --- with no order, account or name per
+ recipient.
+ \end{itemize}
+ \vfill
+ \begin{center}
+ {\small Only the wallet and the merchant are involved --- no exchange,
+ no bank, no card scheme. Merged in the merchant backend and in the
+ published protocol; the wallet interface is still in progress.}
+ \end{center}
+\end{frame}
+
+
+% ----------------------------------------------------------------------
+\begin{frame}{Donau: private, deductible donations}
+ \small
+ \begin{itemize}
+ \item A donation today is either {\bf traceable and deductible}, or
+ {\bf private and not deductible}.
+ \item A {\bf Donation Authority}, run by or for the tax authority,
+ registers charities and their annual limits. The wallet collects
+ blind-signed receipts; the charity forwards blinded values it
+ {\bf cannot read}, and never learns who gave.
+ \item At year end the wallet exchanges them for {\bf one signed
+ statement} --- hashed donor identifier, total, year --- which goes
+ into the tax return as a QR code.
+ \item The authority learns what a donor gave {\bf in total} and what a
+ charity received {\bf in total}, never which donation was which, and
+ never the tax identifier itself.
+ \end{itemize}
+ \vfill
+ \begin{center}
+ {\small Auditable throughout: per-charity volume caps are enforced at
+ issuance. Implemented and packaged, merchant integration merged ---
+ but no tax authority operates one yet.}
+ \end{center}
+\end{frame}
+
+
+% ----------------------------------------------------------------------
+\begin{frame}{Paivana: paying per page, or as an agent}
+ \small
+ \begin{itemize}
+ \item The web has two working business models: {\bf subscription} and
+ {\bf surveillance advertising}. Micropayments failed because every
+ payment needed an account, and processing cost more than the article.
+ \item {\bf Paivana} is a reverse proxy placed in front of an existing
+ site. Prices are set per URL pattern, the site is not modified, and
+ the visitor pays for a {\bf time-bounded access token} --- no account,
+ no subscription, no registration.
+ \item The paywall response carries the price in a {\bf machine-readable
+ header}, so an AI agent can {\bf pay} for what it fetches, under a
+ budget its owner set, rather than scrape it.
+ \end{itemize}
+ \vfill
+ \begin{center}
+ A publisher is paid per read and learns nothing about the reader ---
+ and a crawler can be {\bf asked for money} instead of being blocked.
+ \end{center}
+\end{frame}
+
+
+% ----------------------------------------------------------------------
+\begin{frame}{Users who cannot read the amount}
+ \framesubtitle{Joint work with MyOralVillage}
+ \begin{minipage}{0.40\textwidth}
+ \begin{center}
+ \includegraphics[width=\textwidth]{images/taler-oim.png}
+ \end{center}
+ \end{minipage}
+ \hfill
+ \begin{minipage}{0.56\textwidth}
+ {\small
+ \begin{itemize}
+ \item Amounts are shown as {\bf countable denominations}, not
+ digits; every task is {\bf correctable}.
+ \item Freetown, 2025: {\bf 21} women, 6 languages. Only 4 had
+ finished primary school; only 6 could read a five-digit number.
+ \item After a 24-hour gap, 8 payment tasks, unaided: {\bf 16}
+ completed all 8 with no errors, {\bf 4} with retries and no help,
+ 1 did not complete.
+ \end{itemize}
+ }
+ \end{minipage}
+
+ \vfill
+ \begin{center}
+ {\small A payment instrument that assumes numeracy excludes the people
+ who need it most. The {\bf same wallet} serves both.}
+ \end{center}
+\end{frame}
+
+
+% ----------------------------------------------------------------------
+\begin{frame}{Offline: what works, and what cannot}
+ \begin{itemize}
+ \item {\bf Deployed:} the {\bf merchant} offline, the customer online.
+ The terminal shows an identifier, the wallet pays over its own
+ connection, and a one-time code proves settlement to the terminal.
+ Vending machines and unattended points of sale.
+ \item {\bf Unsolved, by anyone:} both sides offline with a bearer
+ balance. Offline double-spending can be {\bf punished}, never
+ {\bf prevented}.
+ \item That leaves two options: trust tamper-resistant hardware
+ {\bf against its own owner}, or {\bf de-anonymise retroactively}.
+ There is no third.
+ \end{itemize}
+ \vfill
+ \begin{center}
+ {\small We do the other half of this work too: breaking the secure
+ elements such designs rely on, by side channel and fault injection.}
+ \end{center}
+\end{frame}
+
+
+% ----------------------------------------------------------------------
+\begin{frame}{Losing the phone}
+ \framesubtitle{GNU Anastasis}
+ \begin{itemize}
+ \item {\bf Anastasis} encrypts the wallet's root secret under a master
+ key and {\bf splits that key across independent escrow providers}.
+ \item The user sets the policy: which subsets must be satisfied, and by
+ which challenges --- a security question, an SMS, a video
+ identification, a transfer from a known account.
+ \item {\bf No single provider} can recover the key, and none learns what
+ it protects. Recovery works {\bf without} the user remembering
+ anything of high entropy.
+ \end{itemize}
+ \vfill
+ \begin{center}
+ Consumer protection by {\bf splitting trust}, rather than by
+ concentrating it in a custodian.\\[2pt]
+ {\small Implemented: provider backend, client libraries, command line
+ and graphical application.}
+ \end{center}
+\end{frame}
+
+
+% ----------------------------------------------------------------------
+\begin{frame}{Post-quantum: where we actually are}
+ \footnotesize
+ \begin{itemize}
+ \item Taler's public-key layer is {\bf entirely} factoring- and
+ discrete-logarithm-based --- ``very susceptible to attacks with a
+ quantum computer'', in our own analysis's words.
+ \item {\bf Two different clocks.} Forging coins needs a quantum computer
+ {\em at the time of the attack}. Unlinkability does not: refresh uses
+ Diffie--Hellman, so whoever obtains the operator's database later can
+ link refreshed coins {\bf retroactively}. That damage accrues today.
+ \item The obstacle is specific: refresh needs {\bf one key usable both
+ for signing and for key exchange}, and no proposed post-quantum
+ signature scheme has that property.
+ \item {\bf Ready in theory, not in implementation.} The running code is
+ pre-quantum, and no post-quantum blind signature is deployment-ready
+ --- the round-efficient candidate costs some {\bf 22\,kB} per
+ signature against 256 bytes today. Call it 18--24 months.
+ \end{itemize}
+\end{frame}
+
+
+% ----------------------------------------------------------------------
+\begin{frame}{Where it runs, and what is built}
+ \footnotesize
+ \begin{minipage}{0.48\textwidth}
+ {\bf Deployed}
+ \begin{itemize}
+ \item eNetzbon, the Basel regional currency, since 2024
+ \item eCHF from Taler Operations AG since 2025, under the Swiss
+ {\bf sandbox exemption}: {\bf not} FINMA-supervised, deposits
+ capped at CHF\,1\,m, anti-money-laundering through a recognised
+ self-regulatory body
+ \item First merchants accepting it since January 2026
+ \item Magnet Bank, Hungary: {\bf internal alpha}, no launch date
+ announced
+ \end{itemize}
+ \end{minipage}
+ \hfill
+ \begin{minipage}{0.48\textwidth}
+ {\bf Built}
+ \begin{itemize}
+ \item {\bf 28{,}500} payments per second, measured end to end on a
+ research cluster at reduced key sizes --- Switzerland's entire
+ retail volume is around 2{,}000 per second
+ \item EBICS and ISO\,20022 connectivity tested with five Swiss and
+ German banks; native adapters for Magnet Bank and Cyclos
+ \item Wallets for Android, iOS and the browser
+ \end{itemize}
+ \end{minipage}
+
+ \vfill
+ \begin{center}
+ {\footnotesize An integration means a Taler operator can {\bf bank
+ there}, not that the bank offers Taler. Two live deployments, both
+ Swiss; none yet in the euro area.}
+ \end{center}
+\end{frame}
+
+
+% ----------------------------------------------------------------------
+\begin{frame}{Roadmap and open problems}
+ \small
+ \begin{minipage}{0.47\textwidth}
+ {\bf In progress}
+ \begin{itemize}
+ \item Currency conversion via Interledger
+ \item Terminals, vending, doors, one-time-password hardware
+ \item Wallet recovery with Anastasis
+ \item KYC via national e-ID across Europe
+ \item Post-quantum protocol variant
+ \end{itemize}
+ \end{minipage}
+ \hfill
+ \begin{minipage}{0.47\textwidth}
+ {\bf Unsolved}
+ \begin{itemize}
+ \item Both parties offline with a bearer balance
+ \item Direct debit and pull payments
+ \item Practical post-quantum blind signatures
+ \item No euro-area deployment yet
+ \end{itemize}
+ \end{minipage}
+
+ \vfill
+ \begin{center}
+ {\small We also work the other side: breaking secure elements and
+ hardware security modules by side channel and fault injection.}
+ \end{center}
+\end{frame}
+
+
+% ----------------------------------------------------------------------
+\begin{frame}{Where this touches your files}
+ \small
+ \begin{itemize}
+ \item {\bf Digital euro.} A design in which privacy is a property of the
+ protocol, not a restriction on who may query a database. We have a
+ second deck on that if you would rather have it.
+ \item {\bf Retail payments.} Instant clearance at par, no interchange to
+ divide, no payer credential for a merchant to lose.
+ \item {\bf Anti-money-laundering.} Anonymity on one side only. Every
+ euro enters and leaves through a regulated institution.
+ \item {\bf Age assurance.} A proof of ``at least 16'' that discloses
+ nothing else --- already implemented, pending legal recognition.
+ \item {\bf Data protection and sovereignty.} Data that is never created
+ cannot be breached or transferred; free software, published
+ specification, no single operator.
+ \end{itemize}
+\end{frame}
+
+
+% ----------------------------------------------------------------------
+\begin{frame}{Summary}
+ \begin{itemize}
+ \item One property --- {\bf the operator verifies everything and links
+ nothing} --- and every feature here falls out of it.
+ \item Privacy for the payer, identification of the payee: taxable,
+ auditable, and not a laundering instrument.
+ \item Age proofs, subscriptions, discounts, donation receipts,
+ pay-per-request web access, recovery after device loss: the
+ {\bf same protocol}, a different claim inside the signature.
+ \item Free software and a published specification, in production in
+ Switzerland --- and not yet in the euro area.
+ \end{itemize}
+ \vfill
+ \begin{center}
+ {\small \url{https://taler.net} \quad
+ \url{https://docs.taler.net} \quad
+ \url{https://git.taler.net} \quad
+ \url{https://demo.taler.net}}
+ \end{center}
+\end{frame}
+
+
+% ----------------------------------------------------------------------
+\begin{frame}{Acknowledgements}
+
+ \begin{minipage}{0.45\textwidth} \ \\
+ {\tiny Funded by the European Union (Project 101135475).}
+
+ \begin{center}
+ \includegraphics[width=0.5\textwidth]{images/bandera.jpg}
+ \end{center}
+ \end{minipage}
+ \hfill
+ \begin{minipage}{0.45\textwidth}
+ {\tiny Funded by SERI (HEU-Projekt 101135475-TALER).}
+
+ \begin{center}
+ \includegraphics[width=0.65\textwidth]{images/sbfi.jpg}
+ \end{center}
+ \end{minipage}
+
+ \vfill
+
+ {\tiny
+
+ Views and opinions expressed are however those of the author(s) only
+ and do not necessarily reflect those of the European Union. Neither the
+ European Union nor the granting authority can be held responsible for
+ them.
+
+ }
+\end{frame}
+
+\end{document}
diff --git a/presentations/2026-dg-fisma/dg-fisma-2026.pdf b/presentations/2026-dg-fisma/dg-fisma-2026.pdf
Binary files differ.
diff --git a/presentations/2026-dg-fisma/dg-fisma-2026.tex b/presentations/2026-dg-fisma/dg-fisma-2026.tex
@@ -142,13 +142,11 @@
\item Income auditable and taxable
\end{itemize}
\end{minipage}
+
\vfill
- \begin{itemize}
- \item KYC/AML applies where it works: at {\bf withdrawal} and at
- {\bf deposit}, inside the regulated perimeter.
- \item Anonymity is {\bf one-sided}, so there is no anonymous
- \emph{recipient}. The laundering direction is closed.
- \end{itemize}
+ KYC/AML applies where it works: at {\bf withdrawal} and at {\bf deposit},
+ inside the regulated perimeter. Anonymity is {\bf one-sided}, so there is
+ no anonymous \emph{recipient} --- the laundering direction is closed.
\vfill
\begin{center}
Cash protects the payer \emph{and} hides the merchant.\\
@@ -278,6 +276,7 @@
\item Coin expiry and refresh fees discourage hoarding
\end{itemize}
\end{minipage}
+
\vfill
\begin{center}
Banca d'Italia, on eCash: withdrawal {\bf applies all the controls of an
@@ -360,11 +359,13 @@
\begin{minipage}{0.47\textwidth}
{\bf Done}
\begin{itemize}
- \item Live in Switzerland in regulated CHF, under the FINMA
- {\bf sandbox} regime with SRO supervision
- \item v1.5; independent external security audits
- \item {\bf 28{,}500} transactions/s measured --- Switzerland needs
- $\approx$2{,}000, the euro area $\approx$100{,}000
+ \item Live in Switzerland in CHF under the FINMA {\bf sandbox
+ exemption} --- {\bf not} FINMA-supervised; AML through a
+ recognised SRO
+ \item v1.6; independent external security audits
+ \item {\bf 28{,}500} transactions/s measured at reduced key sizes
+ --- Switzerland needs $\approx$2{,}000, the euro area
+ $\approx$100{,}000
\item Android, iOS, browser; EBICS/ISO 20022
\end{itemize}
\end{minipage}
@@ -372,7 +373,8 @@
\begin{minipage}{0.47\textwidth}
{\bf Not done}
\begin{itemize}
- \item No euro-area deployment yet; Hungary 2027 at the earliest
+ \item No euro-area deployment yet; Hungary in internal alpha, with
+ no launch date announced
\item Sandbox caps the Swiss operator at {\bf CHF 1\,m} in total
deposits
\item Fully offline (both sides) {\bf unsolved} --- as it is for
diff --git a/presentations/2026-dg-fisma/images/taler-oim.png b/presentations/2026-dg-fisma/images/taler-oim.png
Binary files differ.
