Careful using this, I'd personally wait until a proper security audit was done.
For instance, you're getting the user's wallet passphrase at line 1361. Does the passphrase just sit around in memory somewhere, long after the wallet encryption has been kicked off?
It's a bit tough to deal with this since javascript doesn't offer any real way to zero a string's memory. The way to do this would be to read from stdin directly into a Buffer object (which is malloc'd separately from the v8 allocator) and to buff.fill(0)/memset(buff, 0) once we're done. I'll definitely work on implementing this. Thanks for pointing this out.
Assuming you trust your hosting company (maybe that's another discussion?) I don't think it's possible to leak memory contents VPS-to-VPS but I could be wrong.
In any case, if I had a pile of Bitcoin (unfortunately I do not) I wouldn't put it all in one wallet on one server. From what I've heard, paper wallets are the safest.
That said, maybe "zero out" your wallet before switching VPS providers, changing plans, etc.
"It is worth noting that the data was not live, in that it was not due to sharing of disk contents between running instances of virtual servers. It is understood that the data is due to disk and swap data not being zeroed after use."
Heck yes, I've been looking for something exactly like this. I hate the Qt client, and the others I've played with aren't much better, but this is perfect :)
EDIT: Dumb question, running Mint 16 here, installed the nodejs package through apt, but termcoin looks for "node", not "nodejs". I copied the symlink as "node" and am just installing the npm modules now, but whats up with that?
What 'yrro said, seems node is something up relying on inetd, apparently! No big, I fixed it anyway, but might send a PR to the project to handle Debian derivatives better.
It looks amazing, and I do dislike the current bitcoin-qt that most of us use.
However, I'll be damned if I install it on my machine for at least a year or two after it's been released and fully verified by everybody in the community who matters.
If you're worried about the security then just verify it yourself, don't wait for others to do it for you. It's not like the source isn't available for auditing.
I do not possess the time to do that, unfortunately.
The only way that I can be sure that it's not going to steal from me is if it has been around for a few years, used extensively, and nobody has cried fowl.
That, or if they paid for a public auditing by respectable cryptographers.
Interesting, I've also developed a bitcoin client :) However, mine is completely independent of bitcoin-qt and is meant to be lightweight and snappy. It uses SPV. Here's a screenshot:
Let me know if anyone is interested in taking a look.
From my README file:
bitc is a thin SPV bitcoin client.
- 100% C code,
- support for linux and mac platforms,
- console based: uses ncurses,
- home grown async network i/o stack,
- home grown poll loop,
- home grown bitcoin engine,
- multi-threaded,
- valgrind clean.
Notably, there is as an alternative to this node terminal btc client.
electrum -g [text | stdio]
The terminal interfaces could use more testing to say the least, but Electrum has been around since 2011. It's written in Python and includes support for CLI based multisignature transactions [1], raw transactions, proxies, and server selection. It was recently added to the Debian official repos.
It's actively used in ecommerce [2], and we've even heard on #electrum freenode of at least one Bitcoin exchange using it on the backend.
Electrum uses a deterministic mnemonic address generation system (soon to be BIP0032 compatible) and the Stratum protocol, which involves running a gateway daemon [3] and bitcoind on the backend, to tackle the large size of the blockchain and rather unwieldy individualized address generation scheme in use by Bitcoin-QT.
After seeing the screenshot (https://raw.github.com/chjj/blessed/master/img/screenshot.pn...) I'll be switching to "Welcome to my program" from now on instead of "Hello world!" which is getting really tired. I don't know why I never thought of it. Facepalm.
Wish this was elaborated: "Ideally I wanted this to have all the capabilities of a full wallet, but that would require, for example, linking to to berkeley db to parse the wallet.dat. I wanted to write this entirely in node."
So it still makes a wallet.dat file but different wallet encryption? I'm a little confused.
termcoin uses the bitcoind json-rpc api[1] for (nearly) everything (which means the same wallet.dat file, the same encryption (aes256-cbc), etc.). What I mean to say is, the bitcoind api is a bit limited with regards to how it can manage a wallet.
For example, there is no way to retrieve the "send" addresses from the wallet via the api. The only way to do this is by using bdb to open the file and reading it as a berkeley database. Send address retrieval is the only thing termcoin does not use bitcoind for: termcoin has a "dumb" parser built-in which reads the wallet.dat and searches it for bitcoin addresses, when it finds them, it checks to see that they're valid and also checks them against "receive" addresses.
The bitcoind api is also incapable of re-labeling or deleting addresses (bitcoin-qt itself cannot delete "receive" addresses). A lot of people end up using a tool like pywallet (which links to bdb) to get around this. These are the only two limitations in termcoin's functionality that keep it from being a fully-fledged wallet.
For instance, you're getting the user's wallet passphrase at line 1361. Does the passphrase just sit around in memory somewhere, long after the wallet encryption has been kicked off?
https://github.com/chjj/termcoin/blob/master/bin/termcoin#L1...