Topic: WalletBuddy - secure wallet(s) storage and backup (Read 6229 times)

Of course I could. That why the code is open source and anyone can inspect it.

I still have yet to post the promised update, I wasn't sure if anyone was still interested in this.

Way too complicated for my non tech savvy mind and I have iq of 135. Plus how do i know that it is secure in that you may have some back door key to info submitted by anyone who interacts with it? Not that I believe you do but couldn't you? since you developed this?
bitpart

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.

Is this a GUI app? Are there any screenshots?

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

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?


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

This is a bug.

Yes, and be sure your hex-conversion function can handle fractional values (eg, 0.1 TBC).
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/

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.

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

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.

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.

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.

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

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

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]

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?

Um, not after what happened with the last one.

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.

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.

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.

Tried to run it and it threw an error.