Armory has an exhibitor booth at the conference in two days, and I've been racing to finish this demo feature.  I don't have time for full testing&integration before the conference, but it should be good enough to demo it on testnet.   But I do need people to dig in and tell me what I messed up.   What combination of things doesn't work?  What's going to embarrass me?


What's New?:

There is a branch of Armory in the repo called "Backup Center".  I have also linked a standalone executable for Windows 64-bit.  This contains a completely revamped backup system in Armory.  Like.  Really revamped.  

• Backup center to help you decide how you want to backup
• Optional SecurePrint feature to encrypt your backups with a code displayed on the screen
• Can now print imported keys on paper backup (with SecurePrint!).  Though, no restore yet for SecurePrint imported keys.
• Newly-created wallets now only require backing up half the amount of data!  And everything is backwards compatible.
• A full M-of-N backup-and-restore interface!
• The M-of-N system can do any mixture of printed sheets, files and with or w/o SecurePrint

These new features are not ready for mainnet/prodnet.  ONLY USE THIS ON TESTNET.  But I hope that I'll be able to get my QA in place to release in the next two weeks.


To claim the bounty:
The bounty is big and dangerous for me.  It's a lot of money I might give away for very little.  But this also won't be easy to redeem!  So here's the conditions to receive the bounty

• I will award up to 4 bounties, to those who give the best feedback.  Preference given to those who respond first.
• A email must be sent before 4pm EST, Thurs.  Use alan.reiner@gmail.com.  You must not post your findings here, because I need people to actually test it, not just see other bug reports and send it to me trying to claim the bounty
• You must have found bugs.  I know a few that I can easily work around in a demo.  So I know there are bugs to report.   If you are really testing it, you'll find a couple for sure.  The more you convince me that you actually, thoroughly tested it, the more likely you are to get the bounty.
• You need to be patient.  There's going to be a lot of copy-and-pasting of backup data.  Probably lots of typing.  This is why the bounty is so high -- it might be boring and take you an hour or two.  Try copying the backup info into a text editor, and use that for copy-and-paste into the backup dialogs
• You need to provide feedback.  Beyond just finding bugs, you get points for telling me what was confusing.  What could be improved.  How to rearrange things.  Etc.

Also be patient, because I won't have time to evaluate bounties until next week.  I have a lot to do before the conference, so I'm eating bug reports now in a hurry.  I will go back through the emails next week (after things have settled down), and figure out who gets these bounties.  

Testing Focus:

DO NOT TEST DIGITAL BACKUPS OR "EXPORT KEY LISTS".  That's not part of this exercise.  Just the single-sheet backups and the fragmented.

Test creating backups. Restoring them.  With SecurePrint, without, new wallets, old wallets (don't worry about the "Version 0" M-of-N backups), mistyping data, mixing up data.  Mixing paper backups, files, SecurePrint, plain, all when restoring M-of-N (yes, you can do that!).  Also, I could use some testing of Armory in general, to make sure I didn't break more stuff.  Tiny things/quirks are appreciated, but you get points for the most-definitely-not-right-and-impacts-usability bugs.

To use it in online mode on testnet, you'll have to disable auto-bitcoind in the settings and run it yourself.    I have only tested in offline mode.  There's probably lots of juicy bugs in online mode, which is partly why I'm limiting the bounty to 4 people.  



Now. I must sleep....


EDIT:  I just wanted to point out that one of the bugs is that the dropdown menu from the main screen does not take you to the right place.  You have to use the new button in the upper-right to get to the new "Restore Wallet" dialog.  It's kind of a lot of work to rebuild the Windows executable, so I'm leaving it for now.

I'm in the process of upgrading the message signing to be compatible.  There was just recently a bounty that was claimed.  But I'm under the gun for the conference that's happening in two days, so I may not get to it for a week or two.  

You don't have a way to verify it unless you use Armory, but you only need to run it in offline mode which has nil resource requirements.  It will start instantly, and you can verify instantly.

--Intsall Armory
--Delete the shortcut on your desktop
--Go to your start menu and find Armory, and click on the "Armory (Offline)" link
--Go to "Tools"->"Message Signing"
--Click on "Import Signature Block" on the bottom-right.  
--Copy the user-supplied chunk of text and click okay.  Armory will verify if the signature and display the message if it is.

This can all be done without making any wallets, or using Armory in anyway.  Maybe this is sufficient for you until I update it in a few weeks?


P.S. -- The reason it is incompatible is actually because Armory came up with the feature first, before Bitcoin-Qt  But they went their own way when they finally did it, and I never had it a priority to upgrade it.  Until recently, since I've been getting a lot of requests like this.

It's pretty satisfying to see people discover--and get excited about!--a feature that I carefully implemented to try to fill in all these little holes, not knowing if they'd ever actually be a deterrent for anything.  I don't know if it's making any hackers' lives more difficult, but at least someone noticed the effort I put in to do it   Thanks!

That's correct.  The terminology I use is that the chaincode is "sensitive" but not "private".  Meaning, that you shouldn't make your chaincode public, but in the absence of QCs, it's just a breach of privacy, not security (people can now see all your wallet transactions, but cannot spend your coins).   If QCs are around, that's a whole different story -- in that case the chaincode would need to be kept securely, though the Bitcoin protocol would be changing to QC-resistant algos, and all this discussion about it is probably moot.

Indeed, vanitygen has a regular-expressions option, but you can't use the GPU with it.  So I had to use regular-old-CPUs to generate that address, which was expected to take about 70 days with my existing CPU power.  I had a bunch of miners laying around eating GPU cycles, but idle CPUs.  So I put them to work.

It was supposed to be 70 days for 50% chance of finding such an address.  I got lucky and found it after like 4-5 days.  And I've been a celebrity ever since then

Armory will be upgrading to BIP32, but at the moment it uses it's own homegrown version of "Type 2" deterministic wallets.  After all, it was the first application to implement them, so I couldn't really have followed any standard   But it's not homomorphic encryption.  Homomorphic encryption is pretty neat and enables some pretty cool capabilities, in general, but I haven't thought about whether it could be useful for Bitcoin.   I bet, if we upgraded the scripting environment, we could find something interesting, but I'm not sure how useful it would be.  It would certainly be a fun discussion to have...

For reference, Armory's wallet chain together like this:


Then


Where the multiplication (*) is scalar-multiplication-mod-N in the first line, and it's elliptic-curve-point-mult-by-scalar on the second line.  The magic of elliptic curve math is that if N is equal to the number of points on the elliptic curve, then you end up with matching private and public keychains on both sides.

I had actually been meaning to document this precisely somewhere.  I guess this was my excuse.

I'm not actually sure.  I'd be surprised if they were different, though.  So you can use either one (and let me know if that's not the case).  Unfortunately, I don't have a 13.04 system near me, so I can't investigate at the moment.

The newest version of Armory runs Bitcoin-Qt for you.  That's a "feature".  But it's an annoying feature if you have some non-std configurations.  You can go into the settings and turn it off, to run it yourself.  Or point it to where it's installed and let it do everything for you.  Or let it install it for you, which should work, but who knows, with all these different system configurations.

The beauty of one the last revelations in that thread was that you can define it in terms of that hybrid tree, but implement it with a regular iteration over the natural sorting of the database.  In other words, if you iterate over the database and are careful about tracking where you were and where you are, you can perfectly simulate the hybrid PATRICIA tree without actually implementing all its complexity.  And at the same time saving all the space you would've spent storing pointers.  You simply define it in terms of the hybrid tree (skip strings, omitting NULL pointers), but the actual implementation will be much simpler.


I was just thinking that in the future and/or when developers decide they don't like LevelDB, we may need to switch.  For instance, I read that LevelDB had some problems above 200 million entries.  I don't know the exact parameters (if it's always 200 million, or if it's DB size, etc), but apparently the scalability and robustness may not be there for the long haul.  But it will work perfectly for a proof-of-concept.


I was actually talking about some discussions with socrates outside the thread, on IRC.  You said "I think it's a misuse of terms", but no, actually it's not.  Your recap is accurate concerning what I originally proposed.  But socrates took it one step further, saying that you could build on top of this to create a fully-validating node without storing the whole database.  I believe it involves downloading and verifying parts of the chain in real-time, as you are verifying new blocks.  But it can be done, because if you are confident in the state of the blockchain at block N, you can verify block N+1 efficiently given the availability of this new datastructure we are building.  The node wouldn't be very useful for seeding other nodes, but it would at least enforce the rules on new blocks, and theoretically could even solo mine without holding everything.  

To me, it didn't seem very possible that you could have a bunch of low-storage nodes doing full verification, but I also didn't have the patience at the time to flesh out the idea with him.  Perhaps given a system with a high density of full-storage nodes that can help the lite node do its verification, but it certainly wouldn't be feasible for the network to be made up of them, if no one is serving the full data set.

If he's right, that dramatically loosens the specs needed by future miners, when everyone is predicting that only super-computers/clusters will be able to verify-and-mine.  I have my doubts, but we should definitely invite him to expand on that, and even if it's not completely feasible, there's will probably still be useful ideas in there.

Ay.  I forgot, 13.04 puts the python-dev files in a different place.  I just ran into this problem on my new laptop (with 13.04), and I forgot exactly how I fixed it... but a search of the /usr dir for libpython2.7 should turn up the correct prefix to use.  Then you can replace that line appropriately.

Sorry for the inconvenience.  I'm battling a few other crises at the moment.  Alternatively, now that you're on Ubuntu again, you can use the .deb package (which will give you a "bad package quality" warning, but it's legit, I promise ).  It is even signed with my offline GPG key, so you can check it to be sure, before you install it.

Understood.  I'm working on it.

You can export your private keys from the wallet properties dialog, under "Backup Individual Keys".  You can get a list of them either using "PrivBase58" or "PrivHex(BE)".  You might have to remove the spaces and the prefix for it to import properly into another app.  I promised that the next update will have an option to remove those artifacts for you.

I am well aware of the problem, hence the warning on the downloads page about having sufficient RAM.  I'm working diligently, and hopefully will have something in the next few weeks.  Thanks for being patient, but I totally understand you wanting to get away from it for now.

By the way, did you switch you to the 64-bit download?  It won't improve scanning time (you need more RAM to do that), but it dramatically improves stability once it's loaded.

http://bitcoinarmory.googlecode.com/files/armory_0.88.1-beta_win64.msi

jim,

When did you last reinstall?  If yo uare using the version posted before a few days ago, you are likely to see this crashing problem.  I recently posted the 64-bit version which has resolved a lot of these problems.

Please uninstall the previous version, and then install the new 64-bit version I posted a couple days ago.  That has solved this problem for a lot of users.

I'm working on updating the blockchain engine to solve this problem, but it's still a couple weeks away (it always is a couple weeks away....).  Luckily, the 64-bit version has been able to hold on to quite a few users.

Please let me know if that works (or doesn't).

I forgot to mention:  you must uninstall the 32-bit version before installing the new version.  I have no idea why, but the installer refuses to overwrite all the 32-bit installation files.  If you don't do this, Armory won't even start up.

I'm working on the updates now that will make all this scanning go away.  But it's still a little ways away.

Until then, I think I figured out that the 32-bit version (originally the only 0.88.1 version released) is the culprit.  Can you please download the 64-bit version and try it out.  I think because of the resource usage, the 32-bit binary is running out memory space.

Hopefully that will solve your problem until I finally get this RAM-reduction release out.

This is what the "heartbeat" functions are for  

-- Add a widget somewhere that will show the price (we'll call it self.goxWidget = QLabel(''))
-- Create a function like below
-- Add it to the extraHeartbeatAlways list  (extraHeartbeatAlways.append(getGoxPrice))


You could set the modulo to 10*SECOND for testing.

Okay, I will update that "Backup Individual Keys" dialog to make that easier.  No one ever sent me the accepted formats for these sites (and I never spent the time to go investigate it myself).

If you're serious about your business, spend $299 at 99designs.com.  The site lets you crowdsource your logo to dozens of graphics artists competing for your money.   You will interact with the designers and give them feedback, and they will continually refine the designs until you're happy.  In a week, you'll have a perfect logo.

For reference, that's how I got my Armory logo.

@maaku

Thank you.  I think you are a good match for this development activity, as you clearly have the self-motivation and technical expertise to pull it off.  And you have the proper attitude as well -- sober but encouraging. 

One thing we might consider is renaming this proposal.  The thread was started a year ago with the phrase "Ultimate Blockchain Compression" because of a really silly oversight on my part:  that the address-indexed DB would have to be in addition to the txHash-indexed DB.  I originally thought it would be a replacement for the tx-indexed DB, but you clearly need both.  Therefore, this necessarily adds resource usage on top of an optimally-pruning miner.  I think the recent discussion where I realized that you can eliminate all the pointers, makes the overhead much more manageable, but it's still non-negligible.    I don't know your real name, but if you make this work, perhaps it would we could just name it the Reiner-Maaku tree   But I think the "UBC" part should be adjusted since it's not "ultimate compression" (though it does fit on top of an ultimately-compressed blockchain).

I'm happy to contribute to this design where I can.  As you pointed out, I'm quite busy, but I also think this is quite a valuable addition to the protocol.  Even if it somehow turns out to be infeasible, we'll learn a lot from the exercise that will help us do it right on the next try.  However, I'm confident that this will bear fruit with someone capable devoting themselves to it. 

You might consider/research using something other than LevelDB for the full nodes.  LevelDB is very fast and efficient for some things, but I fear it may not be reliable enough for the heavy lifting that will be done by the mining nodes in the [far] future.  For partial/lite nodes, LevelDB makes perfect sense, especially because it's easily bundle-able into end-user software.  But the miners of the future will probably be running dedicated hardware anyway, so they won't be terribly inconvenienced having to have a hardc0re DB engine available to run something like this, with all the robustness/ACID properties that are desired.   Therefore, it would be really nice to have a generic interface (or two interfaces, one for SQL and one for noSQL-key-value-store), so that something like LevelDB can be bundled with the software for "regular" users, and something more concrete can be swapped in for full-mining nodes. 

Also, I should mention that socrates/amiller had some interesting ideas that would be worth discussing.  He had an idea for lite-storage-but-full-verification nodes, which I'm still not confident it is possible, but he insists it is and we agreed to debate it in the future when I had time.  Maybe you can discuss it here before embarking on this journey, to make sure the design is extensible enough to accommodate it if it is feasible.

If only DWave actually produced real quantum computers.  To date, they have just been gimmicks, not actually harnessing the physical phenomena needed to ... work as a real quantum computer. 

Universal quantum computers are probably still decades off.  And that's what you need to apply things like Shor's Algorithm, which is what will break a lot of existing internet security (in addition to Bitcoin).

This has been discussed many times.  There was a nice robustness and simplicity by not saving data between loads.  But obviously not sustainable, and it's becoming too much trouble for users.

I'm working on it now.  It should be done in a couple weeks.