-
Notifications
You must be signed in to change notification settings - Fork 16
Wizard should not reuse internal account #129
Comments
Thank you Fred for your input here. So from my understanding now
Can you elaborate on how this will lead to a loss of funds? |
Your understanding is correct. We have two things here. Can we reuse for funding? Then we need to do it by an metamask account. Can we reuse to start raiden? Certainly. This is how the wizard works now already. What we cannot do is, redeem any funds nor does the user currently know where the account and the passphrase is stored. This leads actually to the fact that the user can close all channels by the WebUI but the user actually cannot send it to its metamask account or somewhere else. Thus, if the user does not know where the keystore or the passphrase is stored, can lead to the loss of funds. Another point, which is coming to my mind. If the funds are too low, the user indeed will be redirected to top up the funds by doing BC transactions outside of raiden. If this confuses raiden in any way then it would temendously increase the difficulty of getting the funds back. (Probably only by closing channels manually via etherscan). I hope this helped |
Wouldn’t it be easier (at least for now) to go with the second proposal from #123 and make the wizard not immediately launch Raiden on subsequent starts? |
What do you mean by second proposal? Do you mean the second bullet point? I think #123 are observations how the wizard currently works. The user should at least be able to find its keystore IMO. He could then transfer his tokens to other accounts |
ok, good that we are at a point where we can discuss those things and act iteratively upon. Here are still several problems together from what I see. Let's try to break the open issues down in as many small changes as possible. Please add to this comment if you see more open points. (I will then transfer this to a meta issue).
|
Based on your last point: We also had the discussion if the user is supposed to run raiden always with the wizard (there is a difference between he can run the wizard a second time (nothing breaks) and he should ). One point I just realized. If everything should happen in the WebUI as you mentioned, we are gonna run into the nonce problem again. We can only top up, deposit, etc... while raiden is not running. If we want to do everything by the WebUI then there must be a way that either raiden is doing the transactions or the WebUI is running while raiden isnt. |
The WebUI only works via API calls to Raiden itself. So the actual swap and call would happen in Raiden indeed |
this can be close due to the note by @ulope that the internal account can be used as long as raiden is not running (which should be implicit if you want to start raiden through the use of the wizard) |
As described by @konradkonrad in #123 the user only has the chance to control the internal account and fund it at the first run of the wizard.
After that the user is on its own to figure out how to use raiden again and get his funds back. As @Dominik1999 mentioned the wizard is currently designed to only set up raiden initially and is not designed to be reused.
This leads to a potential loss of funds.
Furthermore the internal account should not be used outside of Raiden. If we want to exchange for new token, as well as, top up the UDC which should be somehow possible, then the current wizard cannot be reused as the internal account does all the work.
Handle internal account funds by external Metamask account
One potential solution would be, that the whole process of interacting with the blockchain to set up the internal account is controled by an metamask account. this process follows like funding the internal account with ETH. Instead of the internal account exchanging for RDN it could also be done by the metamask account and then directly send to the UDC on behalf of the internal account.
This functionality could also be placed in the WebUI of Raiden itself.
The downside is more clicks for the user in metamask to authorize transactions.
The text was updated successfully, but these errors were encountered: