Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Receipient should be able to approve/accept an incoming transaction #5

Open
HLXEasy opened this issue Apr 9, 2024 · 3 comments
Open
Assignees
Labels
bug Something isn't working enhancement New feature or request

Comments

@HLXEasy
Copy link
Contributor

HLXEasy commented Apr 9, 2024

Is your feature request related to a problem? Please describe.
To prevent any loss in case a receipient is not aware of his wallet right on Discord, it would be cool to have something like "accept incoming transaction" functionality.

Describe the solution you'd like
If one is tipped or something is transferred in general, there should be another option to activate "accept transaction". If this option is activated, the receipient gets notified about an incoming transaction and he must accept it. After this reaction, the transfer will be executed.

Additionally there should be a timeout like one hour/day/week/..., maybe with a default value but also configurable.

@tmrlvi tmrlvi self-assigned this May 28, 2024
@tmrlvi tmrlvi added bug Something isn't working enhancement New feature or request labels May 28, 2024
@tmrlvi
Copy link
Collaborator

tmrlvi commented May 30, 2024

The accept transaction mechanism already exists implicitly - if your DM are openned, you receive a DM if there are custodial funds for you. When you unlock a wallet for the first time, you receive all custodial funds that were sent to you. However, there is no timeout, which could lead to losing funds.

To support timeout, we need to change the structure saved in the custodial DB. Instead of saving the total owned, we should save both the from address, timestamp and timeout. In order the support it, we need to complete the following tasks:

  • Implement the new structure of the custodial wallet
    • Should we save only under the receiving key (then we need to go over all custodial funds every time)?
    • Under both? (Then we need to manage two lists for each key)
  • Add custody timeout to tip command
  • Implement custody checking
    • Does it happen every x minutes? When sender unlocks the wallet? When anyone interacts with the wallet?

@tmrlvi
Copy link
Collaborator

tmrlvi commented May 30, 2024

However, the more I think about it, the solution should be on the wallet level, using P2SH which allows either the custodial wallet to spend, or the sender to spend after timeout has passed. This is more intricate solution, but will be better down the line:

  • Build P2SH scripts that locks one address with timeout, where the timeout doesn't affect the address (using push commands)
  • For each custody output, save which utxo is allowed to be spent
  • Add release command to release unlocked funds (would be nice if we save the message IDs of the sending)
  • Subscribe for the public address of the share custody
    • Show the custody funds in /wallet info
  • Add option for automatic custody release

This way, users will have stronger control over the wallet, and can see how much funds they still have held in custody

@tmrlvi
Copy link
Collaborator

tmrlvi commented May 30, 2024

The second option requires #9

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants