path: root/design-documents/005-wallet-backup-sync.rst
diff options
authorTorsten Grote <>2020-05-21 11:14:22 -0300
committerTorsten Grote <>2020-05-21 11:14:22 -0300
commit95fa4f624ecce81fdc3b330fd713185001f2f957 (patch)
treea92ccac590dfef22981bf670119b905ae53701c4 /design-documents/005-wallet-backup-sync.rst
parent35fcd5e889e3a4578e1090c5fb8c1254342363b1 (diff)
Add more questions to design doc 5
Diffstat (limited to 'design-documents/005-wallet-backup-sync.rst')
1 files changed, 28 insertions, 1 deletions
diff --git a/design-documents/005-wallet-backup-sync.rst b/design-documents/005-wallet-backup-sync.rst
index d91c3ff..db46358 100644
--- a/design-documents/005-wallet-backup-sync.rst
+++ b/design-documents/005-wallet-backup-sync.rst
@@ -111,7 +111,7 @@ Multiple sync servers
When a wallet is connected to multiple sync servers, it automatically
propagates changes it received from one sync server to the others. Local
-changes made by the wallet are propoagated to all sync servers. The goal of
+changes made by the wallet are propagated to all sync servers. The goal of
this is to make the state of the sync servers converge.
The different sync servers one wallet is enrolled with do not necessarily
@@ -133,6 +133,9 @@ Discussion / Q&A
* For privacy reasons, we can't use some interactive sync service. Thus we
use the backup blob as a CRDT that also synchronization for us.
+* Do we need to handle backup/sync state becoming very large e.g. by many transactions
+ and embedded product images potentially exceeding service quota?
* Do we synchronize the list of other backup enrollments? How
do we handle distributing the different private keys for them?
@@ -145,16 +148,40 @@ Discussion / Q&A
* How do we handle a synced wallet that becomes malicious deleting all coins or purchased products?
* This needs to balance the genuine need to permanently delete data.
* Should the sync server allow to fetch previous versions of the sync blob?
+ (If not, how to provide backup functionality?)
* Should the individual wallets keep tombstones (i.e. entities just marked as deleted)
around for some time, or should they delete and "sanitize" (delete data not needed for the CRDT)
tombstones as soon as possible?
+* How do we make it easy to remove compromised devices from the sync group
+ and prevent them from getting access to future funds and transactions?
+ * We need to remove all sync connections on all connected devices
+ and then individually (and manually) add all devices to the new backup account.
+ * If we encrypted the key with each wallet's private sync key,
+ we could choose which wallets we want to migrate to the new sync account.
+ * Can we then roll-over wallets to the new account automatically
+ or does it have to be manually on each device to prevent an attacker to roll us over?
* How are wallets identified for backup/sync?
* UUID / EdDSA pub and nick name? When nickname clashes,
some number is added based on lexical sort of the random id ("phone#1", "phone#2").
+* How do we explain users that it can take days for wallet state to synchronize to all devices?
+* How are people supposed to securely store their backup account key(s)?
+ * There can be an option to print/export the QR code
+ * They can manually write down the taler:// Uri containing the key.
+ * Maybe encode the key in a different format such as
+ `BIP39 <>`__?
* Do we have a passphrase for our backup account key(s)?
* ???