Topic: Armory - Discussion Thread - page 188. (Read 521749 times)

I would like to test 0.79.99

Is there a git-branch corresponding to that or can the source be had some other way? I'd like to compile myself.

newest master says:


I'm having a problem (this is on a NFS volume):


Is this potentially fixed in the just-released version?

---

Armory Version 0.79.99 -- Initial Testing release

---

I didn't have time to compile for all architectures -- but I got 64-bit windows and 64-bit-Linux compiled (with an attempt at static compiling python, so it may actually work on any 64-bit linux...)  I have tested most of the features in both Windows and Linux, and there's no hint of a problem with anything.  This is mainly due to the fact that everything I changed in the C++ code was transparent to the UI-layer:  I hardly had to change any python code to get it to work!  This is very satisfying.

---

Windows 64-bit installer:
   Load Time:  Slower!  My VM is loading in 80 seconds.  Yes, that is unacceptable, and will be adding between-load memory so it only does it the first time.
   RAM Usage:  700 MB -- this time that RAM usage is a hard-number:  it's not going to scale with programs opening and closing.  On the upside, it should be no more than 200 MB, and I just have to find out where I'm allocating memory and not cleaning it up (luckily, there does not appear to be a time-dependent memory leak).

---

Linux 64-bit installer: armory_0.79.99-python2.6-1_amd64.deb:
   Load Time:  About the same -- my desktop is loading in about 25 seconds.  
   RAM Usage:  700 MB -- see above

---

Some other comments about what to expect:

(1) There's no reason this won't work in Windows 32-bit, I just have to get it compiling and built, there.

(2)  This version isn't going to look a lot different.  In fact, it's not supposed to.  But it's got entirely new architecture under-the-hood for blockchain scanning, which I have actually tested and maintains consistent data through a blockchain-file-split.  Previous versions will stop working when that happens... in about 2 weeks.

(3) If you are on 64-bit linux and normally use the python2.7 version, please try installing and running this version using the
The static compiling went way too smoothly, which suggests maybe I didn't actually do it right...  Please let me know if it works!

(4) I think that the unconfirmed balances are fixed.  They definitely had an error before (counting change-to-self as unconfirmed).

A few minor tweaks here and there, but it should work the same at 0.77.

Please help test!  Testing really just means, install it and use it like you would the previous version, and let me know if there's any strange/undersirable behavior, and/or any crashes!

cool! looking forward to that. Maybe you could even use the electrum wordlist? that way, I could just use my electrum sentence (adding 3 more words) which I already remembered (or course giving me a different set of addresses).

I actually really like the electrum-way for making seeds memorable.  It's a really slick technique.  But the current wallet design in Armory requires 512 bits of data to recover the wallet.  Electrum uses 128 bits, which takes 12 words to represent.  If I were to leech the idea right now, the user would be memorizing 50 words!

However, after beta when I get the new wallet format implemented, I'll probably be dropping to 160-bit wallet seeds, which would be about 15 words.  That's do-able.

I'm totally with you on not allowing joe schmoe to construct a brainwallet from a self-chosen seed. The inevitable loss of trust in bitcoin/armory could be devastating. However, please consider the electrum-way of doing this (random seed, mnemonic phrase to memorize).

Oh, about the user-stupidity-prevention: you're doing a great job: I really like you're asking a third time for the encryption key "you surely don't mind entering it a third time?", hehe. maybe you could even move that back in time a little (after the encryption that takes a couple of seconds). No harm done, right, since the wallet cant possibly have been used already, so if the user actually did forget the key while the wallet was being generated, you can just dump it and start over again.

I noticed for myself that I can remember stuff really well if I force myself to recall it in roughly the following intervals: 3 minutes, 3 hours, 3 days, 3 weeks. This is how I memorized my electrum seed.

Just send me an email at etotheipi (at) gmail dotcom, with the word "test" or "testing" in the subject line.  That way I can easily go back later and find all the emails and construct the list.  Thanks!

if you dont require high reliability, you can put me on the list.

See the second post on this page.  I describe why I don't want users to do that.  

But I won't be shy about admitting you can still do it -- it'll just take a little bit of work.  Armory assumes that any string entered is a valid wallet, as long as you use the correct alphabet and have a valid checksum.  If you have the skill to reverse-engineer the wallet-restore code and make it work, then I trust you'll use a responsible brainwallet seed  

Is it possible for users to specify the root key and chain code? Then we could have deterministic brain wallets and don't need a paper backup at all.

ALSO:  I want to construct a list of folks who are willing to help me test pre-release versions of Armory.  If you are willing to be part of it, please msg/PM/email me your address.  Like the announcements thread, it should be fairly infrequent that I put out a request.  But it would be awesomely useful if I had a better understanding of who is actually helping test, and whose interested to help with it.

Of course, I do testing myself, first.  But I can't catch everything.

It's on my list of things to do after Beta, to implement a coin-control feature.  Armory (application) asks armoryengine to construct a valid transaction from a list of addresses.  So it shouldn't be hard to just filter that list before it asks the engine for a selection.  Because of that, it's fairly easy to add this flexibility.  I just haven't gotten around to it yet...

---

And a follow up on my previous comments about releasing ... I do most of my testing in Linux (where I do most of my development), and I just noticed a crash in Windows that doesn't happen in Linux.  Therefore, I'm going to have to dig in a bit further before making a release.  Hopefully tonight, still, but debugging rarely goes as planned...

You can look at how blockchain.info does it.  They let you choose the address to send from (or all of them) and the address for change.

It would be even nicer to have it let you choose all addresses in a wallet, some addresses in a wallet, or one address in a wallet for sending and then one address for change.

Is your coin selection done from a list of addresses or from a wallet? If it's done from a list of addresses, this shouldn't be too hard to implement at all.

To be fair, I think I've gone to a lot of effort to warn users of stupidity already.  I just hadn't caught this case.

Try importing the same address into two wallets.  Migrating satoshi wallet twice.  Importing a private key with the wrong endianess.  Deleting wallets and address (it's a lot of warning boxes to click through).  Passphrase warnings.  Exposed keydata warnings.  Typo-correction in the entry fields.  Etc.

I know you weren't actually criticizing, I just wanted to point out that I have made it my goal to try to catch everything    Clearly I've got some loose ends to tie up, though (along with a unified backup dialog)

this is my brainwallet scheme:


why not use armory deterministic wallet instead? because I can't for the love of my life securely remember that seed.
Electrum solves this nicely with a mnemonic seed representation (12 english words) and I actually have my (randomly generated) electrum seed stored in my brain (tested many time, will not go away even with drug use)

I was about to put my savings on it (will still do it, but need a break first). Hadn't I discovered the problem with this idea now, I might've discovered in a couple of years, when I would've wanted to take some coins out of savings... that would've been an extremely BAD day! (I planned to distribute my current savings among the 10 addresses, but still, huge loss would've ensued).


I'm for the "stick to imported addresses"-flag on wallet and for having the user specify one of the addresses as send-change-to address (on first need and changeable thereafter). That would be awesome!


You can stick to your claim.

However, if you implement any of the above your software will receive the takes-user-stupidity-seriously badge from me.

Theoretically: yes

Do I want you to?  no

In fact, I've been having a long discussion with some of the bitcoin-qt devs about how to prevent users from doing this, or avoid the usual issues with it.  Here's why I can't condone pure-brainwallets:

-- Bob A. create's a wallet and wants to never forget it, so he uses sha256("Bob is cool") as the basis for his deterministic wallet
-- Bob A. adds 500 BTC to this wallet then goes to bed
-- Bob B., also a new user has the same idea and creates the same wallet by accident (or, equally likely, a malicious person starts trying lots of common passphrases in sha256(X) to try to find collisions -- you know it will happen [and probably already does]).  
-- Bob B. realizes there's all this money in his wallet that isn't his, transfers the 500 BTC to another address.

This sounds like user error to me.  Sure, it is... but Bob A is not the only one that suffers:

-- Bob A. wakes up to find all his money gone.
-- Bob A. gets on IRC, bitcointalk, etc, and starts crying about his money being gone
-- Bob A. blames Armory for losing his money and claiming the program is insecure and keeps asking me to refund him.
-- I respond by spending 3 days digging into the allegations and trying to discover where the security vulnerability is
-- Other users dive in and start trying to track the stolen coins and posting warnings about Armory and security issues
-- Bob A. won't admit he used a $#!+ passphrase.  It makes him look bad and doesn't get his coins back, so why would he?

No one wins in this situation, except for Bob B.   This is why I'm working with the devs to develop a technique that only 1 out of 2^x passphrases is even valid, thus requiring Bob to either use a real RNG to generate his passphrase, or use a program to find an extra x bits of entropy to add to his passphrase that allows him to use it.

i.e. sha256("Bob is cool") is not a valid passphrase.  But sha256("Bob is cool 1xbnw38kpq") is valid.  It's still memorable, but no one will be colliding by accident and it will slow down malicious users by a factor of 1/2^x, probably making it entirely infeasible.

That's not to say that people aren't doing this now, and not to say it couldn't happen right now and that people won't find a way around it.  I just want to minimize the occurrence of it, and my exposure to it when/if it does happen.
  

---

Fwhew!  Now that that's out of the way.  Think you should know that I'll be releasing a testing version tonight.  Version 0.79.99-almost-beta!  (that won't be official name).  This version will actually be pretty much the same, except it should work on Win32 (though I haven't tested that part, yet), and it will be robust against the B2G bug (like Y2K, but Blockchain-2GB).

All my testing so far has shown that it works with two minor caveats:  

(1) There's some rogue memory allocations that lead to 600-700 MB RAM usage overall -- this should be more like 200 MB after I fix it.  But it will still be usable on most hardware.  It does not appear to be a real memory leak, as the RAM consumption does not increase even when I leave it up for 2 days...
(2) Unconfirmed balances are not computed correctly.   In fact, it's a tad bit confusing.

Neither cases are showstoppers compared to the client flat out not working when the blockchain hits 2 GB, so I will release as is, if I have to.  Though I will try to fix both by the official release.  

can a brainwallet be used to generate a deterministic wallet?  does that even make sense since i haven't studied brainwallets?

maybe i should ask, can a secret phrase be used to generate a deterministic wallet?  then you wouldn't have to worry about change.

Ahh.  I can feel the thought process you went through.  I totally sympathize with you.  I don't know about you, such a mistake could've let to much more than 10 BTC loss!  So, it's not fun, but it could've been worse (always trying to stay positive)

I think it would be pretty easy to add a box to let the user specify what address they'd like to use for the change output.  That doesn't entirely solve the problem, but it would at least serve as a reminder and give you a way around shooting yourself in the foot like this.

I can take it a step further, and add a wallet option/flag that tells it to stick to imported addresses only.  The question is, when I need to create change, how do I do it?  Send to the next address that hasn't had change sent to it recently?  Have the user specify a universal send-change-to address?  Require them to specify it every time?  Obviously, this will be under the advanced interface

P.S. -- I'm still claiming that my program has never been responsible for losing anyone's money.  I'm sticking to that claim even after your report

So I just destroyed 10 BTC (by my own stupidity). This is what I did:

on a offline machine, I generated 10 private keys using a brainwallet scheme, importet them into a fresh armory wallet and put the addresses and a watch-only version of the wallet onto a usb stick.

I then sent 20 BTC to one of the addresses using an online machine.

Then I constructed a transaction using the watch-only wallet that would send 10 BTC to an external address, signed it using the offline machine and deleted the wallet on the offline machine (I wanted to test losing the machine)! I wrongly figured I'd be safe, because I could always regenerate the private keys using my brainwallet scheme. Stupid, stupid, stupid.

I totally didn't think of the fact that armory would send the 10 BTC change to a newly generated address. In fact, I didn't think of the 10 BTC change at all at that point... so I fucked up and the 10 is gone. Well, lesson learned.

I'd really like to use a brainwallet scheme that doesn't require me to safekeep anything physical (assuming I'm magically transported to some other location, totally naked, and I want my coins)

Is it possible to have armory send the change to one of the existing imported addresses instead of to a newly generated one? Maybe a special wallet type could be made up (imported addresses only)?

fuck, only gcc 4.5.2 here ;(

I used ubuntu 11.04? Is that not "fresh" enough?

EDIT: added original problem description to top

EDIT2:

I copied a _CppBlockUtils.so from a 0.75-version I had compiled earlier on gentoo (gcc 4.4.4, libstdc++ 3.4.13) and that works.

Maybe you should link to older libstdc++? version 3.4.15 seems pretty new.