View Issue Details

IDProjectCategoryView StatusLast Update
0006077Talerwallet-corepublic2023-08-24 16:27
ReporterChristian Grothoff Assigned To 
Status acknowledgedResolutionopen 
Platformi7OSDebian GNU/LinuxOS Versionsqueeze
Product Versiongit (master) 
Target Versionpost-1.0 
Summary0006077: sync support needed in wallet core
DescriptionThe operations that should be provided (here described as command-line options for the CLI wallet) are:

0) sync --info-by-url $URL: obtain fee structure and other high level terms (warranty, etc.)
1) sync --create $URL: setup a new sync account (and pay for it!)
2) sync --info: show meta data of current account (fees, paid until, warranty, etc.)
3) sync --show: display a URI (taler://sync/$URL/$SECRET) with the information needed to join a sync group / download a backup
4) taler-wallet-cli taler://sync/$URL/$SECRET: join the sync group (download, merge, upload to notify other members of join)
5) sync [nothing]: synchronize NOW with the active sync/backup service (try upload, if fail download, merge, upload)
6) sync --reserve $AMOUNT: reserve $AMOUNT money (in the respective currency) for *this* wallet
7) sync --leave ($AMOUNT)* leave the sync group, taking $AMOUNT funds out of the joint funds. $AMOUNT may be
   specified multiple times for different currencies.

Let me know if something is unclear, or extend/add to the list in case I missed something.
TagsNo tags attached.


Florian Dold

2020-09-04 09:06

manager   ~0016834

The CLI for this looks mostly good to me (modulo questions below). Except that the "--..." options should actually subcommands. But that's a pervasive usability problem in many binaries of GNUnet and Taler, because the library we use in C for CLI parsing doesn't handle subcommands nicely </rant>.

Regarding starting the implementation of sync: what we actually need is primarily the wallet-core JSON API for all those things. I'll write these docs after we've clarified some other issues. The CLI will follow from that.

# 1. Balances

1.1 How does this affect the balance, both in terms of API and UI? WIll we only show the "reserved" amount?
1.2 Do balances now need to include some timestamp(s) that show how current they are? Sync otherwise might lead users into thinking they have more money than they actually do ...
1.3. How does this affect the coin selection for payments? What happens if the current wallet's reserved balance is too low, but the sync group's balance is high enough to pay?

# 2. Funds reservation

2.1 Does the funds reservation imply a sync, or is it only done locally? Do other devices somehow acknowledge the reservation?

# 3. Device identifiers and encryption

3.1. I'm assuming in the first implementation, a "rogue" device won't be able to be kicked out of the sync group, right? So we don't do any encryption with the some per-device key, we just use the sync key.

# 4. Payments

4.1. Does the user need to confirm the payment to create the sync group? What if the contract terms contain a different amount than what's advertised by the sync server?
4.2. Does the user need to confirm subsequent payments for the sync server to extend the service duration?
4.3. What happens if two wallets in a sync group pay to extend the sync service? Will the 402 always give the same order (=> other wallets receive "order already claimed)?

Christian Grothoff

2020-09-04 10:06

manager   ~0016836

1.1: sync may cost money, if it does, it's a purchase.
1.2: I'd say no. We could store the # devices in the sync group, and if >1 we could do a GET request against the sync service at a reasonable frequency (say on Wallet start, unless started "just before"?). I'd not show a timestamp.
1.3: We grab from the sync group and POST to sync as soon as possible (but after the payment)

Florian Dold

2020-09-04 11:38

manager   ~0016837

Regarding 1.1: This question wasn't related to how the *payment* for sync will show up, but how being in a sync group will affect the balance that is shown. Or to rephrase the question: How will reserving funds from the sync group affect the balance display?

Will it even affect the balance display / API response, or is it an internal thing completely transparent to the user, and just used to reduce (not completely prevent!) spending conflicts?

Christian Grothoff

2020-09-04 12:55

manager   ~0016838

1.1: I'd say not at all. We should show the overall balance, sync groups should be managed "behind the scenes".

Christian Grothoff

2020-09-04 14:49

manager   ~0016849

2.1: Funds reservation is 'soft' anyway, it just means that a wallet will preferentially spend certain coins over others. So I would say any wallet in a sync group can 'grab' a coin (or even assign it to another wallet in the sync group, i.e. on withdrawal), and the latest grab counts (so grabs must have: coin_pub + wallet_id + timestamp). I'd treat grabs like any other wallet-operation (withdraw, pay, refresh) in terms of sync behavior: randomized reduction in the time to the next backup per operation might be a reasonable strategy.

3.1: Why not have a header (encrypted with sync key) that has a list of all participating wallets and then a backup key encrypted *to* all wallet private keys, followed by the actual wallet data encrypted with the backup key? Sounds not too hard, and why not do it right immediately?

4.1a: Yes, but simply have the normal dialog contain the word "confirm payment" in the button and the amount next to it. No need for a 'full' regular pay dialog IMO.
4.1b: That's a protocol violation. Treat it as such and tell the user the sync server failed to respond properly.

4.2: I'd have a checkbox 'auto-renew'. If payment is not possible OR if auto-renew is off, 1 month before expiration we should have an alert on the main screen about the impending expiration of the backup enabling manual renewal.

4.3: We should always force a sync between auto-renew claiming and payment to prevent this. The sync server cannot tell if you want to extend by +1 year, so it will create a fresh order. So simply claim, sync, and if you do not find another claimed order in the DB, then pay (or pay the earliest claimed order in the freshly sync'ed DB).

Florian Dold

2020-09-04 16:34

manager   ~0016856

2.1. brings me to the crypto. Why not just use a HKDF and libnacl/libsodium crypto_(secret)box? Pulling in AES (and using it in what mode? ;-) ) will add more, potentially unaudited dependencies and is *much* easier to use incorrectly.

Christian Grothoff

2020-09-05 00:14

manager   ~0016862

2.1: nothing against HKDF+cryptobox for the 'inner layer', but we need some 'outer layer' to allow adding/removing wallets from the sync group, including telling a wallet that it has been removed. So I don't think we can do without some DH between each group member's private key and some ephemeral key chosen by the last wallet to publish the backup.

Florian Dold

2020-09-10 08:09

manager   ~0016958

After thinking about it some more: How would the per-wallet key work with Anastasis? Isn't that fundamentally incompatible?

Christian Grothoff

2020-09-10 09:19

manager   ~0016959

Last edited: 2020-09-10 09:22

Easy solution: Imagine W1 / W2 / W3 are the per-wallet keys and A is the Anastasis key (A_priv in Anastasis) and the actual symmetric encryption key of the main wallet state is K.

Then, we could store W1_pub, W2_pub, W3_pub, A_pub and an _encrypted_ K in the sync data preamble encrypted with DH(W1,A), DH(W2,A), DH(W3,A).

Note that K can here not change on every encryption, so we'd need an additional IV (or IMO better: salt and KDF via salt) before encryption with traditional AEAD/GCM.

Kicking a wallet out of the device group requires changing K, and so a new Anastasis policy upload. But that is rare and thus should be Anastasis-compatible.

Issue History

Date Modified Username Field Change
2020-02-04 22:13 Christian Grothoff New Issue
2020-02-04 22:13 Christian Grothoff Status new => assigned
2020-02-04 22:13 Christian Grothoff Assigned To => Florian Dold
2020-08-20 08:03 Florian Dold Category wallet (JS core) => wallet (TS core)
2020-09-04 09:06 Florian Dold Note Added: 0016834
2020-09-04 09:07 Florian Dold Assigned To Florian Dold => Christian Grothoff
2020-09-04 09:07 Florian Dold Status assigned => feedback
2020-09-04 10:06 Christian Grothoff Note Added: 0016836
2020-09-04 11:38 Florian Dold Note Added: 0016837
2020-09-04 12:55 Christian Grothoff Note Added: 0016838
2020-09-04 14:49 Christian Grothoff Note Added: 0016849
2020-09-04 16:34 Florian Dold Note Added: 0016856
2020-09-05 00:14 Christian Grothoff Note Added: 0016862
2020-09-05 00:59 Christian Grothoff Assigned To Christian Grothoff => Florian Dold
2020-09-05 00:59 Christian Grothoff Status feedback => assigned
2020-09-06 11:53 Christian Grothoff Target Version 0.8 => 0.8.1
2020-09-10 08:08 Florian Dold Assigned To Florian Dold => Christian Grothoff
2020-09-10 08:09 Florian Dold Note Added: 0016958
2020-09-10 09:19 Christian Grothoff Note Added: 0016959
2020-09-10 09:22 Christian Grothoff Note Edited: 0016959
2020-09-10 09:23 Christian Grothoff Assigned To Christian Grothoff => Florian Dold
2021-03-29 12:16 Florian Dold Target Version 0.8.1 => 0.8
2021-08-23 17:35 Christian Grothoff Target Version 0.8 => 0.8.5
2022-10-20 10:45 Christian Grothoff Target Version 0.8.5 => 0.9
2022-10-20 11:25 Christian Grothoff Target Version 0.9 => 0.9.1
2022-12-20 18:29 Christian Grothoff Target Version 0.9.1 => 0.9.2
2022-12-20 19:25 Christian Grothoff Target Version 0.9.2 => 0.9.3
2023-02-17 18:05 Florian Dold Target Version 0.9.3 => 0.10
2023-04-06 14:45 Florian Dold Target Version 0.10 => post-1.0
2023-04-13 20:36 Florian Dold Category wallet (TS core) => wallet-core
2023-08-24 16:27 Florian Dold Assigned To Florian Dold =>
2023-08-24 16:27 Florian Dold Status assigned => acknowledged