Topic: New Desktop Wallet - I’d Really Appreciate Your Feedback! (Read 97 times)

Hi Cricktor,
Thanks for your feedback.

As for point 1, I’ll definitely  going to look into it. I actually thought about it, in particular signing the HASH of the version with a PublicKey associated to an address on the blockchain which I hold, but ultimately decided on this first public version to go for something easier, but I’ll look into the project I’ve mentioned and see if it’s easier to implement and brings more guarantees.

In regards to the “browser” issues, you are correct, but this can be mitigated by the user with their choice of browser (an IOS, let’s say “tails”). I could eventually bake a browser into the code. As for the webserver I use Kestrel, which is an open source (https://github.com/dotnet/aspnetcore).

In regards to your third point, about the structure of the code (and the libraries I use), you are also correct, they are not on a “standard” project build tree, but there is a reason for it.

To develop the wallet I use a programing language called GeneXus (genexus.com) which I’ve been using for over 25 years. With it I’ve developed solutions currently used by hundreds of thousand of users on multiple industries, like education and pharmaceutical manufacturing, It’s a fantastic tool to build mission critical business application, the only problem is that is a “paid” development tool and it is not really open-source friendly, but at the end of the day, it “generates” C# code, which as you pointed out, is not standard, and is difficult to read, but the code it still there, everything the app does is in the source and with a little bit of effort anybody “fluent” on C# can understand what is doing and analyze the critical points (how the keys, encryption and communication is handled), and if you follow the instructions on the wiki you can build it yourselfer and use that version.
“pooya87”, made a point about the libraries that are include in the project, those libraries are generated by GeneXus, but that part is open-source, and here’s the link to them:

https://github.com/genexuslabs/DotNetClasses

I also use some other open-source libraries:

•   NBitcoin (https://github.com/MetacoSA/NBitcoin)
•   SecretSharingDotNet (https://github.com/shinji-san/SecretSharingDotNet)
•   GoogleAuthenticator (https://github.com/BrandonPotter/GoogleAuthenticator)
•   QRCoder (https://github.com/codebude/QRCoder)


Does this make sense?
I’m trying to be as transparent as possible with the tools I have :-)

Thanks again.

Here's my very brief first impression feedback, by no means complete at the moment:

1.
You should've better security for verification of downloaded files integrity! Currently there's only a SHA-256 checksum of the ZIP file published on your wiki website. If a malicious actor manages to compromise your webserver, people could download a completely forged ZIP archive with a malicious wallet.

Have a look at how Bitcoin Core or Electrum wallet provide better file integrity security with cryptographic signatures of important files.


2.
While I find the approach of a consensus backup an interesting feature, the main issue I have with your approach remains: your wallet seems to be a WebApp. I'm no expert on this field, but your wallet needs a webserver and a browser. Two very complex pieces of software which are notorious of having constantly bugs and security issues.

You're adding more than one can of worms to be spilled. Many users have all sort of shit extensions in their browsers and have no clue how that could impact a web wallet's security.

That's just my personal opinion. I don't like to add unnecessary complexity and security issues when it comes to Bitcoin wallets. For that reason I simply don't think that web wallets are a good and secure idea.


3.
I'm not fluent in C# code (https://github.com/angelonardone/DistributedCryptography/tree/main/src/web) and the structuring of such a webapp project (or your choice of project structure). Can't do much for an assessment if your coding approach has indeed strong security as a design principle as you claim and how the listed dependencies of your project impact security.

At least I would like to see reproducible builds of your wallet. I don't oversee if your source code on Github is complete and I haven't tried to build your wallet from the wiki's instructions.

If your project is truly open source then you should add the direct link to the source code to your front page and the OP here. I took a quick look at your github and all I saw as a VS solution containing a lot of .csproj projects that only referenced external DLLs. I was not able to find a single line of code though.

I understand what you mean.
You can build it yourself, the GitHub repository is on the Wiki, along with a step by step process on how to build it.

In regards to your second point.
I've designed it to be completely offline (the taproot wallet), but for the "group" functionalities you need to be connected to the internet.
All the communication with the server for this "group" functionalities are AES256 encrypted, more over, all the data in the server is encrypted by the user's internal PrivateKeys, so there is no way to access any of the information hosted on the servers.


I haven't been able to finish the Wiki yet, but all of this will be explained in detail.

But you can now test all the functionalities (after you build it from the "source" :-) ) on testnet.

In addition I'll be publishing extensive automated test results once I've finish created and running them.

At this point I don't think I can "guarantee" more than these.
You have to test it for yourself.

Does it make sense what i'm saying?

Thanks for your question.
~angelo

Interesting but the problem is people are afraid of using random wallet from untrusted users like you how can you prove that your desktop wallet project is safe to use?
Another thing it doesn't have open-source code if ever it has you need to post it here and let other developers confirm that your wallet is safe to use.

Based on the video guide it looks like you can host it locally and open the wallet in your own browser not a exe file or app it can also be use offline which seems interesting.
I'm not interested in online feature but I'm interested in offline feature but how it works?

I’m relatively new to Bitcoin; my journey started in 2021 after listening to a Lex Fridman podcast featuring Robert Breedlove. That episode sent me down a rabbit hole (I’m sure many of you can relate), and I’ve since decided to contribute to the community. For the past two years, I’ve been developing a Desktop Wallet.
Coming from a background in business application software development, I’ve focused on usability and innovative features that could make it more accessible to “non-techies.”

Two of the main “new” features I’ve worked on are:
•   Consensus Backup
•   Delegated Multisignature

I’ve dedicated all my free time over the last two years to this project, and I’d really appreciate your honest feedback. Am I on the right track, or have I missed the mark?
Your insights would mean a lot to me. Thank you in advance for your time and help.

~angelo


In this link I explain (and have a video) on how the Concensus Backup works:
https://wiki.distributedcryptography.com/wiki.aspx?1048,Consensus+Backup

On the following one about the Delegated Multisignature”:
https://wiki.distributedcryptography.com/wiki.aspx?1049,Delegated+Multisignature

I’ve included many more features focus on security that I haven’t been able to post on the wiki yet, but are available on the actual application, if you want to try it

The wallet support the following Bitcoin standards:
•   Brain Wallets (not recommended).
•   Wallet Import Format (WIF) for legacy individual keys.
•   Hierarchical Deterministic Wallets (BIP 32).
•   Mnemonic code for generating deterministic keys (BIP 39).
•   Multi-Account Hierarchy for Deterministic Wallets - Legacy Format of HD (BIP 44)
•   Derivation scheme for P2WPKH-nested-in-P2SH based accounts (BIP 49)
•   Derivation scheme for P2WPKH based accounts (BIP 84)
•   Segregated Witness (BIP 141), (BIP 143) and (BIP 144)
•   Bech32 segwit address implementation with error detection (BIP 163)
•   Key Derivation for Single Key P2TR Outputs (BIP 86) ~ our default mode
•   Validation of Taproot Scripts (BIP 341 and BIP 342)
•   Electrum protocol compatible
•   Multy spending paths (address and script)
•   K of N multisignature (using Huffman TapTrees)