As we all know, the nodes we set up have a wallet address, but we do not have mnemonic. We need to take a backup of the db file. db file is not safe even if we back it up. Our node wallet address changes with each node setup. It should be a web wallet instead. 12 words are mine. We just need to install the Node by entering the identity key of our wallet address. To put it briefly, I think our wallet should not be in a node.
6 Likes
I like this idea, with this we wont also lose our xhopr and xdai which is on node??
I would prefere a metamask option, where I can lock my tokens for a specific node (or node address). Something similar to the h0pR-staking-Interface.
Yes, you can’t lose both. You already send xdai and xhopr to the same wallet.
bot
March 14, 2022, 7:50am
5
This is certainly a pain point, and there has been some thinking on this before:
opened 07:26AM - 27 Aug 21 UTC
closed 08:37AM - 12 Sep 23 UTC
epic
# Background
Currently, `hoprd` submits transactions on-chain by relying on t… he private key that's generated upon creation or previously loaded (i.e. `hopr-identity`). In effect, this means that `hoprd` actually loads a wallet, which does the following:
- Populate the transactions data to be submitted on-chain
- Sign the transaction to be submitted
- Keep track of the nonces sent and confirmed in the blockchain
- Keep track of the transactions submitted and their results (via Indexer)
Initially, this was trivial as most on-chain operations were done manually or via the `hopr-admin` panel, which usually left enough time between transactions to allow a cool-off period before nonces could be replicated. As we continued to refine the protocol, more on-chain activity was done automatically or via the REST API, leaving issues where transactions would not be sent or nonces would be re-used. Solving these issues requires now defining a proper spec for this automatic signature wallet behavior, as there's currently not an existing EIP or ERC that handles this requirement.
# Introduction
This epic is meant to be a catch-all for everything related to our wallet/nonce/transaction manager. The goal is to define the existing pain points while putting together a list of requirements for the wallet. These requirements need to be confirmed by the team members, and afterwards used to put a spec on how to implement them.
# Task Description
- [ ] Define a list of requirements for our existing in-house wallet as currently used by `hoprd`
- [ ] Define the blockchain requirements for HOPR to be used effectively by an auto-sign wallet
- [ ] Create a specification design for the auto-sign wallet as per the list of requirements
- [ ] Create the actionable epic that will tackle the first iteration of the wallet overhaul
# Additional notes
It's not clear when it's adequate to tackle this particular task. Ideally, we capture as many issues as possible to create a backlog over time. After enough issues can be identified to be tied to this particular task, this epic should be scheduled to be discussed during our Sprint planning.
Because there was never a discussion or planning around the in-house wallet used at `hoprd`, important discussions as to whether consider other architectures for auto-submitting transactions were never had. In particular, whether other patterns like using [ERC-2771's trusted forwarder](https://eips.ethereum.org/EIPS/eip-2771) paradigm was never considered. There are yet to have discussions about how to handle a custodial wallet that could have a significant amount of money, and whether other architectures could be suitable w/o exposing users to losing funds via exploits.
# Existing issues
- [ ] When a transaction is considered as `stuck`, scheduled transactions should be sent out again if possible[^1]
- [ ] Users have no visibility of the transactions executed or pending by `hoprd`'s private key[^2]
- [ ] Wallet does not escalate issues across `hopr-admin` and instead submits opaque errors difficult to debug[^3]
- [ ] Wallet has no mechanisms against gas fluctuations or uncle blocks[^4]
[^1]: The nonce manager reset the `nextNonce` to the nonce of the `stuck` transaction. All the queuing transactions are lost and user would need to perform the transaction again. We could keep the data of pending transactions and trigger the signing and broadcasting process automatically with a higher `gasPrice`.
[^2]: Ideally, we could have some sort of display that shows something like `(3) completed, (1) pending, (0) failed` or similar that could provide some context to users to understand what's the state of the wallet.
[^3]: Whenever a `nonce` is re-used or there are other transaction-related issues, `hopr-admin` is the wiser and throws a `Failed to send transaction` error, which provides close to zero visibility to the underlying error. Ideally, the wallet has a specific debug or log trace that can be queried or some sort of queryable in-memory storage able to be seen by developers or users on request.
[^4]: Some of the issues we faced was the amount of [blocks forked](https://polygonscan.com/blocks_forked) which displayed inaccurate information about the state of our channels. Currently, there are no mechanisms to tackle these, and it's yet to define whether these should be tackled in the first place instead of being a more high-level requirement for the blockchain picked for the HOPR protocol.
Might be interesting to spec this out in more detail.
Good stuff, shared a strategy to approach this in another topic. This idea spans from a GitHub issue already shared by @bot (thanks, was looking that one yesterday).
Some time ago I shared the concept of a browser-based private key used to quickly onboard a user. The idea was simple: create a dumb private key during the onboarding of a DApp so users wouldn’t need a web3 provider to start using the app right away. Using a Gas Relayer like OpenGSN anyone could use the app even if it had no gas. Here’s the overview (the initial link has a full breakdown).
[image]
In a similar, a HOPR node generates a private key, but this has the following likely unwanted si…
shm1ga
March 14, 2022, 8:35am
7
A good idea to solve the problem of losing tokens (forgot to withdraw) after the test.
A good wallet is essential.
Not just for testnet. It will also be important when cover traffic is ready.
OuTLaWz_1903:
As we all know, the nodes we set up have a wallet address, but we do not have mnemonic. We need to take a backup of the db file. db file is not safe even if we back it up. Our node wallet address changes with each node setup. It should be a web wallet instead. 12 words are mine. We just need to install the Node by entering the identity key of our wallet address. To put it briefly, I think our wallet should not be in a node.
this is definitely a good idea. the funds shouldn’t be on the node
1 Like
I like this a lot and think it would be very helpful. The credentials to add the node’s wallet address to an application like MetaMask are available, but there’s nothing in the documentation about it that I’ve seen. I had to figure it out on my own.
I’m not sure if this should be part of this proposal, but I’d like an option to “withdraw all” to an address of my choosing. Right now, due to gas fees, etc. folks may be leaving a small portion of their funds in the node’s wallet. This isn’t a huge deal since it would hopefully be less than a couple cents, but it would make the whole withdrawal process much easier.
Thanks for this suggestion, @OuTLaWz_1903 !
I think it probably needs a few more implementation details before it can be assessed for validity. You can find the validity guidelines here:
Here are some general guidelines for creating a valid proposal for this third DAO experiment. As a reminder, the topic is:
What dApps, tools, and/or services would you like to see built on top of the HOPR protocol?
Because this is such an open-ended question, it’s impossible to give precise validity requirements. But I can give some advice on what I’m looking for as a moderator.
When you’re happy that your proposal meets these guidelines, adjust the title to include [Proposal] and it will be …