View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006077 | Taler | wallet-core | public | 2020-02-04 22:13 | 2023-08-24 16:27 |
| Reporter | Christian Grothoff | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | acknowledged | Resolution | open | ||
| Platform | i7 | OS | Debian GNU/Linux | OS Version | squeeze |
| Product Version | git (master) | ||||
| Target Version | post-1.0 | ||||
| Summary | 0006077: sync support needed in wallet core | ||||
| Description | The 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. | ||||
| Tags | No tags attached. | ||||
|
|
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)? |
|
|
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) |
|
|
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? |
|
|
1.1: I'd say not at all. We should show the overall balance, sync groups should be managed "behind the scenes". |
|
|
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). |
|
|
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. |
|
|
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. |
|
|
After thinking about it some more: How would the per-wallet key work with Anastasis? Isn't that fundamentally incompatible? |
|
|
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. |
| 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 |
