Armory - Discussion Thread

[check_status]

After deleting mempool.bin Armory opened up normally, no segmentation fault.

[1714199014]

1714199014

[etotheipi]

After deleting mempool.bin Armory opened up normally, no segmentation fault.

Fwhew!  I feel a lot better now.  Sorry I had you run through some unnecessary hoops. 

I know exactly what to do to prevent this in the future, and it should only take like 10 min to implement.  It will definitely be going into beta.

Thanks for being patient with me!

[check_status]

Was able to complete a transaction successfully, so all is good.

[molecular]

problem running:

so I just installed https://github.com/downloads/etotheipi/BitcoinArmory/armory_0.77-python2.7-1_i386.deb onto a freshly installed ubuntu alternate 11.04. Installer said "package has bad quality", offered me to ignore and install anyway, which I did.

It refuses to start ("python2.7 ArmoryQt.py") saying roughly (sorry, can't copy-paste, this is an "offline" machine):

ERROR: C++ block utilities not available.
Make sure you have these 2 files:
  CppBockUtils.py and
  _CppBlockUtils.so

both the files are there (from where I try to start Armory)

any ideas?

EDIT: trying to run "python CppBlockUtils.py" reveals:

ImportError: /usr/lib/i386-linux-gnu/libstdc++.so.6: version 'GLIBCXX_3.4.15' not found (required by ./_CppBlockUtils.so)

Do you have gcc installed?
GLIBCXX_3.4.15 is an object in libstdc++.so.6.0.16
'libstdc++.so.6.0.16' is part of gcc-4.6.x

molec@armory:/usr/share/armory$ gcc --version
gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

molec@armory:/usr/share/armory$ readelf -Ws /usr/lib/i386-linux-gnu/libstdc++.so.6 | grep \ GLIBCXX
   913: 00000000     0 OBJECT  GLOBAL DEFAULT  ABS GLIBCXX_3.4.1
   915: 00000000     0 OBJECT  GLOBAL DEFAULT  ABS GLIBCXX_3.4.2
   921: 00000000     0 OBJECT  GLOBAL DEFAULT  ABS GLIBCXX_3.4.3
   925: 00000000     0 OBJECT  GLOBAL DEFAULT  ABS GLIBCXX_3.4.4
   927: 00000000     0 OBJECT  GLOBAL DEFAULT  ABS GLIBCXX_3.4.5
   931: 00000000     0 OBJECT  GLOBAL DEFAULT  ABS GLIBCXX_3.4.6
   937: 00000000     0 OBJECT  GLOBAL DEFAULT  ABS GLIBCXX_3.4.7
   942: 00000000     0 OBJECT  GLOBAL DEFAULT  ABS GLIBCXX_3.4.8
   943: 00000000     0 OBJECT  GLOBAL DEFAULT  ABS GLIBCXX_3.4.9
  2533: 00000000     0 OBJECT  GLOBAL DEFAULT  ABS GLIBCXX_3.4.10
  2541: 00000000     0 OBJECT  GLOBAL DEFAULT  ABS GLIBCXX_3.4.11
  2544: 00000000     0 OBJECT  GLOBAL DEFAULT  ABS GLIBCXX_3.4.12
  2555: 00000000     0 OBJECT  GLOBAL DEFAULT  ABS GLIBCXX_3.4.13
  2560: 00000000     0 OBJECT  GLOBAL DEFAULT  ABS GLIBCXX_3.4.14
  2823: 00000000     0 OBJECT  GLOBAL DEFAULT  ABS GLIBCXX_3.4

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.

[molecular]

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)?

[etotheipi]

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

[cypherdoc]

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.

[etotheipi]

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.

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.  

[molecular]

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 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 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

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!

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

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.

[molecular]

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.

this is my brainwallet scheme:

for i in 0 1 2 3 4 5 6 7 8 9; do echo "<verylongbrainwalletseed>$i" | sha256sum; done

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)

[etotheipi]

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

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)

[Red Emerald]

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

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.

[etotheipi]

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

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.

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...

[etotheipi]

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.

[jl2012]

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

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.

[etotheipi]

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.

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  

[molecular]

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.

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

[etotheipi]

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.

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

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!

[molecular]

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.

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  

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.

[etotheipi]

... However, please consider the electrum-way of doing this (random seed, mnemonic phrase to memorize).

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.