Topic: Armory - Discussion Thread - page 226. (Read 521855 times)

Build instructions have been posted!  (see the bottom of the top/original post)

I'm sure people will still have problems.  But that's why this is the testing phase and not the release phase

I'll move everything into the master branch and create executables, when I do the first official release.  Until then, everything is in the qtdev branch, and being a tester requires compiling. 

Zero-confirmation transactions are so badly botched, I've disabled them, but they can be re-enabled through the menu options.  Just don't be surprised if you see wacky stuff... Anything with 1+ confirmations will be accurate.  My first priority before release is to get rid of the terrible zero-conf hack, and replace it with the "correct" solution.  That's my task for this weekend...

As stated before:  this is pre-alpha.  Do not put any money into this program unless you expect to lose it!  Therefore, Armory defaults to testnet.  If you really want to try it with real money (because you don't feel like waiting for testnet to download), you can run it via "python ArmoryQt.py --mainnet" ...  but I only say that because I know someone will insist on it despite all my warnings/pleadings not to do it!

Unit testing is a PITA. I commend your work.  Once I get it running, I'll send a donation

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.

Haven't read the whole thread but if you have time you could add vanitygen and oclvanitygen with all the available options to click conveniently (some options: https://bitcointalksearch.org/topic/m.675624 )

Will donate once I have time to test it this weekend.

I don't think so, more like this.

Spends go to addresses that require multiple keys to move. Every teller can have a watching version of the main secure wallet. Nothing need happen except when the controllers of the funds need to move them, then they pass around the transaction each signing it.  

edit: Just one more problem Bitcoin solves. No more sticky fingered tellers.

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)

Concerning the offline transactions feature...

Would a feature like this be used for a large company like Best Buy?  Best Buy would create multiple wallets on each cash register that would be offline.  At the end of the day the wallets are collected, imported on an online computer, and then broadcasted.

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!

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 

Another reasonable blockchain index might be to split the chain into 20-30 segments of consecutive blocks.  Maintain a small bloom filter in RAM for each segment recording which addresses/transactions are present in the segment.  The index's RAM requirements would be minimal but still prune the search space substantially.

I think this should say "Use the checkboxes on the right to.."



By the way, really great job!

Oh great, guess I can't recognize bitcoin addresses after midnight. I'll get the first one in.

edit: I'm a noob, didn't get in first, hadn't checked blockexplorer, only googled. Google ought learn to check strings for being bitcoin addresses so it doesn't have to wait till it crawls blockexplorer again.

looks great, watching.

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)

1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX

what's this?

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!

Amazing... 

Excellent ! The right approach.
You already did what i asked the mainline devs for (many times), and they never complied, even though making a simple setting in configuration file is not that much coding really.

I will give your client some testing and perhaps i will be using it as my default BTC client some day.