diff options
Diffstat (limited to 'design-documents/041-wallet-balance-amount-definitions.rst')
| -rw-r--r-- | design-documents/041-wallet-balance-amount-definitions.rst | 17 |
1 files changed, 10 insertions, 7 deletions
diff --git a/design-documents/041-wallet-balance-amount-definitions.rst b/design-documents/041-wallet-balance-amount-definitions.rst index a7c1202a..9a1eec79 100644 --- a/design-documents/041-wallet-balance-amount-definitions.rst +++ b/design-documents/041-wallet-balance-amount-definitions.rst @@ -53,24 +53,27 @@ For withdrawal: FIXME(dold): 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: +For deposits (where there is no contract that already specifies an amount): -* ``max-mode``: The instructed amount is ignored (can be zero in the request), and all coins are spent +* ``max-mode``: The instructed amount is ignored (can be zero in the request), and all coins are spent (note that the calculation should be made available when the user is asked to specify an amount when using a template) * ``raw-mode`` (default): The instructed amount is what will be paid to the "merchant" (or the customer's bank account), ignoring wire fees -* ``effective-mode``: The instructed amount is how the wallet's balance will be affected. Difficult to compute accurately because refresh is involved. +* ``effective-mode``: The instructed amount is how the wallet's balance will be affected. Difficult to compute accurately because refresh is involved. Note that the calculation should ideally again be made available when the user is asked to specify an amount when using a template. + For peer-push-debit: * ``raw-mode`` (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-mode``: Instructed amount is the effect on the material balance. Difficult to compute accurately because refresh is involved. -* ``counterparty-effective-mode``: Instructed amount is the effect on the counterparty's wallet balance. +* ``counterparty-effective-mode``: Instructed amount is the effect on the counterparty's wallet balance. Difficult to compute accurately because coin selection by receiver may not match our expectations. -FIXME(dold): 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 +FIXME(dold): 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. FIXME(grothoff): isn't this the counterparty-effective-mode you described above, and that would seem to exactly have this issue? For peer-pull-credit: -* ``raw-mode`` (default): Amount that the other party has to put in the reserve, where the other party has to pay deposit fees -* ``effective-mode``: Amount that be added to on the initiator's balance +* ``raw-mode`` (default): Amount that the other party has to put in the reserve. The payer has to pay any deposit fees on top. The receiver balance is increased by the specified amount minus any withdraw fees. +* ``effective-mode``: Amount by which the initiator's balance is increased. Difficult to compute as the receiver has to simulate different coin selections and their effect on withdraw fees to arrive at the minimum total amount that must be deposited into the reserve. + + Illustrative Example -------------------- |