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

Bricked Account Recovery #46

Open
piotr-dziubecki opened this issue May 12, 2021 · 5 comments
Open

Bricked Account Recovery #46

piotr-dziubecki opened this issue May 12, 2021 · 5 comments

Comments

@piotr-dziubecki
Copy link
Contributor

piotr-dziubecki commented May 12, 2021

Accounts can accidentally send money to the wrong address. There should be a mechanism for recovering funds lost this way provided there is community buy-in.

@xcthulhu xcthulhu changed the title Bricked account - CEP design Tracking Issue For Bricked Account Recovery Jun 7, 2021
@xcthulhu xcthulhu changed the title Tracking Issue For Bricked Account Recovery Bricked Account Recovery Jun 7, 2021
@SamuelSchlesinger
Copy link

This is incredibly problematic. It seems to me that it necessarily increases the effective confirmation time for users to the amount of time users are allowed to wait until requesting a refund.

@SamuelSchlesinger
Copy link

One can introduce a contract on-chain for managing these types of revocable transactions in many different ways (depending on individuals desires/needs), it need not be built into the protocol.

@goral09
Copy link
Contributor

goral09 commented Sep 13, 2021

One can introduce a contract on-chain for managing these types of revocable transactions in many different ways (depending on individuals desires/needs), it need not be built into the protocol.

Thank you for joining the discussion. Do you know how other projects solve this problem? Like Ethereum, Cardano, BSC, Polkadot, Solana, etc.?

@KillianH
Copy link

KillianH commented Apr 3, 2022

One can introduce a contract on-chain for managing these types of revocable transactions in many different ways (depending on individuals desires/needs), it need not be built into the protocol.

Agree. This problem is on every blockchain. The only real solution is to improve UX/UI but this problem will always happen. People make mistakes.

@GuybrushX
Copy link

I think this is something which should be discussed a bit further since it can cause a significant and non-recoverable loss very easily. I also know of 1 individual who transferred a pretty decent amount to a wrong address. IIRC the mistake was that the recipient's wallet address was somehow pasted twice on cspr.live which was accepted and resulted in the wrong wallet.

Some thoughts/ideas:

  • Transfers could be made "transactional" like in a SQL database: either the sender and/or the receiver could be required to "commit" and thereby confirm and accept the (pending) transfer -> this could be optional. It would allow the sender/receiver to check a pending transaction and if everything looks OK it can be confirmed. There could be a (configurable?) timeout after which the transfer will be refunded to the sender if it's not confirmed. It could also be added the option to cancel such a transaction as long as it wasn't confirmed by the sender/receiver. There probably needs to be a deeper discussion about this and some typical scenarios - including potential security concerns. I'm happy to join that discussion and contribute.
  • Checksummed addresses are another way but they don't catch cases when the wrong address is used - similar to the IBAN system: if the receiver doesn't return your funds they are just gone.
  • ENS (Ethereum Name Services) are another solution but they also don't catch a copy & paste error or a typo - also not sure if they check that the address exists so not ideal as well

For me my idea sounds like a pretty easy solution - actually so easy that I don't know why it's not implemented by everyone already ;-)

Did I miss something?
Any security/abuse concerns?
What are your thoughts on that idea?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants