[Top][All Lists]

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

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

From: Rune K. Svendsen
Subject: Re: [Taler] Support for payer-trustlessness and merchant-auditing
Date: Thu, 5 Oct 2017 21:13:34 +0200

Hi Sree,

> On 10/03/2017 08:49 PM, Rune K. Svendsen wrote:
>> So the customer would start out by sending e.g. 100 EUR-equivalent of
>> bitcoins to a 2-of-2 multi-signature address, where one key is owned by
>> the customer and the second key by the exchange. When the customer is
>> ready to pay a merchant, the customer transfers exactly the amount it
>> wishes to pay the merchant to the exchange, who then responds with a
>> token of that value that the customer can use to pay the merchant.
>> Have you considered a simpler design, where no blind signatures are
>> used, but the customer simply connects to the exchange via Tor, in order
>> to conceal its IP-address (in case it wants to maintain privacy)? In
>> this way, the only information the exchange gains is the ability to
>> group transactions by customer -- it learns nothing about the customer
>> itself except a source Bitcoin address (from which funds are sent to the
>> customer/exchange multi-sig address).
> What benefit does this provide when compared to the customer doing a
> blockchain transaction directly to the merchant?  I don't see why an
> exchange is needed here.

Doing a blockchain transaction directly to the merchant is costly and slow, 
because it happens on the Bitcoin blockchain.

By the consumer first sending the bitcoins to a multi-signature address, shared 
by the consumer and exchange, the consumer becomes able to send bitcoins 
instantly to the exchange (without going through the Bitcoin blockchain) by 
only transferring the signature over a Bitcoin transaction which incrementally 
assigns more and more value to the exchange’s bitcoin address (this 
construction is called a “payment channel”). This happens without touching the 
blockchain, so there are no associated fees (until the exchange publishes the 
final Bitcoin transaction to close the payment channel and receive its funds).

The purpose of the exchange is to route bitcoins, received from consumers 
connected to exchanges via payment channels, to merchants, when each merchant 
chooses to redeem the tokens/IOUs (issued by the exchange) it receives every 
time a consumer makes a payment. The parties to a payment channel (normally: 
sender and receiver) are set in stone (the blockchain), so paying a merchant 
this way isn’t useful since you’d need a payment channel (and thus a Bitcoin 
transaction in the blockchain) for every merchant you want to pay. The job of 
the exchange, as in Taler, is to act as an intermediary, which temporarily 
holds the received funds, and hands them over to the correct recipient 
(merchant) on demand. So the exchange acts as both a routing mechanism (a hub 
that directs funds as instructed by consumers), and a clearing system (reducing 
thousands or millions of payments into a single Bitcoin transaction).

Using this architecture, the consumer is shielded from the trustful 
relationship that must exist between exchange and merchant. Consequently, the 
merchant/recipient of funds becomes responsible for vetting exchanges, as 
opposed to the consumer/sender of funds. So rather than merchants — who stand 
to lose their income in case an exchange messes up — needing to trust the 
exchanges that consumers choose to trust, consumers choose whatever exchange 
that merchants trust, without standing to lose anything.


reply via email to

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