taler-docs

Documentation for GNU Taler components, APIs and protocols
Log | Files | Refs | README | LICENSE

061-batched-withdraw.rst (1803B)


      1 DD 61: Batched Withdraw
      2 #######################
      3 
      4 :Design status: Accepted
      5 :Implementation status: Implemented
      6 :DD shepherd: TBD
      7 :Historical contributors: Özgür Kesim
      8 :First published: 2025-04-12
      9 :Last substantive change: 2025-04-12
     10 :Implementation evidence: taler-typescript-core (2022-05-03), exchange (2025-01-09)
     11 :Normative references: ``core/exchange/post-withdraw.rst``
     12 
     13 .. note::
     14 
     15    This DD was reserved as a design placeholder and was never expanded.  The
     16    current ``POST /withdraw`` specification is normative and supersedes the
     17    former endpoint named ``batch_withdraw``.
     18 
     19 Summary
     20 =======
     21 
     22 We replace the previous single-coin withdraw protocol with a variant that
     23 allows for batched withdrawal of multiple coins in only one (or two, in case of
     24 Clause-Schnorr) roundtrips.
     25 
     26 Motivation
     27 ==========
     28 
     29 The original single-coin withdraw requires too many roundtrips, one for each
     30 coin, whenever a client wants to withdraw multiple coins.
     31 
     32 
     33 Requirements
     34 ============
     35 
     36 One idempotent request must be able to withdraw multiple coins from the same
     37 reserve.
     38 
     39 Proposed Solution
     40 =================
     41 
     42 Use the current ``POST /withdraw`` request with arrays of denominations and
     43 coin envelopes, as specified by the normative exchange API.
     44 
     45 Definition of Done
     46 ==================
     47 
     48 * [x] batched withdrawal implemented by wallet-core
     49 * [x] current ``POST /withdraw`` endpoint specified and implemented
     50 * [x] former ``batch_withdraw`` endpoint removed
     51 
     52 Alternatives
     53 ============
     54 
     55 Retain one request per coin, with the associated extra round trips.
     56 
     57 Drawbacks
     58 =========
     59 
     60 The request and response are larger and clients must persist all coin inputs
     61 before sending the request.
     62 
     63 Discussion / Q&A
     64 ================
     65 
     66 (This should be filled in with results from discussions on mailing lists / personal communication.)