WalletBuddy - secure wallet(s) storage and backup

[BitterTea]

Now (maybe) Linux compatible!

It's late, I'm tired, I'm going to keep this short.

I made it my goal to get this published tonight, and I did it. Binaries, Source

Absent encrypted private keys, I wanted a way to easily store my wallet encrypted. Absent solid import/export of private keys, I wanted a way to easily juggle multiple wallets. After a few weeks of writing and rewriting, this is what I came up with.

• Uses GPG (via BouncyCastle) to encrypt the wallets.
• Per-wallet GPG key choice
• Queries Bitcoin when running (if -server switch) to determine oldestkeypool
• Automatically backs wallets (encrypted) only when last backup is older than oldestkeypool
• Supports wallets on removable volumes (with notifications)

This is my first time doing the open source dance, let me know if there's anything I can do better. I know the repository is a mess, I just threw it together, I have to figure out some organizational structure. If anyone wants to throw together a windows installer package rather than the ClickOnce one I threw up there, please do.

Requirements:
gpg keyring (I use gpg4win)
Windows: .NET Framework 4
Linux: Mono 2.8[1]

Changes:
[1] 2011-02-24.
I just pushed some updates removing some libraries that are incompatible with Mono. Anybody using Linux care to try this out? Also in the update are some incomplete ideas... I want to (optionally) store the wallet's address book with the wallet settings, updating it periodically. When I complete my JSON-RPC client, you could transfer funds from your current wallet to another with a few clicks.

[1714045584]

1714045584

[1714045584]

1714045584

[BitterTea]

Is there no interest in this functionality, is there hesitance due to the recent malicious wallet tool, or am I just an impatient bastard?

There's one issue I didn't think of... currently there's no way to import a plaintext wallet. You'll have to manually encrypt with GPG the first time until I write some code to handle this.

[Garrett Burgwardt]

Tried to run it and it threw an error.

[BitterTea]

What was the error? It's compiled for .Net 4.0 I think. If you don't have the redistributable installed, the plain zip version probably won't work. Did you try the ClickOnce version?

Let me know and I'll look into it.

[TiagoTiago]

I would be worried about using the binary, if i study the code and get convinced it's not gonna harm me, then copile it myself i would be more confortable using the program.

[BitterTea]

I would be worried about using the binary, if i study the code and get convinced it's not gonna harm me, then copile it myself i would be more confortable using the program.

Sure, that's totally understandable. The code is fairly clean so it shouldn't be too bad to review. For the crypto library (BouncyCastle), I'm wondering if it would be better to just include a static library reference rather than a project reference. That way, you could swap the DLL out for the one you download from their web site. Considering that it's the largest project in the solution, it would save some code review time.

[Quip]

Um, not after what happened with the last one.

[BitterTea]

Um, not after what happened with the last one.

Which is why my code is available for review. Not very well documented, but available nonetheless.

Anything additional I can do to help alleviate concerns?

[we6jbo]

Is there no interest in this functionality, is there hesitance due to the recent malicious wallet tool, or am I just an impatient bastard?

There's one issue I didn't think of... currently there's no way to import a plaintext wallet. You'll have to manually encrypt with GPG the first time until I write some code to handle this.

This quote intrigued me because at least the way I see things even compiled code that does not relate to Bitcoin could in fact take advantage of the bitcoin api and cause harm to the user. I'd like to debate this issue but instead do it in the thread that was about fraud because I don't want to derail your thread for a topic that has nothing to do with program. [I'll repaste a variation of my post here http://bitcointalk.org/index.php?topic=3596.40]

[SmokeTooMuch]

I don't see why we need such a programm.
backing up an encrypted copy of the wallet.dat is as easy as 1-2-3.

I still appreciate your effort

[BitterTea]

This quote intrigued me because at least the way I see things even compiled code that does not relate to Bitcoin could in fact take advantage of the bitcoin api and cause harm to the user. I'd like to debate this issue but instead do it in the thread that was about fraud because I don't want to derail your thread for a topic that has nothing to do with program. [I'll repaste a variation of my post here http://bitcointalk.org/index.php?topic=3596.40]

I'd like to make one reply to this, and then we can take it to another thread.

The code I was referring to is a well known crypto library, BouncyCastle. Wanting to know how it worked, I included the source of the library in the WalletBuddy solution. This means that I could have modified any of that code to include malicious behavior - a lot of code to check! My thought was that I'd instead link to a compiled DLL, which you could then download separately from a trusted source (e.g. BouncyCastle web site) to ensure that I didn't mess with the BouncyCastle code.

I don't see why we need such a programm.
backing up an encrypted copy of the wallet.dat is as easy as 1-2-3.

I still appreciate your effort

Sure, for some users. But managing multiple wallets is still rather a pain. This alleviates some of that annoyance, I think.

[we6jbo]

I was thinking that an attacker would probably not want to use Bitcoin.org to plan an attack on a persons wallet since the community is quite acute to what may be considered malicious code towards Bitcoin. Instead the attacker would most likely stage an attack on Tor which is highly popular with people with different levels of computer experience and then once the Tor community got enough word on Bitcoin some of the members including ones that are not technology savy would install Bitcoin on their machine which would also have the attackers program waiting patiently for the program to install and for the user to deposit some coins into the system which would then be transferred into the attackers account.

One of the reasons why I think Bitcoin would be considered a high target and why attacks like these could happen is because Bitcoin is a direct currency and it requires little or no effort for the attacker to get paid. I've also mentioned this before but I think that if Bitcoin allowed users to insert some identification such as their name or an email into the users transactions then if an attacker stole money from the user it would make it a lot easier to report the theft such as if the attacker tried to change the currency into dollars by exchanging it with a bitcoin trader, the trader would see the theft report and that person could track that the funds did originate from the original owner through blockexplorer and hopefully the person could return the funds back to the original owner.

That's just my comment about why Bitcoin security will be an issue on sites outside of Bitcoin.org and not necessary on the site itself. As for the program you wrote, I like the ideas that you mentioned that are in your program and it would probably be good for a Windows users. If it were written in C++ or Java then it would be easier to port to other platforms. Also I was just wondering how you were interfacing your program with Bitcoin. I'm guessing that you're using the JSON-RPC API.

[BitterTea]

As for the program you wrote, I like the ideas that you mentioned that are in your program and it would probably be good for a Windows users. If it were written in C++ or Java then it would be easier to port to other platforms. Also I was just wondering how you were interfacing your program with Bitcoin. I'm guessing that you're using the JSON-RPC API.

I just released an update which might allow it to be compatible with Mono. If you'd like to give it a shot I'm interested to know how it works for you.

Right now I'm only using JSON-RPC to call getinfo and listreceivedbyaddress. From getinfo I use oldestkeypool to determine if it's time for a new backup (if the newest backup is older than the oldest key in the keypool). In the original post I added an update which explains my use of listreceivedbyaddress.

[Luke-Jr]

Since you are already factoring out libraries, I would suggest doing so with the formatting code too, possibly adding an abstract function to autodetect display type based on amount.

I don't use Windows/Mono, so I can't check for sure, but I suspect the TBC rendering code has a few bugs... It seems to just convert amount to hexadecimal and stick TBC on the end. If so, this is missing the tonal point (1 TBC = 10000 (65536) Satoshis), and neglecting the fact that tonal has different digits than hexadecimal. If .NET has a Unicode-compatible tr(anslate) function, you could map "9abcdef" to "".

Interesting concept with the ScientificSatoshis

[BitterTea]

Since you are already factoring out libraries, I would suggest doing so with the formatting code too, possibly adding an abstract function to autodetect display type based on amount.

I don't use Windows/Mono, so I can't check for sure, but I suspect the TBC rendering code has a few bugs... It seems to just convert amount to hexadecimal and stick TBC on the end. If so, this is missing the tonal point (1 TBC = 10000 (65536) Satoshis), and neglecting the fact that tonal has different digits than hexadecimal. If .NET has a Unicode-compatible tr(anslate) function, you could map "9abcdef" to "".

Interesting concept with the ScientificSatoshis

Detecting display type based on amount would be easy, but I am storing the value as decimal base units no matter what is entered for ease of interoperability with Bitcoin's JSON-RPC.

You're right though, I should divide the decimal amount by 65536 before converting to hex, correct? For some reason I'm having trouble wrapping my head around that, though the math seems to work. I'm not sure about displaying actual tonal characters, I think I will keep it displaying their hexadecimal equivalents instead. Are there even any fonts which include tonal 9-f?

I've been working on payment queuing and syncing wallet(s) with removable devices and plan on updating git and releasing another version soon.

[Luke-Jr]

Detecting display type based on amount would be easy, but I am storing the value as decimal base units no matter what is entered for ease of interoperability with Bitcoin's JSON-RPC.

This is a bug.

You're right though, I should divide the decimal amount by 65536 before converting to hex, correct? For some reason I'm having trouble wrapping my head around that, though the math seems to work.

Yes, and be sure your hex-conversion function can handle fractional values (eg, 0.1 TBC).

I'm not sure about displaying actual tonal characters, I think I will keep it displaying their hexadecimal equivalents instead. Are there even any fonts which include tonal 9-f?

That could be confusing, since Tonal is not Hexadecimal. '9' Tonal is 'a' Hexadecimal, and '9' hexadecimal is '' tonal.
There are at least 3 fonts that I know of: http://luke.dashjr.org/education/tonal/glyphs/fonts/

[BitterTea]

Detecting display type based on amount would be easy, but I am storing the value as decimal base units no matter what is entered for ease of interoperability with Bitcoin's JSON-RPC.

This is a bug.

Could you be more clear? If you're saying that Bitcoin expects a decimal number of Bitcoins, not base units, then I misspoke. I convert to Bitcoins (not base units) to send via JSON-RPC. If you're saying that storing base units in a 64 bit integer internally is a bug, how so?

That could be confusing, since Tonal is not Hexadecimal. '9' Tonal is 'a' Hexadecimal, and '9' hexadecimal is '' tonal.
There are at least 3 fonts that I know of: http://luke.dashjr.org/education/tonal/glyphs/fonts/

In that case, I will perform a string replacement of hex characters to tonal, on input and output.

[Luke-Jr]

If you're saying that storing base units in a 64 bit integer internally is a bug, how so?

No, I was saying the opposite (storing values as BTC) is a bug. Perhaps I misunderstood you.

[theymos]

Is this a GUI app? Are there any screenshots?

[BitterTea]

Yes, it runs in the system tray. It should run on Linux (Mono), but I've only tested on Windows XP/Vista/7.

I've been fixing bugs and adding features, but I plan on writing up some better documentation soon, and taking screenshots.