[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.
Sincerely,
Rune