taler
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Taler] Hello


From: Christian Grothoff
Subject: Re: [Taler] Hello
Date: Sun, 8 Jan 2017 13:33:12 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

On 01/08/2017 01:09 PM, Joerg Baach wrote:
>> and terribly inefficient.  If you give me say 2x 1 EUR, 1x 2 EUR and 1x
>> 4 EUR, then I go spend 1 EUR, spend again 1 EUR somewhere else, and then
>> when I try to spend 1 EUR for the third time, I'm left with one 2 EUR
>> and one 4 EUR coin and cannot complete the transaction.
> 
> Indeed. This is what happens in opencoin. You can rely only one doing at
> least one payment before getting new change. I think you fully
> understood it.

Ah, great.

>> background automatically), but in that case the system will see it as me
>> receiving _income_ (money transfer to me!) and I certainly wouldn't want
>> to pay income tax on that.  Alternatively, you could give back the 4 EUR
> 
> This is out of the scope of our system. However, is a refresh really
> income? Because in the end 4 EUR are going to the bank, but also 4 EUR
> are leaving the bank. So, turnover is increased, but not the balance.

We agree that change is not income; my point was that because of that,
we cannot use deposit + withdraw and instead use refresh.

>> What part am I not understanding here? Do you have some real
>> documentation on how Opencoin does this? Pointing to the source is
>> hardly adequate IMO.
> 
> I completely agree on pointers to the source as being inadequate. We
> don't have formal spec for this bit though. But you have the idea, and I
> will add a description of the refresh mechanism to the documentation.

I think I got it now: if your coin structure after spending has
degenerated to the point that for some amounts you could no longer pay,
you refill your wallet with 'adequate' change upon the next withdraw, so
as to again assure that you can pay any amount.  However, between an
(unlucky) transaction and a withdraw, there may be a point where you
cannot make a transaction due to lack of exact change.

Taler can (and probably should) use similar tricks when withdrawing
coins to maintain adequate change, but additionally with the refresh
protocol Taler can partially spend coins and get unlinkable change
independent of a fresh withdrawal.

On 01/08/2017 01:01 PM, Joerg Baach wrote:
>> would be computed exactly like for the original withdrawal.  In
>> principle, a stranger total value for the refresh "withdrawal" creates a
>> slightly unusual stash of coins, but I doubt this impacts anonymity
>> much.
>
> So we seem to agree that some information is leaked, the question is,
> how much it matters.

Nope, I still do not agree even with that.  In fact, my analysis
suggests that the refresh protocol _strengthens_ anonymity as it
increases the anonymity set of a denomination key (with a normal
withdraw, I know the set of customers that could have withdrawn the
coin; once refresh is thrown into the mix, there is a much larger set of
historic customers that could have done the refresh, hence the effect is
similar to that of moving from a fixed-size mix to a pool mix).  And
also no additional information is leaked by the protocol, in the sense
that all information about the customer that might be leaked by refresh
would already be known to the other entities already anyway (be it
inadequately protected IP addresses, timing or amount data).

> I guess there are different attack scenarios, so it
> is hard to determine - it just leaves a bad feeling to me. If you have
> transactions of the form
>
> a --t--> b
>
> in your system b is known. The refresh withdrawal exposes t (somewhat).
> Now you only rely on keeping a anonymous, using external mechanisms.
> Compare that to t being untraceable - then the anonymity of a doesn't
> matter anymore.

Sorry, but I have no idea what a, t or b are supposed to be here, or
what the arrow is supposed too indicate.

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]