Re: [Taler] Hello

[Christian Grothoff]

On 12/31/2016 04:53 PM, Joerg Baach wrote:
>> This is not correct; refresh does not cause us to loose the
>> untraceability of transactions, because the exchange does NOT know that
> 
> [...]
>> That's interesting, could you elaborate on this? I don't see how you can
>> do this _efficiently_, especially as withdrawing EUR 40.52 in advance of
>> an EUR 40.52 transaction would obviously seriously reduce my anonymity
>> set.  So please elaborate on your solution, I'm really curious.
> 
> 
> I guess in the end we both maybe mean the same - reducing anonymity or
> leaving traces, a maybe unnecessary piece of the puzzle. In Taler, if I
> see an awkward coming in from B, and the matching changing coming in
> from A, I can assume that this is a specific transaction. If I can
> resolve A to Alice then only depends on TOR.

As Jeff mentioned, there is the trivial option (still under discussion)
of routing the refresh request over the merchant B.  Then both /deposit
and /refresh would come from B. Right now, my feeling is that for good
privacy A relies on using Tor to have anonymity from B, and then ought
to be able to rely on Tor to have anonymity with respect to the exchange
as well, but you are right that of course a 2nd exit slightly increases
the exposure.

> In opencoin we do it this way: way before any transaction Alice makes
> sure that the coins in her wallet allow her to pay any desired
> amount.[1]
>
> She can then 'directly' pay Bob, without any need for change.
> Some time in the future, maybe even after receiving more coin, she can
> then rearrange her wallet to again have the coins she needs to be able
> to pay any desired amount. This usually will only involve a small subset
> of her coins to the "split" again. By this, we think, the issuer doesn't
> get even a trace of the transaction, so resolving a A to Alice isn't
> even a question (and allows us to require authentication for doing
> exchange, if so desired by e.g regulators).


I still don't get how, at all.  Suppose I have denominations that are
powers of two (1 EUR, 2 EUR, 4 EUR, 8 EUR).  I only _have_ 8 EUR in
total.  I withdraw 8 EUR.  Now, if you give me 8x 1 EUR, you're linear
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.

What you _could_ do is return the 4 EUR into my bank account
(deposit-to-self) and then withdraw 1 EUR pieces again (in the
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
using a special protocol that reveals the original blinding factor, but
then you end up allowing the exchange to link the change amount to my
identity (you call it "split", and the specific split set relates to the
change amount), thereby reducing the anonymity level.

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.

> Have a nice new years eve!
> 
>   Joerg
> 
> [1]
> https://github.com/OpenCoin/opencoin-js/blob/master/jsclient/ocapi.js#L148
> or
> 
> I can't tell much about the efficiency of the code - I wrote it, it's
> tested to be working, it seems to be good enough (works for me, cough,
> cough), but I am still not ably to explain _why_ it works. It's magic ;-)
> 

Oh oh.  In fact, I'm not worried about getting change to _work_. I'm
worried about how you got it to work in a way that does not negatively
impact either income transparency/taxability OR anonymity OR performance
(specifically O(log n) vs. O(n)).  And to assess that, I'd really like
to have a proper write-up explaining _how_ it is _supposed_ to work.

signature.asc
Description: OpenPGP digital signature