[Top][All Lists]

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

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

From: Christian Grothoff
Subject: Re: [Taler] replay and merchant backend/frontend protocol
Date: Tue, 26 Jan 2016 08:51:16 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0

On 01/26/2016 01:15 AM, Florian Dold wrote:
> 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.

Yeah, except that the upstream bandwidth is usually much smaller, so
having the wallet send the contract back is really bad.

> 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.

Let's put it in the merchant for now.  We may add the other possibility
later as an optimization for sites where contracts are very low-value
and simple, and where thus sending it back would be inexpensive and the
DDoS potential is more relevant.

Attachment: 0xE29FC3CC.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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