Is there a potential user base for a new wallet?

Absolutely, you are 100% correct. I have written malware as a hobby and I have learned a lot in the process. Strictly for learning. This is why I’m interested in better wallets for all legitimate cryptocurrencies. I also worry about scammers which I think is a major hindrance before mass adoption can be achieved. A rogue setup program can do everything you describe because such a program would want to run with admin privilege. If so, it can do all of the things you mention

Using yoroi, without a hardware wallet, is really scary. As far as I can see, you can’t sign it. There’s no way to know if yoroi has been replaced by something fake. I guess this is what has happened to those yoroi users that have lost ada.

I really, really want everyone to use hardware wallets. First buy a hardware wallet, then buy cryptocurrency.

1 Like

Here’s a really scary article. Not related to javascript

My guess is that the seedphrase used on Metamask was the same as on the ledger device. The malware managed to take a screenshot of it and send it to the scammers. If so, the theft was done from a different computer, someone simply reconstructed the wallet and transferred all the coins.

You can disable printscreen via Group Policy and that is something I will do.

This made me realise that something can be done to protect software wallets and it’s actually easy.

In addition to the extension, there should be a signed exe that can be started from the yoroi menu. It should be run with admin privilege. If it is indeed signed by iohk, the exe should disable printscreen and also verify the browser extension. I guess it could do other things as well in order to make sure there’s no foul play.

I remember a debugging tool that could act as a real user. It would record everything in a script and then replay everything. Very useful but If memory serves, such tools must be cross signed by microsoft. That makes it difficult to steal coins directly from the user’s computer by simulating mouse clicks and keyboard inputs.

Interesting idea.

I’d also make a forum poll to see if SPOs would be interested in participating. Saying as we can see how each SPOs is trying to optimize the server resources to the maximum in order to be performant and to not miss a block.
Having thousands of concurrent wallet users could affect the performance of participating SPOs servers which would yield additional costs to IT infrastructure. Also, there is a security aspect of opening more ports and allowing public access, that needs to be thought through.

I’m not sure how Yoroi operates and who covers their IT infrastructure costs?

Yes it would absolutely put some strain on the servers, but it would also work as a form of promotion for them. Seeing how many of them were eager to be a Sundae Scoopers, I don’t see why many of them wouldn’t want to become part of backbone of community light wallet.

Also many SPO use more than 1 relay, which is useless from technical perspective, so they could easily run this on one of their extra relays and keep 1 relay dedicated only to the PN itself.

btw it doesn’t even have be an SPO participating in this, it would be anyone who runs cardano-node (full node), ideally with high availability and public IP. It’s just that SPO already have to run high-available full node, so they are ideal for this role.

Yes, there is always potential for new wallets and people keep creating them.
Personally I also have mine, it is a desktop wallet. You do need the full node, but then use the Emacs text editor to wrap the cardano-cli and interact with the node.

In further self advertisement. I think it is great and aside from the full node, extremely lightweight. Yet you are limited to the UTxO set. I have tried to wrap cardano-address and it works, you get access to HD keys. Also I experimented wraping cardano-wallet, which keeps a new service to track your funds, you get full transaction history. That one starts being a overkill from my point of view.

One extra advantage of having Emacs assist you to wrap the CLI is that you can easily port it to an airgapped machine for singing your transactions.

My project is on GitHub - Titan-C/cardano.el

1 Like

I absolutely love this idea! I have been thinking about yoroi security in this thread; Export/duplicate key's from yoroi - #12 by HeptaSean

I’ll read this thread more closely later, time’s up for me for today…

1 Like

Right now status of my project is that I have basic skeleton written in C++, a cross platform desktop app that starts in less than a second (it’s Qt, visually similar to NavCash), is able to create new wallet using randomly generated seed phrase, generating of all key sets for staking address and for first 20 payment addresses takes about 2 seconds, but that’s because right now I am still heavily depending on cardano-address binary shipped with Daedalus and do most of this address logic through that.

I will implement this logic in C++ later, but that would really just lower dependencies, simplify the potential packaging process and eventually give some extra performance, so it’s low priority now.

What I am dealing with now is the actual communication with Cardano network. I decided to go with lots of abstraction here so that user has multiple options, I want to implement classes for:

  • local cardano-wallet instance (same functions as daedalus, basically a full node client, with heavy overhead as cardano-node needs to be running on local machine, just interface is going to be different, probably a bit more advanced)
  • blockfrost - I don’t like it so much because it’s centralized and requires registration / subscription, but their APIs are very rich and easy to use, probably most trivial implementation of light wallet.
  • ogmios - I am still exploring that
  • remote - this is something that requires lots of coding, basically either re-implementation of ogmios or some wrapper around it that would provide some rate limits, basically the idea here is that various SPOs who wanted to be part of this project, would host instance of node / ogmios relay (with some rate limiting to avoid DDoS) and the light wallet would use these relays simultaneously to query ledger data, obtain transaction history and submit transactions.

I will keep posting updates as I progress, I will upload code to github later, when it’s more mature


This is exciting. I look forward to read about your updates.