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

[Christian Grothoff]

Dear Rune,

In GNU Taler, the exchange is assumed to have an escrow account with
some underlying banking/settlement system (i.e. SEPA, ACH or Bitcoin).
We say that this system provides for wire transfers (in contrast to
Taler payments).

The exchange is expected to obtain a customer's signature before making
a wire transfer from its escrow account. The Taler auditor is a software
component that checks the customer's signatures and the exchange's wire
transfers and ensures that they match.

What is not exactly specified by the protocol (as it depends on the
specific implementation) is who is the auditor, and when does the audit
happen.  For example, one could imagine a wire transfer system that only
allows the exchange to make wire payments after checking the signatures.
Here, the wire transfer system would incorporate the auditor into its
logic. Today, SEPA cannot do this, but for example an Ethereum contract
for such an exchange could be written to enforce it for ETH.

For Taler running over a cryptocurrency, you would want such a contract
where the audit-compliance is enforced by the consensus mechanism.

For Taler running over a traditional fiat currency, I believe you would
want a state regulator and possibly some independent foundation to run
independent auditors, but for the sake of efficiency you would simply
run the audits continuously but probably not actually _prior_ to
effecting the wire transfers.  This is also what we are currently
implementing / have implemented.

As there can also be more than one auditor, in theory merchants could
also participate in the auditing.  However, auditing requires a copy of
the exchange's database and checking lots of signatures.  Given that an
exchange will have lots of transactions that a specific merchant doesn't
care about, having your typical merchant do the audit is simply
inefficient.  Hence I would generally assume that some independent
foundation and/or a government regulator are a better alternative.

I hope this answers your questions!

Happy hacking!

Christian

On 09/18/2017 09:11 PM, Rune K. Svendsen wrote:
> Dear fellow GNU Taler enthusiasts,
> 
> 
> In my opinion, GNU Taler is a great step in the right direction towards
> an open, ubiquitous internet payment system. For the past few years,
> I've been writing code with the goal of implementing the Stroem[1]
> payment system, which is very similar to GNU Taler. Both systems operate
> on essentially the same idea, which is consumers (payers) depositing
> funds with an "exchange" (in GNU Taler terminology) or "issuer" (in
> Stroem terminology), after which a payer can ask the exchange to issue a
> note which is redeemable (by the merchant) in whichever currency was
> deposited by the payer/consumer (and a reduced per-payment fee is
> achieved by merchants aggregating notes for redemption). GNU Taler
> interests me because it, in addition to what Stroem offers, adds
> anonymity for payers from snooping exchanges (via RSA blinding).
> 
> One thing, which I think is highly important, is allowing payers to
> connect via a trustless mechanism to the exchanges, such that unspent
> funds remain in control of the payer. With Bitcoin payments, this is
> possible using so-called "payment channels", and I've spent the past
> year or two implementing a payment channel server in Haskell, for this
> exact use[2] (open, RESTful protocol is documented here[3]). The idea
> behind a payment channel is fairly simple: rather than the payer
> depositing funds with the exchange (such that the exchange is in full
> control of the funds), the funds are sent to a Bitcoin address (an
> account, essentially) which requires a signature from *both* the payer
> and the exchange in order to transfer funds (from those deposited into
> the payment channel) to the exchange. This allows instant Bitcoin
> payments between two parties. One analogy from the world of banking
> would be a bank account where cheques, that transfer funds from this
> account, require the signature of both the payer and the payee (the
> exchange). This makes "bouncing" checks impossible, as the recipient of
> funds needs to sign the cheque as well in order for it to be valid. This
> construct makes it possible for payers to deposit funds with an
> exchange, while remaining in full control of it, and only signing over
> the amount required for each payment, when the payment occurs. It means
> that only the merchants (payees/payment receivers) take risks when they
> accept GNU Taler payments, instead of the payer/consumer also taking the
> risk that the exchange is hacked (and they thus lose their deposited
> funds). In my opinion, this is an important feature, because it means
> funds are stored in a decentralized manner, such that each payer's
> device needs to be compromised in order to steal funds (rather than only
> the exchange's wallet).
> What is your view on this? Does the GNU Taler protocol already allow
> payers to deposit funds using this mechanism, or would the protocol need
> to be changed for this to be supported?
> 
> Another remark I have (a relatively minor one compared to allowing
> trustlessness for payers), is allowing merchants (and not just a
> government regulatory body) to audit exchanges (this would be
> particularly relevant for merchants located in countries with unreliable
> government institutions). Since merchants are the recipients of
> payments, they have a huge incentive in making sure that exchanges are
> honest, and consequently they should be able to audit the exchanges they
> choose to use, in my opinion. Is this supported by the GNU Taler protocol?
> 
> 
> I look forward to hearing from you.
> 
> 
> Sincerely,
> Rune K. Svendsen
> 
> 
> [1] https://www.strawpay.com/docs/stroem-payment-system.pdf
> [2] https://github.com/runeksvendsen/rbpcp-handler
> [3] http://paychandoc.runeks.me/

signature.asc
Description: OpenPGP digital signature