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

[Christian Grothoff]

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.

0xE29FC3CC.asc
Description: application/pgp-keys

signature.asc
Description: OpenPGP digital signature