[Top][All Lists]

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

Re: [Taler] replay and merchant backend/frontend protocol

From: Florian Dold
Subject: Re: [Taler] replay and merchant backend/frontend protocol
Date: Tue, 26 Jan 2016 01:15:34 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

On 01/26/2016 12:09 AM, Florian Dold wrote:
> On 01/26/2016 12:01 AM, Christian Grothoff wrote:
>> Well, in any case we need to very clearly define what the backend has to
>> store.  Right now, the merchantdb only stores hashes of the contracts
>> that have been paid, and never stores _anything_ just for the /contract
>> requests.
>> What you suggest now will make /contract requests significantly more
>> expensive, as even unpaid contracts will require a database transaction.
>>  If we store
>>  h_contract -> contract or
>>  h_contract -> (contract, frontend_data)
>> is almost irrelevant here.  For me, the real issue is that the merchant
>> frontend can no longer assume that /contract requests are virtually free
>> (we can probably do 10k EdDSA signatures/s, but only way fewer
>> transactional DB commits/s).

The alternative would be, of course, that the wallet always has to
provide the full contract (the frontend extracts the information, after
asking the backend whether then signature is valid).

Then /contract would be "free" again, and we only have storage costs on
*actual* payment.

This might actually nicer, since there is less DoS potential, making the
merchant store something will have costs associated with it.

So it's a trade-off between customer<->merchant traffic and the
merchant's storage cost.

- Florian

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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