View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007448 | Taler | wallet-core | public | 2022-11-10 13:51 | 2023-06-28 20:26 |
| Reporter | sebasjm | Assigned To | sebasjm | ||
| Priority | low | Severity | feature | Reproducibility | have not tried |
| Status | confirmed | Resolution | open | ||
| Target Version | post-1.0 | ||||
| Summary | 0007448: wallet operation that receive amount in the request should specify if the amount include fee | ||||
| Description | For example 1.- the user wants to withdraw all the KUDOS from the bank, the amount in the request is the raw amount 2.- the user wants to pay for an article, doesn't have enough coins, wallet redirect to the withdrawal operation, the amount in the request is the effective amount (just what need for the payment) The same happens to other commands: * deposit: the user may want specify the amount to send from the wallet or the amount to receive in the bank account * transfer and invoice also Since the fee is affected by the coin selection this is not an easy calculation that the user can do from the UI. Proposal: We have a prepare command for every operation (prepareWitdraw/GetFeeForDeposit/peer/...) this prepare command is being use to get information about the operation like the total fee. It will be enough to add the intention (semantic) of the amount in the prepare command, return the {effective,raw} amount and then always use the amount raw in the confirmation command. | ||||
| Tags | No tags attached. | ||||
|
|
Okay so what we want is for operations that take an *instructed* amount to also include some "mode" argument. But the *raw* and *effective* amounts are always interpreted the same. Can we agree on what we want these modes to be? For withdrawal, I can see: * raw (default): instructed amount is what is subtracted from the reserve balance (i.e. it's the raw amount) * effective: instructed amount is what the user wants to have as material balance in the wallet However, that does not really cover the user case where the merchant charges fees and the user has to pay for that. So in theory we could have a mode that withdraws enough to pay for some particular claimed order, but IMHO that's overkill. For deposits: * max: The instructed amount is ignored (can be zero in the request), and all coins are spent * raw (default): The instructed amount is what will be paid to the "merchant" (or the customer's bank account), ignoring wire fees * effective: The instructed amount is how the wallet's balance will be affected. Difficult to compute accurately because refresh is involved. For peer-push-debit: * raw (default): The instructed amount is what will be paid, deposit fees are covered by the sender, withdrawal fees from the reserve by the receiver * effective: Instructed amount is the effect on the material balance. Difficult to compute accurately because refresh is involved. Should we also have a mode where withdrawal fees are covered by the side that does peer-push-debit? However, that assumes the other party has the same withdrawal coin selection algorithm For peer-pull-credit: * raw (default): Amount that the other party has to put in the reserve, where the other party has to pay deposit fees * effective: Amount that be added to on the initiator's balance IMHO this is complex enough to warrant a new DD |
|
|
I've created DD41 with the above definitions as a starting point. |
|
|
As discussed two new concepts, instructedAmount could be origin-effective: how the balance is going to change with the operation destination-effective: how the balance/account is going to change with the operation Its going to be specified by the `mode` argument And new functions to validate input from the user checkPeerPushPayment(instructedAmount, mode) => AmountResult type AmountResult = InstructedAmountPossible | InstructedAmountNotPossible type InstructedAmountPossible = { type: "possible", amountEffective, amountRaw, } type InstructedAmountNotPossible = { type: "not-possible", closestHigher: { amountEffective, amountRaw, }, closestLower: { amountEffective, amountRaw, }, } |
|
|
this is going to be solved after DD41 is finished |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2022-11-10 13:51 | sebasjm | New Issue | |
| 2022-11-10 13:51 | sebasjm | Status | new => assigned |
| 2022-11-10 13:51 | sebasjm | Assigned To | => Florian Dold |
| 2023-02-17 02:53 | Florian Dold | Target Version | => 0.9.3 |
| 2023-03-30 11:27 | Florian Dold | Note Added: 0019992 | |
| 2023-03-30 11:27 | Florian Dold | Assigned To | Florian Dold => sebasjm |
| 2023-03-30 11:27 | Florian Dold | Status | assigned => feedback |
| 2023-03-30 12:18 | Florian Dold | Note Added: 0019996 | |
| 2023-03-31 15:56 | sebasjm | Note Added: 0019997 | |
| 2023-04-13 20:36 | Florian Dold | Category | wallet (TS core) => wallet-core |
| 2023-06-28 20:25 | sebasjm | Priority | high => low |
| 2023-06-28 20:25 | sebasjm | Status | feedback => confirmed |
| 2023-06-28 20:25 | sebasjm | Target Version | 0.9.3 => post-1.0 |
| 2023-06-28 20:26 | sebasjm | Note Added: 0020318 |
