Skip to content
This repository has been archived by the owner on May 28, 2021. It is now read-only.

[protocol, card, client] Unrolled Deposit #462

Closed
ArjunBhuptani opened this issue Oct 20, 2019 · 5 comments
Closed

[protocol, card, client] Unrolled Deposit #462

ArjunBhuptani opened this issue Oct 20, 2019 · 5 comments
Assignees
Labels
Enhancement New feature or request p2: User Shipping Needs Important (but minimal) refactors/enhancements/fixes needed for customers

Comments

@ArjunBhuptani
Copy link
Member

Separate out the deposit commitment from the onchain deposit transaction itself.

WIP: counterfactual/monorepo#2516

@ArjunBhuptani ArjunBhuptani added Enhancement New feature or request p2: User Shipping Needs Important (but minimal) refactors/enhancements/fixes needed for customers labels Oct 20, 2019
@ArjunBhuptani ArjunBhuptani changed the title [protocol] Unrolled Deposit [protocol, card] Unrolled Deposit Oct 22, 2019
@ArjunBhuptani ArjunBhuptani changed the title [protocol, card] Unrolled Deposit [protocol, card, client] Unrolled Deposit Oct 22, 2019
@ArjunBhuptani
Copy link
Member Author

This should also include the necessary changes to client/card to support the new deposit type.

Doing so will fix a lot of the pesky bugs we're seeing with autodeposit int he card too

@rhlsthrm
Copy link
Contributor

Implementation details from Liam:

  • Create a new controller on cf-core that looks similar to the deposit/withdraw controllers (INSTALL_BALANCE_REFUND).
  • The controller will install a balance refund app and set a flag in the channel saying that the balance refund app is installed.
  • Create another controller that removes the balance refund app and sets the flag to false.
  • Deposit and withdraw should throw errors if they are called when the balance refund app is installed. An alternative approach is to make those controllers smarter and automatically do the uninstall.

Indra implementation of these controllers:

  • The client can always have the balance refund app installed unless the hub is depositing.

@rhlsthrm
Copy link
Contributor

For the edge case where there is a small window when async deposit can be wrongly credited to the hub, use the following workaround:

  • Hub checks free balance before deposit
  • If free balance after - free balance before > deposit amount, credit back to client's channel

@rhlsthrm
Copy link
Contributor

rhlsthrm commented Dec 4, 2019

New updates to feature:

  1. remove timeout from client API
  2. remove any rescinding logic from the hub
  3. add checks in the hub to refuse to deposit if the user has a coin balance refund app installed
  4. on daicard make the timer a button (should display something like
if (coinBalanceRefundAppInstalled with recipient == user) {
   ready to accept deposits
} else {
   deposit inactive
}
  1. Add check on load in daicard for the multisig balance:
if (multisigBalance > threshold) { uninstall } else { listener for asset id }
  1. The UI tests will need fixing

@rhlsthrm
Copy link
Contributor

The primitive functions are already in the client so the use case can be supported at the app layer. Closing this issue.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Enhancement New feature or request p2: User Shipping Needs Important (but minimal) refactors/enhancements/fixes needed for customers
Projects
None yet
Development

No branches or pull requests

2 participants