[taler-docs] 01/02: Add more questions to design doc 5

[gnunet]

This is an automated email from the git hooks/post-receive script.

torsten-grote pushed a commit to branch master
in repository docs.

commit 95fa4f624ecce81fdc3b330fd713185001f2f957
Author: Torsten Grote <address@hidden>
AuthorDate: Thu May 21 11:14:22 2020 -0300

    Add more questions to design doc 5
---
 design-documents/005-wallet-backup-sync.rst | 29 ++++++++++++++++++++++++++++-
 1 file changed, 28 insertions(+), 1 deletion(-)

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 <https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki>`__?
+
 * Do we have a passphrase for our backup account key(s)?
 
   * ???

-- 
To stop receiving notification emails like this one, please contact
address@hidden.