Jim,

If you didn't just donate 5 BTC to me, I'd be donating 5 BTC to you!  I hope you accept my raw appreciation instead of a returned donation
Thanks!

Cypherdoc,

Be careful running two clients that use the same keys.  Weird things can happen.  Armory should be robust to most of it, but I'll be interested to hear if that's really true.   Satoshi client has a habit of getting confused, and locking inputs based on transactions that aren't actually valid (because you sent a tx, and then satoshi client tried to spend the same outputs before it got the update, locked the outputs, and then gets stuck).  I don't know how multibit is, in this regard...

If that 0.0001 is in the blockchain, Armory should find it.  However, in some places where values are displayed, the values might be truncated (but that should be big enough...).  Also, sometimes you just have to close the wallet properties and reopen it, in order for the data to be displayed correctly.

The thing to do after importing, is to go into the wallet properties and double-click on the address.  It will show you all the transactions that address has ever seen.  If it shows nothing, then check blockexplorer or blockchain.info for that address.   I've never seen any of those online services be out of sync with what Armory says.  But that doesn't mean it can't happen... (please let me know if it is)



I highly recommend that you wait for the other client to receive the transactions of the first client, before attempting to do more transactions.  They should have no problem, as long as you give them time to have the latest blockchain data before constructing new transactions in either one.

I have plans in the far future to allow for a headers-based implementation.  As long as you have the headers, you wouldn't need the whole blockchain (after all, that's kind of what the headers are for).  Thus, if you just created your wallet, you wouldn't need to download the old blocks.

But that's a non-negligible paradigm shift for Armory.  Until then, I'll just focus on not loading the whole blockchain into RAM.  While that's a significant paradigm shift, my upcoming solution will work on systems <1 GB of RAM and not run off to infinity with the size of the blockchain...

(P.S. - I'm talking about available system RAM -- Armory doesn't use 4 GB right now, but you'd have a tough time using it on a Win7 machine with less than 4GB)

Awww, c'mon!  1,800 page views, but less than 18 donations so far (1%).  Nothing in the last 24 hours.  If it wasn't for the awesomeness of a few key donors, I'd be really disappointed right now  

If even 10% of you donated between $25 and $50, I would pretty much a full-time Armory developer!   And I would get some nice bulk discounts on USB keys and Tshirts (that helps even more!)


If anyone would like to suggest better ways to find people willing to contribute, I'm open!   It's probably not a matter of "spin", but RocketHub did suggest the following interpretation:   Do not think of these as donations.  Consider it a marketplace to buy the overpriced rewards I have posted, knowing that the extra money is going to a good cause!  Even I feel better promoting it when I think of it that way (I guess that's what fundraisers are, aren't they?)

Giantdragon, maybe I'll take you up on your free advertising!  Thanks for the offer, I'll contact you soon.

P.S. - I added a screenshot of Armory to the top post, I hope that will get people's attention better.

Actually, they are.  Sipa has a test branch implementing the deterministic wallets I described above (the HMAC version)... though it will probably a little while before it gets fully tested and merged.   Once that happens, I will add support to Armory for it.

Mila,

Look at Armory.  It provides exactly what you describe:  keep the full wallet somewhere else (maybe not even touching the internet), create a watching-only copy of it (no private keys), and use that on your website to distribute addresses.  There is no JSON-RPC interface to it (yet!), but I could help you produce a straightforward script along the lines of "getAnotherAddress.py" that will read your watching-only wallet fie, and return the next unused address.

If you want more information, see the presentation on my webpage:  Using Offline Wallets in Armory.  That doesn't show you exactly what to press, but it explains how the process works.  Please PM me if you want help setting it up

This is one of the reasons I created watching-only wallets -- risk-free webservers.  I hope you get some benefit out of it!

I picked a sub-optimal construction, and wished I had talked to gmaxwell and sipa before I commmitted myself to it, because I like theirs better.  However, there's nothing wrong with what I did, it's just that it can be a little slow, and theirs has some nice properties (like random access).  I will be adding support for their method in Armory and deprecating mine (eventually).  Until then, here is both algorithms:

Let the root address be considered keyIndex=0, C be the chaincode, and O be the order of the elliptic curve group:

Mine:
M = doubleSHA256(PublicKey(i)) XOR C
PrivKey(i+1) = (PrivKey(i) * M) mod O


gmaxwell and sipa use HMAC construction; || represents concatenation
PrivKey(n) = SHA256( C || SHA256(C || PubKey(0) || n) )

The QR code is the exact same data, but in a QR code.  The primary goal was that you could use the paper backup as both a backup, and a means to transfer a wallet to your smartphone, just by scanning it (there are currently no Bitcoin apps that leverage my wallet format, but I'm getting help to work on one, now).  But it would also be useful if you have a webcam setup for scanning QR codes -- it'll pick up the exact same letters as shown on the page, and you can just copy the text into the "paper backup import" dialog.

For anyone in this thread who has no idea what I'm talking about, the paper backup looks like this:

The "root key" is a Bitcoin address that serves as the "root node" of the deterministic wallet.  All other addresses are based on it.  The chaincode is another 32-byte number that helps you get from PrivKey(i) to PrivKey(i+1) or PubKey(i) to PubKey(i+1).    In order to have "type 2" deterministic wallets, you will need to be multiply the priv/pub keys by a number... so the chaincode is used to create that number.

As described by gmaxwell, you could easily use lots of different chaincodes to create different address "branches".  Right now, in Armory, there is only one chaincode per wallet.  But you could could add multiple chaincodes to create multiple "branches" that would then appear unrelated -- i.e. you could give someone a watching-only wallet with the first chaincode, another person with a different chaincode but same root public key -- they'll generate two completely different address chains even though they both have the same root public key.  You can generate all private keys in both, but the two people will not be able to generate or even recognize addresses on the other branch.

If someone steals your wallet, they get all your old addresses and the next 100, but no more.  When you start using addresses, the key pool keeps getting refilled with random addresses based on the random number generator on your computer.  The attacker will generate different (and thus useless) addresses.   Therefore, if someone steals your wallet, it "unsteals" itself after you go through 100 addresses.

Since the point of deterministic wallets is to produce the same sequences of addresses every time, the attacker will always generate the exact same addresses until the end of time.  They have permanently stolen your wallet, and could wait years before executing an attack, if they knew you were going to keep using it.

However, I'm of the opinion that this is basically irrelevant.  The severity of attacks on both types are not much different, and many cases they are the same -- because if the attacker has access to your system to steal it, they can install a process to continue stealing your wallet.  I firmly believe that users' not having sufficient backups is a tremendously more significant risk to their wallets.  As such, deterministic wallets are superior since they only require one backup at time of creation.

I agree with you 20%.  The first issue is that I want Armory to be to a "global" application.  Right now it's feeding the niche crowd of users willing to set everything up and who have the computing resources to use it.  In other words:  Geeks.  But if this is going to make impact for the greater community, it needs to be usable by anyone.  It's a lot of work, but it would easily improve exposure of Armory 10-fold. 

Second of all, it may be runnable with 4GB of RAM right now, but it won't be in a year.  The blockchain size is increasing in size much faster than modern computers are increasing in available RAM.  There is no way around it:  the current paradigm is unsustainable.  In fact, the blockchain has almost doubled in size since I started this project 8 months ago... and that's when I made the decision to just hold everything in memory.  I didn't anticipate it to get out of hand so quickly...

I just attempted to do a 32-bit python installation along with twisted and pyqt, on a Win7-64 system.  Surprisingly, it compiled in Win32 mode, but Armory crashes as soon as it starts.   I was hoping to make a Win7_64_Python32 build, but that looks like a pipe dream at the moment.

When I finally get real binaries built, this will go away (as all the necessary DLLs will be packaged with the binary).  One day...

When you say it "helped," do you mean that everything links and runs properly, now?   Did you have to use the LD_PRELOAD line?    For whatever reason, "libcryptopp" and "libcrypto++" are kind of different libraries.  But only kind of... I never fully understood what's different.  Apparently, the cryptopp library on your system is missing some symbols that crypto++ has.  It might simply be a version thing...

Matt,

I think the misunderstanding comes from a perception that somehow Armory is "Done."  I will make all kinds of plugins and extras for it, Android apps, whatever, but only when it's actually done.  That includes:

• Getting it to run on systems with less than 4GB of RAM
• Running it without the Satoshi client in the background
• Being able to make Windows, Linux and OSX binaries, installable like an actual program
• Complete multi-signature interface with everything I've already listed (multi-sig, two-factor-auth, buyer-seller-escrow)
• JSON-RPC interface
• etc

There's a good reason it is "alpha," and many more months of work to get it to a final release with everything I think it should have.  Perhaps, at that time, I will contact you for advice/help on how to monetize future efforts.  But until then, I don't want corrupt it with ads, obligate myself to some big core donors, or stifle momentum to work on business-specific add-ons, just because I could use a few bucks now.  I want it to have everything imaginable, and also be free.  That sounds like a good crowdfunding platform

rjk,

Unfortunately, it hasn't reached that stage yet.  It still requires the blockchain in memory, though I have made a lot of progress switching to a non-full-RAM implementation.  It was an early design decision due to it being a creative, experimental tool, not a wide-user-base client.  I'm paying for that now, by having to overhaul pieces of the C++ code run like a "normal" application.   Unfortunately, it's a lot of work, and will need a lot of testing when it's done.

And, Armory still requires the Satoshi (regular) Bitcoin client to be running -- Armory connects to it as a single peer and uses it to receive not-in-the-blockchain transactions yet, and to send tx to be broadcast.  This gives Armory the security of having all the most advanced networking security behaviors in the regular client, as well as full-validation behaviors, but does make Armory even more burdensome to use.

THIS is why Armory is still alpha.  It's very usable if you have 4GB of RAM and don't mind running the regular client, too.  But it's going to take quite a bit of work just to support everyone else. 

It's been so long since I implemented the functionality (and now I'm at work where I can't check), but I did have a setting for "ExtraWallets."  That setting is a list of paths where you have other wallets not found in your app-data directory.  Armory will then look for that wallet when it loads, but only when Armory is restarted.

The issue with this is that the Ironkey only manages the encryption of the data on the device, but your system will still be accessing your wallet private keys in order to sign it.   A virus on the online system that is watching your process memory will have no problem picking out the BTC private keys when you go to sign a transaction.   It's because the OS does the crypto signing, which means it will have to copy the private keys from the IronKey wallet to the local RAM in order to apply it. 

In other words, you can't really get the benefit of the offline wallet unless you have a separate OS to do the signing for you.  Granted, the way I've set it up, the "OS" only needs to process a couple hundred bytes of tx data and run an ECDSA signature module -- meaning you could make some pretty super-lightweight "offline systems."  For now, I feel like there's too many old laptops in the world waiting to be junked that are perfectly good for this, so this is an acceptable solution for now.

Geez Matt.  The goal was to give the community a chance to pay for it and help me avoid poisoning it with ads, or "selling-out" to someone just because they have a lot of money (and thus I acquire an obligation to satisfy some suits instead of myself).   I don't want to monetize it and corrupt it, I want to provide it for free, which will have the most impact on the greater Bitcoin community.  I'm not in this to get rich, I'm in it to make an impact, and I can make maximum impact by keeping it open and pure.   This is exactly what crowdfunding is for.  Sorry I'm not a businessman like you.


Did you read the page?  I laid out exactly what everyone is getting for their money.  To a tee.  Exactly what features are expected, the length of time I expect to leverage the money, and conditions for underfunding and overfunding.  I don't think I could get any more clear.  And FYI, Armory is not even close to "done."  This is just the beginning!  All the multi-sig tx support, two-factor authentication, and a buyer-seller escrow interface need to be implemented, among other things.   If you don't like it or don't agree, then don't donate.  

P.S. - Let's not pollute this thread with this discussion.  Please pick it up in the crowdfunding thread if you would like to discuss further.

I just posted a call for help crowdfunding for Armory Bitcoin client.

I am the developer of Armory, which has recently been released as alpha.  It has all sorts of great stuff like deterministic wallets, multiple wallets, watching-only wallets, permanent paper backups, key importing/sweeping, usermodes, and a complete offline-wallet interface for keeping private keys offline while still managing funds online.  It took me 8 months to get this far, but I need some funds to keep going.  I have plans to implement a full multi-signature tx interface, buyer-seller escrow interface, and two-factor authentication via smartphone without a third-party. 

Please check out the thread above, or go straight to the crowdfunding campaign website and donate! 

I've been asked about this a few times.  I think I will do it eventually, at least for Windows (where there's a fairly consistent environment).  But that's low priority, at the moment...

If you would like to do it yourself:  Here is the vantiygen thread, and the download link for Windows binaries.  You will have to run it from the command line to supply the arguments and make sure the window stays open when it's done.   But it's actually quite simple once you get to the directory with the executable in it.  You should only need to type something as simple as: 

 

The third option there is for GPU (OpenCL) vanitygen, which is, of course, much faster than the CPU.  There are many more customization options, but I'll let you look at the thread for that.   When you run it, it will tell you how long it expects to take (a timeframe for 50% chance of success).  6 letters (such as 1Cypher) will take a few days on a CPU, a few hours on a GPU.  Every letter after that, multiply by 58 (it gets out of hand quickly!).

Check back with it every couple hours and see if it succeeded.  Just copy (or type) the very long string into the Armory import-address dialog and you're done! 

Shadow,

I wanted to follow up on a recent conversation I had with you concerning Armory and transaction fees. 

I made a mistake in my initial assessment of what I could do with it.  I have implemented all the tx fee calculations and exactly when they need to be applied.  The default behavior of Armory is to let you select 0.0 fee, but if the calculation determines you need more, you either have to increase the fee, or cancel.

I had decided to put in an "Override Minimum Fee" setting that you would have to change by hand, but it could be done.  This was all implemented and the dialogs are even created and work.  The problem is that since Armory connects through localhost-Satoshi-client, transactions that "need" a fee but don't have them, will not get forwarded.  Thus, even though the network is full of nodes that will take zero-fee txs, Armory only has one peer, and the forced-zero-fee transactions are DOA. 

It seems, the only way for Armory to do this, is if this fork is used along with the over-ride min fee option (though, I haven't tried it).   In the future, I will have some kind of independent networking that will allow me to sidestep this problem.  Until then, I can't live up to my promise of supporting forced zero-tx fees!