Re: [Taler] minor changes

[Jeff Burdges]

On Tue, 2015-10-13 at 21:32 +0200, Christian Grothoff wrote:
> Jeff, we expect to get "random" delays because the wallets will
> withdraw (likely in the background!) and the coins will remain
> for some 'random' time in the wallet before being spent.  

Doing withdrawals in the background makes things interesting.

> Making the mint slow would be horrible for various reasons, 
> but most importantly not help as without a wallet-side delay, 
> the mint can still link the transactions.

Yes obviously.  I never said we should make the mint slow.  I said the
1 min timeouts were likely too short.


On Tue, 2015-10-13 at 19:58 +0200, Fabian Kirsch wrote:
> are you afraid of timing attacks uncovering the customer coin
> relation?
> 
> Thinking of kinda MailMix.
> Let the Mint wait for N blind signings in the queue,
> then serving them at the same time.


I'd consider that a bad approach for numerous reasons, including:
- The mint cannot expect the user will still be online then. 
- Taler must work for small deployments that merely want a transaction
system, well even a large deployment must still start somewhere.
- The mint still knows exactly when the coin was issued, thus helping
to deanonymize users.


There are better ways to address this through the wallet interface. 

Approach 1.  The mint publishes a safety margin with their
denomination's signing key.  The wallet records issue time plus safety
margin as a safe time.  If a transaction is requested, and the wallet
can satisfy it with safely old coins, then it should do so.  If it
cannot, then it should tell the user when enough coins will be clean,
and suggest they wait.  Of course, the wallet should always allow the
user to spend their coins, even if they're being impatient.

Now the above scheme sucks because it segments users into patient and impatient 
with similar behavior, but the patient ones get shifted by the waiting period, 
so not much extra benefit.

Approach 2.  The mint publishes the parameters for probability
distributions representing withdrawal and spending events.  We expect
that, for any particular size range, the events obey an exponential
distribution, ignoring time of day, holidays, etc., so this should be
nicely parameterizable.  We should think about if it's possible or
useful to model wallet balances too.  Now the wallet should record
timestamps for recent withdrawal and spending events.  As the user
enters information, there should be javascript that updates an estimate
of their anonymity set size based upon these recent events, maybe
colors it yellow or red if it's small.  There need not be a warning
dialog if a user wants to withdraw money after spending it or spends it
after withdrawing it, just a little number that changes to red. 

I'll think about how one should actually do this anonymity set size 
computation.  It's definitely messy, especially as it involves several 
different effects, but imho it's worth doing well if possible.  

Jeff

signature.asc
Description: This is a digitally signed message part