commit e0e7eca1b3042d6667013f1878831eb28d127007
parent 3aa9420469d0f3c55ac6b5863dc2e7b43d95e32d
Author: Iván Ávalos <avalos@disroot.org>
Date: Tue, 11 Aug 2026 17:47:24 +0200
dd92: mark the withdrawal family implemented, with the reserve reference
Diffstat:
1 file changed, 28 insertions(+), 13 deletions(-)
diff --git a/design-documents/092-incremental-backup-sync.rst b/design-documents/092-incremental-backup-sync.rst
@@ -898,10 +898,15 @@ Restoring the coin also recomputes the wallet's *coin availability* rows
(the counts the balance reads) from the restored coins, so a restored
wallet shows the same balance as the wallet that made the backup. The
reserves (and with them the ability to recoup a restored coin) are backed
-up by the ``add-reserve`` family; the withdrawal groups and the refresh
-groups are still not backed up, so pending withdrawals are not restored
-and a restored refreshed coin cannot be recouped-refreshed until the
-withdrawal and refresh families land (recoup of a withdrawn coin works,
+up by the ``add-reserve`` family, and the withdrawal family
+(``withdrawal-start`` / ``withdrawal-abort`` / ``withdrawal-done`` /
+``withdrawal-fail``, referencing the reserve by
+``[exchangeBaseUrl, reservePub]``) restores the withdrawal transactions
+themselves; a withdrawal that was still pending on the other device
+cannot have its in-flight bank leg continued, and the refresh groups are
+still not backed up, so a restored refreshed coin cannot be
+recouped-refreshed until the refresh family lands (recoup of a withdrawn
+coin works,
see the recoup discussion under "Add a reserve").
.. ts:def:: AddCoinInc
@@ -1054,21 +1059,28 @@ Start a withdrawal
User initiates a withdrawal.
+The increment references the reserve by ``[exchangeBaseUrl, reservePub]``
+(see the "Add a reserve" section): the restored wallet takes the reserve's
+key pair from the reserve record. The in-flight bank interaction of a
+pending withdrawal is not part of the backup -- only the constant
+parameters and the terminal increments travel, so a restored wallet shows
+the withdrawal's history (start, then done, failed or aborted), while a
+withdrawal that was still pending on the other device cannot have its bank
+leg continued here.
+
.. ts:def:: WithdrawalStartInc
interface WithdrawalStartInc {
type: "withdrawal-start";
withdrawalGroupId: string;
+ exchangeBaseUrl: string;
+ reservePub: EddsaPublicKey;
secretSeed: string;
timestampStart: TalerPreciseTimestamp;
restrictAge?: number;
- instructedAmount: AmountString;
+ instructedAmount?: AmountString;
}
-.. TODO: withdrawal-start references the reserve by [exchangeBaseUrl,
- reservePub] (see the "add-reserve" increment type below); the
- withdrawal families are blocked on it.
-
* **Primary key:** ``[withdrawalGroupId]``
* **Deletion groups:** ``[withdrawals]``
@@ -2359,10 +2371,13 @@ Definition of done
that predate the seed) is designed as described above; once implemented,
it restores the reserves' key material, which is what makes a restored
coin recoupable (see the recoup discussion under "Add a reserve").
- The withdrawal families are still blocked on the ``withdrawal-start``
- increment (referencing the reserve by ``[exchangeBaseUrl, reservePub]``)
- and the refresh groups are not backed up, so pending withdrawals are not
- restored; the token family is
+ The withdrawal families are implemented
+ (``withdrawal-start`` / ``withdrawal-abort`` / ``withdrawal-done`` /
+ ``withdrawal-fail``, referencing the reserve by
+ ``[exchangeBaseUrl, reservePub]``); a pending withdrawal's in-flight
+ bank leg is not portable, so only its history (and its coins) restore.
+ The refresh groups are not backed up, so a restored refreshed coin
+ cannot be recouped-refreshed; the token family is
blocked on a schema redesign: the increments in this document model
seed-derived tokens, while the wallet database now stores per-token key
material, so restoring from the documented increments could not produce
