The issue is not breaking the passphrase.  It's that a purely-deterministic wallet without extra entropy will lead to many users, using keys that are identical, and then they'll end up sharing wallets -- which obviously will lead to one person taking the other person's money.  Then you'll have determined people creating wallets based on a common passphrases, and it will be very successful, because they will get to attack ALL such users at once.  They can just keep trying common passphrases until they find one that generates a wallet with money, then keep going.

That would be an utter disaster for Bitcoin.  There must be extra entropy added to ensure that no two users end up with the same deterministic chain of addresses.

Doesn't sound like the devs want to go that direction yet, though I have seen Gavin mention that it's the right direction to go.... eventually...

For now, you can simply wait for Armory, which should be officially released (alpha) next week.  It not only has deterministic wallets, but paper backup print option (see the screenshot on the thread).  Digital backups are great and all, but you never know if that USB key sitting in your safe will still work when you plug it in for the first time in a year... paper backups are forever!

Honestly, Bitcoin is so complicated under-the-hood, that development becomes quickly overwhelming unless you have a good setup for isolating pieces and testing them individually.  It's completely worth the time investment to make an exhaustive unit-testing suite to help figure out what new bugs you're always introducing (accidentally), and verify that things still work as expected.  Even with the tests, it can be extraordinarily frustrating to find problems, which seem to be reflected in many places at once.  Maybe this is one reason why so few people have succeeded at making such a client:  there have been multiple times I wanted to give up...

And now that I've been using all the features, myself, it's time to see how other people can break the software.  I probably haven't accounted for all the different strange combinations of behaviors of the users... and I'd like to catch that pre-alpha before people inevitably start using it with real money (which I don't recommend yet, but I know it will happen)

For licensing reasons, I want to avoid actually distributing anyone else's code with Armory.  However, it might be possible for me execute those tools if the user already has them on the system.  It's a good idea, but unfortunately will be low priority right now.  I have a a bit of core development left to do, and that would represent more of a luxury upgrade   Of course, though, it's absolutely trivial to copy the output of VanityGen into an Armory wallet and use those keys like all the others.  I've been doing it a lot lately, and the thought of battling pywallet + satoshi client is painful...

I think I fixed the bugs related to first-use (settings files, making directories, etc).  So if you were able to compile Armory, but couldn't run it, give it a shot again.  The latest commit to the qtdev branch should be in good shape.  Right now I'm to work on getting it setup on a fresh Win 7 install, to make sure I capture all the build steps.  Will post those instructions when I finish.

It would be used by anyone that wants to store their private keys offline, but still manage their wallet on an offline computer.  This does include companies.

The company would have a secure office somewhere with a non-internet-connected computer.  They would create one wallet per cash register, and the copy the watching-only version to each register.  Then the registers could monitor transactions, and generate addresses for customers, but the register would not be able to spend any of the money.

Then if the company wants to move the cash, they can create the transaction from the register, but the txs can't be signed.  Instead they are copied to a USB key, taken to the secure location, and the offline system signs all of them.  The final transactions are taken back to the internet and broadcast.

But this is useful for anyone who wants top-notch security.  If I have more than $100 in BTC, I'll be keeping it in a wallet that has never touched the internet.  By using this feature, it is virtually impossible for an attacker to compromise your keys, because the private keys have never left the offline computer.  Some creative USB key viruses might succeed, but that's a big stretch, requiring a very specific, targeted virus -- and if you're concerned about that, you can do something creative using the raw transaction blocks of text (perhaps convert them to QR code and scan from the offline computer?  then you never even plug in a USB key).

The community here has come up with all sorts of command-line tools for doing this, but they are all complicated and pretty much only accessible to the die-hards.   I believe that Armory will bring this functionality to anyone who wants to use it, and they might even figure it out without a tutorial!  If that works, then I've succeeded!  (btw, you can add donations to offline transactions the same as online transactions )


EDIT:  to answer one of your questions more directly.... wallets are never copied/moved after the initial distribution.  Once they are in place, the only thing that is moved/copied between systems is transaction files (*.unsigned.tx and *.signed.tx).  In fact, the offline computer doesn't even need the blockchain!  That's innovation!   (the other solutions I mentioned above which are complicated, do require making sure the offline computer maintains a sync'd blockchain)

Offline transactions work!    I successfully created a transaction from a watching-only wallet, saved it to USB key (as an *.unsigned.tx file), then opened it with Armory on my non-internet-connected computer, signed it and saved it back to the USB key.  Then loaded it and broadcast it from the online computer.  Booyah!.  I also made sure that Armory runs without an internet connection, allowing you to manage offline wallets.



With this feature complete, I'm going to focus on helping folks get Armory built and running on other people's computers, and work out the little bugs having to do with system settings that I couldn't account for in my personal testing.  It's going to be a little bumpy, but I'm sure there's plenty of folk here up for the challenge!  The biggest issue I see is Windows build instructions, and wacky layouts on systems that aren't mine.  Please don't hesitate to PM me with complaints about what doesn't look right.  I'll do my best to fix it in a platform-agnostic manner.

Offline Transaction Primer:

Create the wallets

• (1) Load Armory on offline computer
• (2) Create a new wallet (encrypted or not)
• (3) Double click on the wallet and click on "Create Watching-Only Copy" on the right side
• (4) Save the file to USB Key
• (5) Load Armory on online computer, and select "Import Wallet"
• (6) In the wallet-properties dialog, click on "Belongs To", and click the checkbox that says "This wallet is mine".  (optional: make sure that any funds in this wallet are part of your global balance).
• (7) Use the "Receive Bitcoins" button to generate addresses for this wallet

Send Bitcoins

• (1) Double-click on the offline wallet, select "Prepare Offline Transaction" on the right menu
• (2) Create the transaction as you normally would, click "Create Unsigned Tx"
• (3) On the next window, press the save button to save a *.unsigned.tx to the USB key
• (4) Take USB key to offline computer, and click "Offline Transactions"
• (5) Load the file from the USB key, review it, then press the "Sign" button (save the *.signed.tx file to the same USB key).
• (6) Load the signed.tx file on the online computer, hit "Broadcast".  
• (7) Done!

Indeed.  I'm just about to do a testing release, which has most of the Armory feature list implemented -- including address sweeping and importing.  In fact, the design of that dialog was based on this thread!  I had to disable zero-confirmation transactions until I have time to put in the "correct" solution, but just about everything else is working, or at least usable.  

I've already pulled in a bunch of VanityGen addresses and use it to manage donations.  Then I used the key-backup dialog to print out a list of imported keys onto a single sheet of paper, and tucked away in a safe place so I can never lose them.  

And yes, it supports mini-private key format, and the Base58 private key format [0x80 + 32-byte-priv-key + 4-byte-chksum], as well as raw hex dumps of private keys, and it even makes sure the private key is in the right endianness (assuming you know what the Base58 address is supposed to look like)!  

Now that offline transactions are working, I'll be releasing build-instructions shortly!

If a transaction shows up in a block that uses an arbitrarily complex, non-standard script (but doesn't use any disabled op-codes), it will be accepted by all the nodes as long as it is a valid script (and if it's a TxIn script, that it evaluates to true with the TxOut script being spent).

However, the act of getting such a script into the blockchain is fairly difficult, because no Satoshi-based nodes will relay transactions with such scripts, and no miners will include those transactions into the blocks they are producing.

What this means is that, you can use all the advanced scripting capability that isn't specifically disabled, under two conditions:
(1) The scripts are ultimately valid
(2) You mine them into a block, yourself

In other words: no one will help you put those scripts into the blockchain, you have to do it yourself by solving your own block.  But those blocks will be accepted as part of the longest chain once it's there.

I think there's a lot of different, feasible solutions to handling this.  Luckily, optimized data structures are my specialty.  I just haven't spent the time yet to figure out what the space- and time-efficiencies are, of the various indexing options.   I do want to see Armory move towards "lightweight" in the far future, so I might start from headers-only and figure out the most "bang-for-the-buck" in terms of how much compute time do I save for each byte of extra RAM I use.  I would guess that there's a lot of variations on prefix maps that simply give "hints" about what data is where.  The keys and values of the map may not be unique to individual addresses or transactions, but they would cut down the HDD search space two or three orders of magnitude.

But I'm a long ways off from that.  For now, I'm focusing on making Armory a powerhouse of features and robustness, without requiring 4 GB to run it.  I believe mmap will take me most of the way there. 

On that note, I was able to get Armory loaded into a fresh install of Ubuntu 10.10 (32-bit).  With nothing else running except for Satoshi client and Armory (with blockchain synchronized), the total system memory usage was 1.7 GB.  So it seems, a system with 2 GB of RAM might be sufficient for full-blockchain operations - as long as you aren't running much else.  By the time the blockchain grows to exceed the 2 GB threshold, I will have implemented a better solution.

The places I'm really lacking experience at the moment is in the PyQt layouts.  I have very little experience with PyQt, and I noticed the layouts work great on my Ubuntu 10.04 installation with 1920x1200 desktop, but not so good on a smaller monitors, and possibly completely out of whack on Windows.  The app windows can be manually adjusted, but it's really not ideal.  If anyone has good PyQt/PySide experience with this, please let me know.  I might be inclined to toss a few BTC at someone who helps me figure out a good paradigm for getting this right 

Why is there an assumption that the checksum is any different than the rest of the letters?  The address is created from 25 bytes.  The first byte is always '\x00' which corresponds to the first '1' you see in every main-network Bitcoin address.  So we will ignore that one...

But the following 20 bytes are a hash, which means it's all essentially-random bits.  Then, the checksum is just 4 more bytes, which are also a hash... which means it's essentially random, too.  When I say "essentially-random", I mean from the perspective of what characters will be used in the Base58 address, all letters are equally likely for all positions, except maybe the very first character after the '1', and that's for reasons that are difficult to explain...

But the point is that the address is created from a sequence of 24 bytes (addr + checksum) which are all essentially random, so why would some letters be more difficult to match than others?   If you want more information about how addresses are computed, click the bottom link in my signature.  There's a diagram halfway down that shows how addresses are generated from the public key. 

-Eto

This problem gets exponentially harder, the fewer characters you choose to have in your final address.  In this case, I only wanted upper-case letters, which limits each character in the final address to one of 24 characters out of 58 (26 letters in alphabet minus 'I' and 'O').   If your address was only one letter after the '1', you would have to generate 2.4 addresses (58/24, on average) to get all uppercase letters.  If it was two letters, you'd have to generate 5.8 (2.4^2) addresses on average before finding it.  Etc.  So for an address with 32 letters, you're talking 2.4^32 guesses before finding such an address (on average).

At 300,000 keys per second in vanitygen, it should take about two months (I calculate 70 days) to find such an address as I have in my signature (on average).

If you now instead change it to all numbers, you've now limited yourself to 9/58 characters instead of 24/58 (10 digits minus '0').  If you repeat the calculation using 58/9, it will take 6.4^32 guesses.  At the same key generation rate, I calculate it would take 3,022,041,992,597,561 days to find such an address.

So the answer to your questions is... no

I wasn't able to get GPU working in linux, but it turns out my cluster of CPUs was enough to create the address I really wanted :

    1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX

Am I really the first person that has done this?  FreeMoney didn't even recognize it as a BTC address.  At the very least, people should recognize that one when they see it

A donation is on its way!

That's my new donation address!  I got a little creative with regular expressions and vanity gen  (yes, I do have the private key for it, so I will get your donations)

One more feature down!

Despite the fact that I made the wallet file intentionally simple, sometimes nothing can beat plain old text files:




I have two more major features to implement before I officially release "alpha":
(1) Offline transaction pipeline [3/4 done]
(2) Fix zero-confirmation transaction handling

Once I finish the offline-tx stuff, I will post specific build instructions for folks that want to help me test it.  While people are testing, I'll be working on the zero-conf transactions, which was a temporary hack gone terribly wrong.  It's almost not even worth using in its current state, so I will just dive in and do it right, right now.

Has anyone here been able to compile and use Armory, yet?  The qtdev branch is in good shape (particularly, commit b7f0abf9).  There's nothing actually stopping anyone who wants to test it now -- I just won't be releasing any Windows build instructions until "testing" starts, and then binaries once "alpha" starts.  If you are in ubuntu (trivial!), please go ahead and try it out on the testnet.  I'm sure there's thousands of little 1-minute fixes that need to be made, but it's also quite usable right now!

Armory tries to detect three things:  satoshi-client connection, general internet connection, and blk0001.dat.  If any of those of are missing, you will get this dialog, or something similar.  However, I have not yet detected the case that all three are available but the blockchain is  not sync'd.  That's a case I will let fall through the cracks, for now (though, when I get full networking, I will be able to detect that we're not sync'd yet, and disable transactions).


Forced-fees are the default, but they are possible to disable if you manually edit the settings file.  I did this to make it possible to disable them, but I don't want it to look like I encourage it in anyway.  I don't want anyone complaining when their tx gets stuck (yes, I know it's rare, but I'm still responsible).

More teasers!  And I need some recommendations... I figured you folks would appreciate seeing more screenshots, anyway

This dialog is loaded whenever you try to send money from a watching-only wallet.  The goal is to explain how the user can execute the offline transaction without needing external advice (yes, some users will still not totally understand it, but that's why this is only available in the "Advanced" usermode).

I have spent a lot of time trying to fix the layout and the wording, and I still feel like it could be better.  What better way than to get feedback from the potential users!



-Eto

P.S. - Sorry I haven't gotten around to the Windows build instructions ... I want to get the pre-alpha code out as soon as possible before battling Windows issues.  Building in Windows really is a PITA.  See post #63 if you want to compile and run in Ubuntu, which is only a few shell commands.

Thanks for the apology.  It sounds like I need to go through the code and clean up some old comments.  I like to leave myself "TODO"s" and random comments about what isn't done yet, and then forget to remove them.

The reorg test is actually in the C++ unittests:  cppForSwig/BlockUtilsTest.cpp, and I believe the .dat files have been checked in as part of the test, too.  It's not part of the UI yet but you just reminded me that I need to make it part of the UI.  Perhaps check the isValid_ flag for a LedgerEntry and pop up some kind of message in the rare event it goes false.  I think the user should be notified that they just became a victim...

You should look closer at the code, because you completely misunderstood what you read.  I already ran an exhaustive blockchain re-organization unit-test and posted them on the forums a couple months ago.  Not only does my code gracefully handle re-orgs and double spends, but I even packaged and documented it, and put it on the forums for everyone else.    

I spent a 1-2 weeks painstakingly creating that unit test and stepping through the debugger hundreds of times to make sure it works perfectly.  I'm not pleased that you accuse me of "not focusing on correctness" when I have 2500 lines of unit testing code in my project.   Those comments you referenced were for additional things that I might want to do on a re-org, outside of updating the blockchain data structures.  At the moment, there isn't anything else.  

(To see the reorg-handling code, do a search for the variable txJustInvalidated_, and the function "reassessAfterReorg" in BlockUtils.cpp)

It is platform specific if I have to use a completely different implementation for each platform, unless they have identical interface calls (which I doubt).  Specifically, I'll have to do preprocessor branching to compile one set of code in Windows and another branch for Linux (and maybe yet another for OSX).  The question is how much code has to be branched to make it work?  My guess is that it's a lot...

As for address space comment, am I correct that mmap doesn't help me?  It sounds like if the blockchain is 2.0 GB, I have to reserve 2.0 GB of RAM to mmap it -- therefore I'm not really benefitting any folks who only have 1-2 GB of total system RAM.  Perhaps someone with more mmap experience than me can explain if there's anything I can get out of it, and how much different the code is going to look between platforms. 

Once I get official build-instructions out there for Windows and Linux (and actually make the first release), I'm sure someone will figure out how to port it to OSX.  I've tried hard to use platform-independent code, so hopefully it won't be too difficult.