095-captcha-100.rst (5391B)
1 DD 95: Captcha 100 2 ################## 3 4 :Design status: Proposed 5 :Implementation status: Partial 6 :DD shepherd: TBD 7 :Historical contributors: Christian Grothoff, Bohdan Potuzhnyi 8 :First published: 2026-06-16 9 :Last substantive change: 2026-06-16 10 :Implementation evidence: ``paivana`` (2026-04-19); Pepsi, wire-void, and complete CAPTCHA deployment evidence was not established 11 :Normative references: ``taler-paivana-manual.rst`` and ``frags/paivana-httpd-manual.rst`` 12 13 Summary 14 ======= 15 16 One of the key applications we had always envisioned was the use of GNU Taler 17 for spam protection. A related application domain is Captcha's, where a server 18 needs some 'proof-of-humanity' to protect itself from handling expensive 19 requests on behalf of some out-of-control automated bot process. The key 20 insight is that here the operator is not necessarily interested in receiving 21 revenue from GNU Taler, but primarily in limiting their exposure to the attack 22 by increasing the cost to the initiator of the request. Furthermore, the 23 operator is often willing to inconvenience the sender, be it by various spam 24 filters (which have false-positives) or forcing the sender to solve Captcha's 25 or computational puzzles (Anubis). These existing methods are today often 26 failing, especially as LLMs enable bots to formulate messages that pass spam 27 filters or to solve Captcha's. In this context, forcing the sender to make a 28 Taler deposit becomes simply another form of imposing a cost, and one that 29 would cost an attacker more dearly. 30 31 We can investigate this use-case by setting the Taler fees to 100%. At this 32 point, the "merchant" never actually receives any money (and customers that 33 withdrew tokens cannot get money when they return them either), while the fee 34 still imposes a cost on bots. Whether such an operator is outside payment- 35 service, money-transmitter, or e-money licensing is jurisdiction-dependent and 36 requires qualified legal review; this design makes no global licensing claim. 37 38 Motivation 39 ========== 40 41 - globally launch first useful GNU Taler service without requiring a license 42 - protect users from DDoS / spam / phishing 43 44 Requirements 45 ============ 46 47 There are two high-level key requirements: 48 49 - global availability for consumers; few sites or e-mail recipients would be 50 happy if they cannot be contacted by a large fraction of their partners 51 anymore. Thus, we need to have bank accounts for major currencies (USD, 52 EUR, ideally more) and Bitcoin (BTC) as a stop-gap. It is probably OK 53 to exclude parts of Asia or Africa initially, as many individuals or 54 businesses would have few relevant global connections. Explanations for 55 consumers withdrawing tokens must also be crystal-clear, especially 56 that they do not get digital cash. We may want a new "bank dialect" 57 to change user-facing terminology in the wallets to use language that 58 is less payment-focused. 59 - the paywalls must be well-documented, scalable to high traffic volumes 60 and easy to deploy. Instructions given to the blocked humans must also 61 be clear. Whitelisting must be possible to give services an easy way 62 to unblock highly desireable users without forcing them to pay. 63 64 For the paywalls, we are mostly focusing on two: 65 66 - paivana-httpd: reverse proxy for HTTP that adds a paivana-style paywall 67 - pepsi: MTA/forwarder/proxy for SMTP that has a Taler payment gate and 68 logic to learn whitelisted senders from monitoring receivers of 69 outgoing traffic 70 71 This will cover the two main use-cases. 72 73 Proposed Solution 74 ================= 75 76 Business: 77 78 - Open bank accounts in various currencies 79 - Consider getting no-action letters from regulators 80 81 Wallets: 82 83 - Implement wallet dialect with non-payment captcha-oriented language 84 - Ensure wallets respect 'no deposit' and 'no-p2p' settings nicely 85 - Communicate special fee structure clearly on withdraw 86 87 Other development: 88 89 - Implement, test and document Pepsi 90 - update merchant backend to support wire method 'void' 91 (auto-configured bank account payto://void/) for some 92 particular settings. 93 94 Administration: 95 96 - Deploy a single exchange in CAPTCHAS and hook it up 97 to all of these accounts with some reasonable currency 98 conversion ratio 99 - Setup new web site explaining the solution 100 - Setup paivana-httpd in front of our Git Web 101 - Setup Pepsi in front of (some) of our e-mail accounts 102 103 104 Test Plan 105 ========= 106 107 - terms of service written and reviewed 108 - website explaining system live 109 - Operational exchange in USD, EUR, BTC converting to CAPTCHA 110 - merchant backend (single-instance) for testers with that exchange 111 - void account supported by merchant backend / SPA 112 - paivana-httpd works for git-www.taler.net 113 - pepsi works for say grothoff.org, other self-hosted team members 114 115 116 Definition of Done 117 ================== 118 119 - Exchange, Merchant backends and "demonstrators" (Git-Web, SMTP) live 120 121 122 Alternatives 123 ============ 124 125 - get a license first and share revenue; very difficult to do globally, 126 and without global operation very limited utility as users would be 127 excluded because they cannot pay due to unavailability of the payment 128 system 129 - even partial, deferred payments or incentives paid to operators would 130 likely move the solution towards being seen as *bad* creative ways to 131 try to side-step the need for a license, so only 100% fees are a good 132 choice here 133 134 Drawbacks 135 ========= 136 137 - harder to motivate deployments 138 139 Discussion / Q&A 140 ================