Comments (4)
Hello @mmick66
Thank you for noticing this, yes, this is to me the biggest issue I have with wallet-lib.
But it is actually more than just that, right now, for the sake of the exportWallet() function, mnemonic and root keys (seed) are stored.
But this information is not needed as we could at least have a derivation path (so we don't make other chain using the same mnemonic vulnerable).
There is indeed on top of that the secure storage issue (which so far were left for pull request but no one really made one yet).
What I can say is that we do have this planned, but its priority is delayed due to more immediate need.
So I can't give any ETA yet (I hope we are talking about end of year).
But let's use this issue to discuss the subject in the meantime.
Would any users have specific requests on that subject, please forward it here as we will use this issue to ensure we match requirements.
from platform.
Thank you for your honest reply. For the moment, and as I am trying to use this library on a current project that I'm working on, I though of the following pattern for mobile devices. I am going to post it here for others to see, as well as for you @Alex-Werner to give me an opinion.
To create a wallet you:
-
Generate a new Mnemonic through the helper function. You then show it to the user, who is then made responsible for storing it.
-
You create an HDPrivateKey, and from that, a (standard) PrivateKey.
-
You create a PublicKey and Address and instantiate the Wallet with either as an
WALLET_TYPES.ADDRESS
orWALLET_TYPES.PUBLICKEY
respectively. At this point, only the PublicKey and/or Address are going to be saved in-memory. -
You discard both Mnemonic and HDPrivateKey from memory, and save the PrivateKey in a secure storage.
-
Whenever you want to sign a transaction (or Message), you unlock the PrivateKey from storage using whatever mechanism you with (pin, TouchID, FaceID etc) and pass it to the sign function of the Account, which is going to pass it to the
sign
function of the KeyChain.
from platform.
Thank you for this.
Indeed the plan is exactly what you describe !
Keep me update about your progress, so I can see if at some point I need / can prioritize slightly more.
In wallet-lib case, it will be specific, we still require a HD key (but at lower level), for us to be able to generate additional public address (BIP44), or identities.
So the path will be specific to BIP44/dash,... for change and external.
We also manage identities, so we also have that
from platform.
Sure, I get what you are saying. Currently, and for the purposes of my project, I need a "single address" wallet only. Basically, and for my current purposes, a wallet will be (practically) synonymous to an account. I will keep you posted if and when I encounter problems. Thanks again for the swift response.
from platform.
Related Issues (20)
- feat(release): bump rust package via `yarn release` script HOT 1
- perf(dashmate): profile command execution time HOT 1
- feat(dashmate): add service configs render command HOT 1
- bug(dpp): Wasm SIMD unsupported
- bug(dpp): WASM DPP bundle doubled in size HOT 3
- feat(dashmate): warn user if the node is participating in DKG sessions HOT 5
- bug(dashmate): evonode shows platform up when tenderdash is still syncing
- bug(dashmate): dashmate update fails if one image could not pull
- Rename repository to dash-drive
- Doc: How to install Dash Drive HOT 3
- bug: tenderdash abci version mismatch between tenderdash, rs-tenderdash, and rs-drive-abci (v0.24 vs v0.25) HOT 1
- `v1.0-dev` (the current working branch) fails to build from source HOT 3
- Missing updated .env.testnet
- Ports from various example ENV files and configs don't match up
- doc: example envoy config
- `dashmate setup local` fails with `Database already exists` HOT 4
- doc: which services start in which order HOT 2
- `envoy` fails to load as system daemon trying to access `/dev/stdout` HOT 1
- Error during contract deployment HOT 4
- Dashmate platform Block Height 0 HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from platform.