[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Taler] The illicit use case (A)
From: |
fabian . kirsch |
Subject: |
Re: [Taler] The illicit use case (A) |
Date: |
Tue, 29 Sep 2015 09:39:32 +0200 |
User-agent: |
Posteo Webmail |
That is not quite correct. Sharing can be finalized, by spending the
You're right.
Well, in the current design of refreshing, we assume that losses of
2/3rds are unacceptable. If they are, we'd have to raise the security
parameter kappa.
and have a role model in which the mint is trusted by the state.
I suggest the state should skim most of the mint's profits from failed
coin refreshs.
Spending has to be lightweight and fast. But
is there a reason, that refreshing has to be fast?
Could we declare:
SA = Key from state authority
customer: commitment = S_C'(E,B,T_p, timestamp)
state: prefix = Hash(string with results from the national lottery
draw following the commitment)
state: announce = S_SA( prefix )
customer and mint: gamma = Lowerbits( Hash( prefix, commitment ))
Refreshing would be delayed by a working day.
Auditors can look for backdated commits.
So the mint and customer derive the gamma from official announcements.
For the level of protection against illicit use:
Please correct me if i'm wrong.
The goal of taler is to be accepted by the state as a legal payment
method.
They come from "Know your customer" and detailed records of wire
transfers, SWIFT, Visa, Mastercard.
They don't care if taler is more decentralized, less resource-hungry,
more efficient, faster, ...
But taler's coin spending is by design diametral to "know your
customer".
In order to get taler accepted while keeping the desired anonymous
spending,
we have to absolutely care for tax-evasion (TE) and money laundering
(ML).
TE and ML have to be less convenient in taler than with existing means.
And this "less convenient" has to be plausible to the state.
As long as the state gives no banking license to the mint the merchant
is not allowed to accept wire transfers from the mint for services to
third parties (the customer).
Paypal, paysafe, ukash, they all needed to acquire a license.
lieferheld.de (order local pizza, sushi, curry, etc. in one platform)
had to learn this the hard way.
- Re: [Taler] The illicit use case (A),
fabian . kirsch <=