commit 56fba2d9371a47100df42b5cc3e2f0af81166abc
parent 43a2be878936049e09551c3e23968b5267b42313
Author: Christian Grothoff <grothoff@gnunet.org>
Date: Tue, 16 Jun 2026 19:10:41 +0200
fix #11506 from my end
Diffstat:
1 file changed, 73 insertions(+), 4 deletions(-)
diff --git a/design-documents/095-captcha-100.rst b/design-documents/095-captcha-100.rst
@@ -4,7 +4,30 @@ DD 95: Captcha 100
Summary
=======
-
+One of the key applications we had always envisioned was the use of GNU Taler
+for spam protection. A related application domain is Captcha's, where a server
+needs some 'proof-of-humanity' to protect itself from handling expensive
+requests on behalf of some out-of-control automated bot process. The key
+insight is that here the operator is not necessarily interested in receiving
+revenue from GNU Taler, but primarily in limiting their exposure to the attack
+by increasing the cost to the initiator of the request. Furthermore, the
+operator is often willing to inconvenience the sender, be it by various spam
+filters (which have false-positives) or forcing the sender to solve Captcha's
+or computational puzzles (Anubis). These existing methods are today often
+failing, especially as LLMs enable bots to formulate messages that pass spam
+filters or to solve Captcha's. In this context, forcing the sender to make a
+Taler deposit becomes simply another form of imposing a cost, and one that
+would cost an attacker more dearly.
+
+We can quickly enable this use-case by setting the Taler fees to 100%. At
+this point, the "merchant" never actually receives any money (and customers
+that withdrew tokens cannot get money when they return them either), so the
+operator would not be a payment service as they do not give money to anybody.
+While this is less attractive to the recipient, it would still be effective at
+blocking bots. At the same time, this model can be rolled out globally pretty
+quickly because at 100% fees we do not need a money transmitter or e-money
+issuer license, as we no longer transmit money -- we only accept money in
+return for a digital service, like many other regular unregulated businesses.
Motivation
==========
@@ -15,11 +38,58 @@ Motivation
Requirements
============
+There are two high-level key requirements:
+
+- global availability for consumers; few sites or e-mail recipients would be
+ happy if they cannot be contacted by a large fraction of their partners
+ anymore. Thus, we need to have bank accounts for major currencies (USD,
+ EUR, ideally more) and Bitcoin (BTC) as a stop-gap. It is probably OK
+ to exclude parts of Asia or Africa initially, as many individuals or
+ businesses would have few relevant global connections. Explanations for
+ consumers withdrawing tokens must also be crystal-clear, especially
+ that they do not get digital cash. We may want a new "bank dialect"
+ to change user-facing terminology in the wallets to use language that
+ is less payment-focused.
+- the paywalls must be well-documented, scalable to high traffic volumes
+ and easy to deploy. Instructions given to the blocked humans must also
+ be clear. Whitelisting must be possible to give services an easy way
+ to unblock highly desireable users without forcing them to pay.
+
+For the paywalls, we are mostly focusing on two:
+- paivana-httpd: reverse proxy for HTTP that adds a paivana-style paywall
+- pepsi: MTA/forwarder/proxy for SMTP that has a Taler payment gate and
+ logic to learn whitelisted senders from monitoring receivers of
+ outgoing traffic
+
+This will cover the two main use-cases.
Proposed Solution
=================
+Business:
+- Open bank accounts in various currencies
+- Consider getting no-action letters from regulators
+
+Wallets:
+- Implement wallet dialect with non-payment captcha-oriented language
+- Ensure wallets respect 'no deposit' and 'no-p2p' settings nicely
+- Communicate special fee structure clearly on withdraw
+
+Other development:
+- Implement, test and document Pepsi
+- update merchant backend to support wire method 'void'
+ (auto-configured bank account payto://void/) for some
+ particular settings.
+
+Administration:
+- Deploy a single exchange in CAPTCHAS and hook it up
+ to all of these accounts with some reasonable currency
+ conversion ratio
+- Setup new web site explaining the solution
+- Setup paivana-httpd in front of our Git Web
+- Setup Pepsi in front of (some) of our e-mail accounts
+
Test Plan
=========
@@ -36,9 +106,8 @@ Test Plan
Definition of Done
==================
-(Only applicable to design documents that describe a new feature. While the
-DoD is not satisfied yet, a user-facing feature **must** be behind a feature
-flag or dev-mode flag.)
+- Exchange, Merchant backends and "demonstrators" (Git-Web, SMTP) live
+
Alternatives
============
