summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorJeffrey Burdges <burdges@gnunet.org>2017-05-18 14:29:20 +0200
committerJeffrey Burdges <burdges@gnunet.org>2017-05-18 14:40:41 +0200
commitc47745a1b3aab470035b1883b08e4f6e7131038f (patch)
tree959096fc40e34283e15b6d274614354b9ac27961 /doc
parente6d61f666bddb8fd38c2f64b3f02a8d83721c92d (diff)
downloadexchange-c47745a1b3aab470035b1883b08e4f6e7131038f.tar.gz
exchange-c47745a1b3aab470035b1883b08e4f6e7131038f.tar.bz2
exchange-c47745a1b3aab470035b1883b08e4f6e7131038f.zip
Add a bit to FC2017 comments
Diffstat (limited to 'doc')
-rw-r--r--doc/paper/taler_FC2016.txt27
1 files changed, 19 insertions, 8 deletions
diff --git a/doc/paper/taler_FC2016.txt b/doc/paper/taler_FC2016.txt
index d84e2ce0..60a7c0da 100644
--- a/doc/paper/taler_FC2016.txt
+++ b/doc/paper/taler_FC2016.txt
@@ -156,10 +156,10 @@ provides in its base form, without hidden services)
[3.1] Why does the customer need an anonymous channel when interacting
with the mint?
-> An anonymous channel is strictly needed only during refresh,
-> to provide unlinkability vs. the transaction at the merchant.
-> However, for location privacy it is generally still advisable
-> to always use an anonymous channel, as the exchange should
+> An anonymous channel is needed only when fetching /keys and during
+> refresh, for unlinkability vs. the transaction with the merchant.
+> However, for location privacy it is generally still advisable to
+> always use an anonymous channel, as the exchange should
> not learn more information than necessary.
[3.2] The discussion of copying private keys is informative but I’m not
@@ -171,7 +171,18 @@ key. In this case, they do not have to worry about the other party
absolving with the funds (but they do have to worry about the other
party cooperating when one party wants to use the funds).
-> We do not use threshold signing.
+> Right now, we discuss coping coins only in the context of its
+> inevitability and its relationship to taxability. In future, we do
+> envision wallets supporting the transfer of coins between friends
+> and family, with the refresh protocol used to recover from problems.
+>
+> There are interesting things one could do with threshold signing
+> and even group signatures of course, but these seems like niche use
+> cases that do not warrant the protocol complexity. We have not
+> evaluated if a simple change like using a BLS signature scheme
+> might support such use cases at the exchange level, but doing so
+> might make the refresh protocol subject to the ever improving attacks
+> on pairings, so again the complexity seems unwarranted for now.
[3.3] I think you understate the benefits of the mint knowing the
identity of the customer: many countries have Know Your Customer (KYC)
@@ -217,10 +228,10 @@ sigs in the DL setting exist of course, but you should specify and cite
an appropriate one.
> We don't use blind sigs in the DL setting. We use RSA blind signatures
-> and Ed25519 for all _other_ signatures. (Taler has about 30 places
+> and Ed25519 for all _other_ signatures. Taler has about 30 places
> in the protocol where different parties sign different types of
-> messages.) Only the validity of coins is attested with RSA signatures,
-> the rest uses EdDSA. ECDH(E) is used for the refresh protocol.
+> messages. Only the validity of coins is attested with RSA signatures,
+> the rest uses Ed25519. ECDH(E) is used for the refresh protocol.
[4.6] If Alice pays $75 to Bob using a $100 coin, is there any technical
difference between (a) Bob limiting the coin to $75 and Alice refreshing