taler
[Top][All Lists]
Advanced

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

Re: [Taler] Support for payer-trustlessness and merchant-auditing


From: Jeff Burdges
Subject: Re: [Taler] Support for payer-trustlessness and merchant-auditing
Date: Tue, 03 Oct 2017 18:43:13 +0200


On Tue, 2017-10-03 at 14:18 +0200, Rune K. Svendsen wrote:
 
>         You cannot naively use multi-signature bitcoin wallets with
>         Taler
>         because they would break the anonymity and increase costs.
> 
> 
> Can you expand on this a bit? What I don't understand is that if we
> assume that the customer starts out by sending funds to the exchange's
> Bitcoin address (non-multisignature) as an initial deposit, surely it
> would need to reference this account/address when later making
> payments, otherwise the exchange wouldn't be able to know whether the
> customer in question actually has any funds to spend, right?

You can fund a Taler withdrawal with a multi-signature transaction of
course, but you gain no benefit by doing so.  

A Taler exchange must be satisfied that the customer irrevocably
transfered the funds before permitting withdrawal because..  

> As far as I can see, each individual payment from the customer needs
> to reference some initial deposit -- from which the payment spends --

Only the customer's wallet ever knows which deposit corresponds to which
withdrawal. 


If you want the mathematics behind blind signatures: 

Let (n,e,d) be the RSA key for some coin denomination issued by our
exchange.

At withdrawal, the wallet computes two numbers mod n called m :=
FDH_n(C) and b, with b pseudo-random.  I'll skip explaining FDH_n(C),
but we believe both m and b cannot be distinguished from uniformly
distributed random numbers mod n.  

Our wallet first pays the exchange the denomination's value and asks the
exchange to sign m b^e, obtaining (m b^e)^d = m^d b mod n, from which it
computes s := m^d = (m^d b) / b mod n. 

At deposit, the exchange redeems the coin (C,m) by verifying that s^e =
FDH_n(C) and marking the coin as spent.  

Information theoretically, the only linkage between m^d b and m^d is
this "blinding factor" b, which we think is indistinguishable from
random and only known by the client.

>  but I don't see how referencing a single-signature account is any
> less anonymity-breaking than referencing a multi-signature account. 

As I said, there are schemes like BOLT that attempt to reference actual
transactions in some zero-knowledge way, but they are subject to nasty
deanonymization attacks when one party drops the transaction.  

There are really no schemes besides blind signatures with this
information theoretic anonymity for the customer.  We do leak
information about the amount spent through the choice of denominations
spent of course.  Otoh, schemes like ZCash that hide the amount
seemingly leak information to epistemological attacks on what portions
on the blockchain you know.  As the scheme scales up, our leakage
becomes less important while ZCash's becomes worse.

Jeff

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


reply via email to

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