[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[taler-docs] branch master updated: document offline payments discussion
From: |
gnunet |
Subject: |
[taler-docs] branch master updated: document offline payments discussion |
Date: |
Thu, 04 Aug 2022 11:04:12 +0200 |
This is an automated email from the git hooks/post-receive script.
dold pushed a commit to branch master
in repository docs.
The following commit(s) were added to refs/heads/master by this push:
new a1a342b document offline payments discussion
a1a342b is described below
commit a1a342bad891df0637e2b61ba22e4af66c26bfc5
Author: Florian Dold <florian@dold.me>
AuthorDate: Thu Aug 4 11:04:10 2022 +0200
document offline payments discussion
---
design-documents/030-offline-payments.rst | 99 +++++++++++++++++++++++++++++++
1 file changed, 99 insertions(+)
diff --git a/design-documents/030-offline-payments.rst
b/design-documents/030-offline-payments.rst
new file mode 100644
index 0000000..5466d7c
--- /dev/null
+++ b/design-documents/030-offline-payments.rst
@@ -0,0 +1,99 @@
+Design Doc 030: Offline payments
+#######################################
+
+Summary
+=======
+
+This design document discusses support for offline payments.
+
+Motivation
+==========
+
+Many proposed CBDCs claim to support offline payments.
+Taler is explicitly meant to be an online payment system. However, since there
+recently seems to be an increased interest in offline CBDC solutions,
+we have decided to still explore how Taler could support offline payments in
the future.
+
+While we still recommend online-only payments, this work operates under the the
+following theme: "If Taler can support offline payments that are no worse than
+those of competing systems (that often offer less freedom and privacy to
+users), why should we claim we can't support them and fare worse in
comparisons"?
+
+Requirements
+============
+
+TBD.
+
+Possible Solutions
+==================
+
+Approach 1: Trust-based offline payments
+----------------------------------------
+
+The merchant simply trusts payments without depositing them at the exchange, up
+to a certain threshold and when an emergency mode is activated.
+
+Advantages:
+
+- Offers the most user freedom
+- Very few protocol/implementation changes required
+
+Disadvantages:
+
+- Requires manual switching to "emergency mode" where merchant
+ just trusts payments without verification.
+- Linkability of transactions unavoidable, because refresh is not available
offline
+- Unclear if/how business logic based on order state will be affected.
+ (Will there be a "paid-offline" / "paid-unconfirmed" state for orders?)
+
+Approach 2: Full HSM wallet
+---------------------------
+
+Implement the full wallet in a hardware security module. When paying, the HSM
+wallet attests itself to the merchant, who then (if configured appropriately)
+trusts that the coins are still valid without talking to the exchange first.
+
+Advantages:
+
+- Easy to lift coins out of the HSM into a software wallet.
+ The HSM would internally mark the coins as "online" and give
+ the coin secrets to the software wallet.
+- Few exchange/merchant protocol changes required.
+
+Disadvantages:
+
+- Complex implementation, might not be supported on commodity HSMs.
+- Requires medium-to-major merchant backend changes (to verify HSM sigs and
+ deposit coins once offline)
+- Difficult to support P2P payments
+- Depending on available coins, linkable transactions
+ might be unavoidable.
+- Since the HSM wallet supports the full protocol, regulators might
+ be encouraged to make the HSM a requirement for *all* payments.
+- The usual (justified!) HSM security and freedom concerns
+
+Approach 3: Light-weight HSM balance register
+---------------------------------------------
+
+The HSM maintains an offline balance, effectively as a single, HSM protected
+register. To obtain offline cash, the software wallet spends coins to get a
+signature that can be passed to the HSM to increment the offline balance.
+To spend, the software wallet requests an "offline deposit permission"
+that decrements the HSM balance register. The exchange accepts these offline
+deposit permissions in lieu of a normal coin deposit permission.
+
+Advantages:
+
+- Trivially supports P2P payments
+- Cleanly separates normal Taler functionality from offline functionality
+
+Disadvantages:
+
+- Requires non-trivial (but backwards compatible) protocol changes
+- The usual (justified!) HSM security and freedom concerns
+
+
+Discussion / Q&A
+================
+
+(This should be filled in with results from discussions on mailing lists /
personal communication.)
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [taler-docs] branch master updated: document offline payments discussion,
gnunet <=