Is there a potential user base for a new wallet?

Developers Cardano Projects
1

Hello,

I am a long term C++/Qt cross-platform programmer, who made many desktop apps over the decades. I have to admit that I have a bit unique view on webapps and modern software, that is IMHO unnecessarily bloated and resource expensive (RAM, CPU), despite it looks “cool”, but I totally understand that’s what most of modern users are looking for.

When I first saw Daedalus - a prime example of this kind of software (massive CPU and RAM usage, compared to any other full node client I know for other chains) I was wondering why nobody created a simple stupid lighweight desktop wallet that maybe doesn’t look fancy, but does the job, is secure and uses very little RAM and CPU. I was actually thinking of contributing to Cardano project a bit in this aspect and create one, but then I dismissed the idea as I didn’t really see this as something community would have wanted.

However - seeing this disgruntled comment by a potential Cardano user - Daedalus ignores my settings and store files where they don't belong (read the whole discussion - he ended up selling and leaving) I started thinking that maybe it wasn’t such a bad idea in the end.

What do you think? Do you think that there is a user base of people that would prefer a lightweight wallet (< 100MB RAM, little CPU usage) that is NOT browser based (therefore potentially more secure), with simple stupid interface that just “does its job” and nothing else?

If there was support / interest in this idea, perhaps I would start some open source project for this, I even had a model in my mind where this wallet could be a light wallet in similar fashion to Yoroi, but more community focused and decentralized - where the backend servers that act as full nodes would be in fact operated by community SPOs, similarly to Sundae Sc0opers (these nodes would be just a proxy between cardano-node and light wallet, they would just handle signed transactions, so it would be absolutely safe, the signing would be always done by light wallet using the owners computer, no keys or secrets would ever be exposed).

Thanks for any feedback on this idea. Also if anyone is already working on similar project, let me know as well, I don’t want to reinvent anything that exists :slight_smile:

4 Likes
2

As already stated in the original discussion, I would be kind of interested.

Some unordered thoughts would be:

  • Do not depend on backend servers. Get the information from full nodes, but do not save the whole chain either. Just remember the needed information and just get (and perhaps validate) the new blocks on next startup and extract the needed information from them.
  • “Needed” could be configurable: Just remember all transactions of your wallets (or a list of wallets to observe). Remember all unspent outputs (so we can validate all transactions), but forget all addresses that are already at 0 again. Remember everything (like Daedalus/cardano-node).
  • Be prepared to work with all kinds of wallets from other wallet applications, i.e., support the multi-account functionality of Adalite (and, I think, one other wallet) as well as the random address selection of Daedalus (which Adalite states, that it cannot handle). List can obviously be extended.
  • It would be really nice to not save secrets by default on disk, where they can be hijacked by malware. It can remember the public information of all configured wallets, show transactions and balance etc., but could require the seed phrase and store it in memory only for issuing transactions (or an encrypted file that can be easily stored on a USB stick), a bit like Adalite, but remembering wallets in a read-only fashion like Yoroi.
  • Provide rewards per epoch information. As far as I understood, they are on another layer, which is why they are not visible, e.g., in explorer.cardano.org, but withdrawals seem to come out of thin air, there. Would be nice if a client/wallet could also observe this layer and give reliable information about it.
  • Save everything in an SQLite database with an easy to understand schema, so that other tools can explore the information in there, perhaps leading to a more light-weight replacement for cardano-db-sync.
  • Provide a command line interface, first, and a GUI building on it only optionally.

If I would do it (which realistically will not happen due to time constraints and procrastination), I would probably do it in Python, just to have an easy to understand alternative reference implementation of how this stuff works (while I’m totally not opposed to the official implementation in Haskell).

2 Likes
3

Hello, thanks for the ideas. I agree that we should save the information from backend servers. Really backend servers would be just simple relays to the cardano-node that would be used for two purposes:

  • Obtain network status (parameters / balances etc.)
  • Submit transactions

Given how simple they are and that they work only with public data, their providers don’t need to be trusted. That’s why community SPO are perfect candidates, since they already have to run cardano-node on publicly accessible relays anyway. These information could be cached into some sqlite DB afterwards.

For the security topics - I would love to get integration with HW wallets, that shouldn’t be too hard, that would be best way to avoid storing secret on disk. Another option I was considering was creating a read-only wallet mode, where secrets would never be stored on disk, but only used to obtain wallet public keys (store those instead), so that balances were visible, but no transactions possible. In order to enable transaction signing, user would have to temporarily enter their recovery phrase.

Then traditional option to generate private keys using recovery phrase and symmetrically encrypt them using spending password would of course be also available, in the end that’s what most users would probably prefer.

As for the language choice, I don’t want to do Python, I have terrible experience with using Python for very large projects. I want this to be extremely lightweight, fast and portable, so I would stick with C++

1 Like
4

I don’t know if you really need specialised backend servers for that, even if they are just proxies. The cardano-node inside Daedalus is able to do it with just communicating with the other nodes in the network via the standard protocol.

We are pretty much on the same page. Of course, hardware wallets should be supported.

Language choice: Yes, matter of taste. Never got the hang of the large industry languages – Java, C#, C++.

Would be nice if it had some interfaces – CLI, database structure – where I can easily poke in with small tools in my language of choice.

5

Being a Windows C/C++ programmer myself, i completely agree. I just made the same discovery, there’s no setting in Daedalus such that that you can choose where the blockchain is stored. I also use an ssd and there’s not much free space. Actually, I think the wallet could be improved if portions of the code were written in C++. It may be an old school language but it does offer fine grained control which you simply can’t get with more modern languages where you can’t use the native api.

6

I can think of something even nicer. Would it not be great if there was some kind of wallet framework with a unified UI and hardware wallet support. That would make wallet development easier, it would be a signed dll. No mean feat, though. Perhaps something for Microsoft to consider

7

I don’t think there is a good description of low level protocol that cardano-node instances are using to communicate, or is there?

I believe that the way how it’s done now is that cardano-node implements whole logic of Cardano, so that before you attempt to submit a transaction it also validates it. I don’t want to reinvent the wheel here. I think that most simple and correct model that can be used to allow light wallet access to network is to communicate through cardano-node, that’s how all wallet implementations do it right now.

8

Not that I can find one. :unamused:

Which would in itself be a reason to implement one in a light-weight, accessible implementation as a documentation of “how stuff works”.

But, of course, not necessarily for you. Interfacing cardano-node is a totally valid design decision.

9

Hi, I like the idea of a smaller wallet then Daedalus!

I know that there is a better wallet in the pipeline build by IOG (it will all get better when mithril arrives, thought this might take a while). I agree with the points that @HeptaSean made and would like to add the following github request that will be implemented [1]. This leads the way to specify which data the cardano-node will process and which data it should not process. This will not only be very handy for light weight nodes but also for other applications that want to store only a small subset of blockchain data (like only that of a particular address). Disclaimer, this is in Haskell (its a part of the PAB that is split of to become its own thing).

If you would like to use a API for the wallet I would recommend Dandelion [2].

2 Likes
10

With regards to this, have a look at the following Github rep from @bwbush [1]. It is a tool for extracting more info from chain using the node directly (like watching an address or calculating certain derivatives of cryptographic structures). Note that this still stores the complete database but it is better than using bash scripts plus the Cardano client.

1 Like
11

I look forward to a better and faster wallet than Daedalus. It is written in javascript which I think is a bad choice since it is single threaded. That means it simply can’t implement a better way to download the blocks. You really want to download the blocks in essentially random order and from where you get the best connection speed. You also want to abandon a downlpad midway if the connection speed goes down and continue from there. I think my donload speed is really slow in spite of the fact that my internet connection is really fast.

1 Like
12

actually Daedalus is just UI wrapper around cardano-wallet, which is written in Haskell, so I don’t think that performance is so bad, but it’s a huge memory hog.

What I want to create is a light wallet, where the cardano-node would be hosted by SPO relays who want to participate in this. So the model would be same as Yoroi but would be 100% community based and decentralized.

1 Like
13

Ah, I didn’t know that. But I still wonder why the download speed is so slow.

I found an ”interesting” thing that can be done in javascript. It can intercept a copy command and replace the text woth something different. Admittedly, I have never done anything in this language but since it isn’t compiled, I suspect it’s not too hard to ”add” this particular snippet. So that a hacker can alter the receive address.
I sure hope widows will show a warning if a signed exe has been altered assuming that the signature hasn’t been removed.

I’m not worried myself, I check that what I paste does match with what I see. Still, hackers will use this trick in this wallet or elsewhere. So, if you are worried, you can try to start it as an admin and make sure it is signed. But you shouldnt run it as an admin, just press cancel.

Below is a link to the article I found.

14

that’s very usual hack in crypto world, that’s why you should use a hardware wallet, where you see on display target address you want to send to and verify it’s correct.

I was thinking for my wallet to allow people who don’t want to buy hardware wallet to create one using old computer - basically you would create a cold PC disconnected from internet, and my wallet would just prepare the raw unsigned TX for you, which you would transfer to cold PC and sign there, then moved back to hot PC. CLI can already do that, but I’d like to make a graphical UI for this. I even wanted to use my old raspberry for this with CLI, but it’s armv6 and cardano binaries are not compiled for it and GHC doesn’t even support this platform as a target, I think it supports only latest raspberries. If I could port this code to C++ I would easily be able to compile it there.

For “why download speed is slow” - it’s not download speed that’s problem but blockchain verifying. Every block that is downloaded is cryptographically verified, you can see your CPU is probably going to be pretty used up in first startup of Daedalus. Also for each wallet Daedalus creates 20 derived private keys for first 20 addresses, and scans whole chains for transactions made by these 20 addresses, which transaction history is then compiled from. That is also very slow and necessary every time you add a new wallet. More wallets = more CPU.

1 Like
15

Interesting example, really, but this is done at the source, where things are copied from. People could hack an exchange and make people copy the wrong address if they want to cash out or something like that.

All desktop programming languages could also intercept copy and pasting quite easily. That’s not a speciality of Javascript, there. (It is a speciality on websites, where you would normally not expect such things.)

But then: If you consider an attack vector, where the attacker has write access to your Daedalus installation, all kinds of really, really bad things could happen. They would also have read access to secrets stored on disk (if no hardware wallet is used). And it’s not specific to Daedalus. Every wallet can be toast if you are not sure that you can get an unmodified installation and protect it.

I suppose it’s mostly Yoroi that is attacked, because of the number of installations, because the secrets can be found in relatively standardised locations (in the browser profiles), because there are a lot of different platforms that can be targeted (iOS, Android, Chrome, Firefox), but in principle, as soon as your machine is hacked, desktop wallets – Javascript or not – will not be much safer.

16

They wouldn’t have access to your secrets in Daedalus until you enter the spending password. All private keys are encrypted using that password.

17

Okay, yes, but: If they are on the machine, they could keygrab the spending password. If the spending password is weak, they could brute-force it.

If I consider attackers having machine access, my only protections are hardware wallets or air-gapped machines (not installed from the compromised machine) or simply the fact that there are easier targets out there.

18

HW wallet is probably best solution. Its only drawbacks are:

  • cost - you need to buy additional gadget
  • Ledger is proprietary SW, you can’t verify or audit it, I heard Trezor is open source
  • support for HW wallets is still poor even for Cardano.
    • Yoroi has fatal bug that prevents HW wallets from being used
    • Daedalus has also bug, which has a workaround, but it compromises the security a little bit
  • Not all wallets support them, especially not sure about mobile phones
1 Like
19

I have used a Ledger Nano S with Daedalus on Desktop, Adalite in Firefox and Yoroi on Android without any problems or workarounds. I remember a problem with sending transactions in Yoroi on Firefox, where the proposed solution was Yoroi on Chrome, but other than that it works. Are there more problems on Windows than on Linux?

20

Yoroi has cross platform issue, but probably not affecting mobile phones:

yoroi bug - extension completely broken for HW wallets (ledger) - indefinite syncing due to GenericApiError · Issue #2448 · Emurgo/yoroi-frontend · GitHub
daedalus bug (might be windows only) - [DDW-722] Hardware wallet Ledger Nano S - Windows pairing issue by tomislavhoracek · Pull Request #2698 · input-output-hk/daedalus · GitHub