Armory - Discussion Thread

[etotheipi]

It is fixed, thanks!

I override the mandatory tx fee function in the armory conf file. So this is my problem, not a bug.

Oh.  I didn't think that option actually worked!  Very interesting that it does! 

I would think any sub-standard fee broadcast by Armory would be DOA at the Satoshi node and never make it to the rest of the network.  Unless your Satoshi node is a special version designed to allow low-fee tx through...

[etotheipi]

Please help test the new version:  Armory 0.76-alpha-RC1:  Layout Fixes&Memory, Table sorting, Fedora Compiling, --datadir


Armory now looks remarkably different yet actually the same, all at once!  In addition to some slight layout improvements, I've added memory to the major windows and tables so that windows open to the last position&size, and table columns will remember the widths manually set by the user.

• Dialog and Table Geometry Memory --  Dialog sizes and column widths are saved between loads.
• Smart Stretch factors -- Major layouts are more efficient and stretch more intelligently.
• Table sorting now works! --  You can now sort ledgers and address lists by any column. (not all tables have been upgraded)
• Added "--datadir" option -- Use "--datadir" to choose a different home-directory for Armory (i.e. keep wallets on a USB key).
• Fixed wallet corruption bug! -- A "wallet description" of more than 256 chars could overflow into and overwrite the encryption settings.  Fixed now.
• Fixed Fedora compiling -- I became aware that the latest version of crypto++ was [accidentally] dependent on a bug in gcc that was fixed in gcc version 4.7.  The latest version of Fedora uses gcc 4.7 and thus compiling fails.  I upgraded the included Crypto++ code with the official fix, so it should work, now.

I've provided the most popular downloads below.

Windows 64-bit
Ubuntu/Debian 64-bit, 9.04-10.10
Ubuntu/Debian 64-bit, 11.04+
Ubuntu/Debian 32-bit, 9.04-10.10


Layouts are more efficient and table sorting lets you find stuff easier!

New wallet format is on hold:  I started a complete overhaul of Armory wallets and probably spent a week getting about 30% done.  Not only is it hugely complicated (but worth it!), the new determinism algorithm has not been finalized by the Satoshi developers yet (it's not even an official BIP yet, and I don't want to release it until I know that they're supporting it).  Given that the 0.7X code is pretty darned stable, anyway, I think this will be the basis for Armory Beta!


So instead of a new wallet format, my final hurdle to beta will be completely eliminating all system requirements.  Mmap did not succeed on Windows 32-bit at all, and is still pretty heavy on Windows 64-bit.  I think it will be better to get Armory working on any hardware, and will give me a headstart on some networking stuff.


P.S. -- For anyone interested, Sipa has really locked down a great algorithm for the new wallets.  It allows you to deterministically generate new addresses and new wallets.  In fact, you can very quickly compute addresses of arbitrary dimension and index:  i.e.  you can get Address(12),  or Address(3)(9), or Address(98)(4)(182)(5)(48372221).  Of course, this can get wildly out of hand, which is why the new wallets will have a "convention" for what addresses are used and associated with each other.   Here's a diagram I made of how it will work (assuming it survives the BIP process).

This means that you can create a single wallet seed when you install Armory, and all future wallets you create can be regenerated from that seed.  Of course, you can choose to create new seeds to keep wallets truly separate.  But at least you have the option! 

[jl2012]

I'm using the standard 0.6 Shatoshi client. I'm not sure if Shatoshi client has broadcast my sub-standard fee tx (I didn't get any error message). How could I know if it has broadcast or not?

It is fixed, thanks!

I override the mandatory tx fee function in the armory conf file. So this is my problem, not a bug.

Oh.  I didn't think that option actually worked!  Very interesting that it does! 

I would think any sub-standard fee broadcast by Armory would be DOA at the Satoshi node and never make it to the rest of the network.  Unless your Satoshi node is a special version designed to allow low-fee tx through...

[etotheipi]

I'm using the standard 0.6 Shatoshi client. I'm not sure if Shatoshi client has broadcast my sub-standard fee tx (I didn't get any error message). How could I know if it has broadcast or not?

Armory sends the Satoshi client the tx, then asks for the same tx 2 seconds later.  If it receives a reply, the client accepted it and broadcast it.  If it doesn't, an error message will pop up saying there was an issue and you should contact support (me).  If you didn't get the error message, then it means the Satoshi client accepted it.

[Foxpup]

Uh, can I have links that aren't circular redirects? Or does Dropbox just hate me?

Code:

http://dl-web.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.76-python2.7-1_amd64.deb
Connecting to dl-web.dropbox.com|199.47.217.179|:80... connected.
HTTP request sent, awaiting response... 
  HTTP/1.1 302 Moved Temporarily
  Server: nginx/1.0.14
  Date: Mon, 07 May 2012 02:23:42 GMT
  Content-Type: text/html; charset=utf-8
  Location: http://dl-web.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.76-python2.7-1_amd64.deb
  Pragma: no-cache
  Cache-Control: no-cache
  x-frame-options: SAMEORIGIN
  Connection: keep-alive

[Foxpup]

Okay, now that Dropbox is no longer hating me...

For what reason, if any, does the python 2.7 version require python 2.7? I'm going crazy here. Can someone else with python 2.6 please download the python 2.7 version, install it with dpkg --force-depends, and confirm that it works anyway? I don't want to be only person here who's crazy. And if it does work with both 2.6 and 2.7 can we drop the libpython dependency and finally get rid of these two separate versions once and for all?

Moving on...

The Armory logo no longer fits in its panel (at least on my system), regardless of the window size, though everything else that didn't used to fit, now does fit. (Screenshot)

I've noticed that closing the Wallet Version Warning window does not cancel the Migrate Wallet operation - exactly the opposite of what should happen. Also, the text in the Migrate Wallet window doesn't fit unless the window is resized, and this particular window does not remember its size.

I'm also still annoyed that I can't change advanced encryption options for an existing wallet, and that paper wallets don't print correctly on light-on-dark colour schemes. Any word on when these will be fixed?

[teste]

Hi,

I can't install armory yet because I'm using a tablet for now, but i need to say that by looking screenshots and features list, the program really promisses.

When on notebook I'm a linux user and the way I like to install satoshi client is just open the tar.gz file and extract the files to a folder and then execute the program by running the bin file. (When a new version is released, i just delete the folder and extract the new files to it).

I would like to know if is possible do the same thing on armory. (I would like to extract armory to a folder on pen drive and use it).

Could you take some screenshots of send bitcoin window and post here?

[etotheipi]

Okay, now that Dropbox is no longer hating me...

For what reason, if any, does the python 2.7 version require python 2.7? I'm going crazy here. Can someone else with python 2.6 please download the python 2.7 version, install it with dpkg --force-depends, and confirm that it works anyway? I don't want to be only person here who's crazy. And if it does work with both 2.6 and 2.7 can we drop the libpython dependency and finally get rid of these two separate versions once and for all?

Moving on...

The Armory logo no longer fits in its panel (at least on my system), regardless of the window size, though everything else that didn't used to fit, now does fit. (Screenshot)

I've noticed that closing the Wallet Version Warning window does not cancel the Migrate Wallet operation - exactly the opposite of what should happen. Also, the text in the Migrate Wallet window doesn't fit unless the window is resized, and this particular window does not remember its size.

I'm also still annoyed that I can't change advanced encryption options for an existing wallet, and that paper wallets don't print correctly on light-on-dark colour schemes. Any word on when these will be fixed?

Thanks for the bug reports.

(1) I'll try what you suggested on my various machines, with respect to python versions.  I have to make sure that just because it works on one system that I think has only 2.6, but it will on the others.  As happened with the 2.6 version that worked on 11.04 which appears to only have 2.7, but didn't work on 12.04.  Supporting all these different variants reliably is tough!
(2) I actually forgot to resize the dark-background logo before committing everything.  It's not a problem on regular backgrounds.  I'll try to remember it for final release of 0.76
(3) Wallet migration and encryption options are getting overhauls with the new wallet format.  For instance, fixing migration stuff won't happen til I support compressed keys, and it is of limited usefulness until I do.  So I wasn't putting too much effort into it, yet.
(4) If you're really anxious to change the encryption options, it can be done from the python shell, I just never put an interface into Armory for it.  There is a "test-change-KDF" test in the unittest.py file, which shows you what python commands need to be issued.  It will involve a readWalletFile() command and then another call.  The wallet will be modified in place, so you won't need to save anything back out.  I remember test passed, but it is of course recommended to make a backup before trying this.  There might be a long-forgotten reason I didn't finish it...
(5) I looked briefly at paper wallets on dark backgrounds... there wasn't an obvious fix for it that didn't make the print-dialog display suffer from the same problem you are reporting on the printout (...then no one would use it at all).  I'll see if it's not too hard to make the text gray when on a dark background, so that it will show up on screen and on paper both.


@ Teste,

I'll add this to my list of things to do to support other Linux versions.  I don't think it'll be that difficult, except that Armory is a python script so it will require having a couple of dependencies satisfied on the user's sides

[Foxpup]

(5) I looked briefly at paper wallets on dark backgrounds... there wasn't an obvious fix for it that didn't make the print-dialog display suffer from the same problem you are reporting on the printout (...then no one would use it at all).  I'll see if it's not too hard to make the text gray when on a dark background, so that it will show up on screen and on paper both.

Isn't the correct solution to just make the paper wallets use black text on a white background, regardless of the system colours? That's what virtually every other program that handles printed documents does.

[etotheipi]

For what reason, if any, does the python 2.7 version require python 2.7? I'm going crazy here. Can someone else with python 2.6 please download the python 2.7 version, install it with dpkg --force-depends, and confirm that it works anyway? I don't want to be only person here who's crazy. And if it does work with both 2.6 and 2.7 can we drop the libpython dependency and finally get rid of these two separate versions once and for all?

I just tried this on a version compiled with 12.04 (python 2.7), on a 10.04 system (python 2.6).  I got a

Code:

ImportError: /usr/lib/libstdc++.so.6: version "GLIBCXX_3.4.15' not found (required by /usr/share/armory/_CppBlockUtils.so)

Not really related to your question, but further justification for needing separate versions.  I really don't feel like battling glibc version compatibility issues...

More directly related to your question:  in order for the 10k lines of C++ to be made available to Python, I need to use swig to create a .so file.  This requires linking using -lpython2.X, which of course needs to be the one available on the system.  Then, the resulting .so file requires having that specific version of libpython2.X.so on the system. 

On the other hand, now that I look at it:  I don't see why I can't statically compile whatever version of python I currently have.  I don't think it needs to match the current python version.  That might be worth trying, though I don't think I can avoid the glibc issue I mentioned previously...

[etotheipi]

@ Foxpup

I just uploaded to the previous location a dark-background-fixed version of 0.76.  It has the new logo sizes, and it printing looks better:

http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.76-python2.6-1_amd64.deb

Try it and tell me if that's any better.  I'm pretty sure that python2.6/amd64 is your arch.  I didn't feel like recompiling all of them just for you to test it...

[Foxpup]

I just tried this on a version compiled with 12.04 (python 2.7), on a 10.04 system (python 2.6).  I got a

Code:

ImportError: /usr/lib/libstdc++.so.6: version "GLIBCXX_3.4.15' not found (required by /usr/share/armory/_CppBlockUtils.so)

Not really related to your question, but further justification for needing separate versions.  I really don't feel like battling glibc version compatibility issues...

It actually depends on the glibc version? Now I feel like an idiot for not mentioning earlier that my copy of glibc is from a different distro, which makes sense for reasons I'm not even going to try to explain... Well, I guess that clears that up.

More directly related to your question:  in order for the 10k lines of C++ to be made available to Python, I need to use swig to create a .so file.  This requires linking using -lpython2.X, which of course needs to be the one available on the system.  Then, the resulting .so file requires having that specific version of libpython2.X.so on the system. 

On the other hand, now that I look at it:  I don't see why I can't statically compile whatever version of python I currently have.  I don't think it needs to match the current python version.  That might be worth trying, though I don't think I can avoid the glibc issue I mentioned previously...

I don't see why you couldn't have done that two weeks ago when I suggested you do exactly that (better late than never, I suppose):

Is there no way of using the statically-linked python interpreter?

I just uploaded to the previous location a dark-background-fixed version of 0.76.  It has the new logo sizes, and it printing looks better:

http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.76-python2.6-1_amd64.deb

Try it and tell me if that's any better.  I'm pretty sure that python2.6/amd64 is your arch.  I didn't feel like recompiling all of them just for you to test it...

It is much better. Thanks.

[arfeniel]

I downloaded version 0.75.1 and 0.76 and I can't migrate my Bitcoin wallet. It was never touch by the Bitcoin client version 0.6.
With both version 0.75.1 and 0.76, when I click on the migrate button nothing happen...

Do I have to close the Bitcoin client before trying to migrate the wallet?

Thanks

[etotheipi]

I downloaded version 0.75.1 and 0.76 and I can't migrate my Bitcoin wallet. It was never touch by the Bitcoin client version 0.6.
With both version 0.75.1 and 0.76, when I click on the migrate button nothing happen...

Do I have to close the Bitcoin client before trying to migrate the wallet?

Thanks

Interesting.  Admittedly, I haven't put much extra thought or effort into the migration since I realized that it's going to be of limited value until I can support 0.6.0 (compressed public keys).  So I've kind of been neglecting it...

Are you in Windows or Linux?  If you are in Linux, you can help identify the problem by running it from the command line and observing the error output. 

Code:

python /usr/share/armory/ArmoryQt.py

If not, then I guess I'll have to bump getting a "proper logging system" implemented up on the list of priorities.  I'm not sure how to figure it out without...   I recognize it's not the best option, but if you can always create new addresses and send coins to it.  It's is a universal way to migrate funds between Bitcoin clients

The new wallet format is on hold while the main devs sort out the new wallet details, and I have a couple high priority things to do before then, anyway.  It might be a month before I can get to it...

[arfeniel]

Are you in Windows or Linux?  If you are in Linux, you can help identify the problem by running it from the command line and observing the error output. 

I'm running Windows 7 home premium

I recognize it's not the best option, but if you can always create new addresses and send coins to it.  It's is a universal way to migrate funds between Bitcoin clients

I can work with that. I will create a new wallet with Armory and play around with this app.

Great job btw!

[da2ce7]

Have you conceded using the Stratum protocol?

http://stratum.bitcoin.cz/

So instantly on first load Armoury, can be functional as a Bitcoin wallet...

Then it could start loading the Bitcoin chain in the background, and eventually offering the hosing the stantum protocol to other Armoury (and electrum and any other thin client).

It would be best if the Armoury could connect to 10 or 20 different other thin Stratum servers, so one bad server won't be able to scam.

[check_status]

Can I use patched Bitcoin Clients, like coderrr's, with Armory?

[etotheipi]

Have you conceded using the Stratum protocol?

http://stratum.bitcoin.cz/

So instantly on first load Armoury, can be functional as a Bitcoin wallet...

Then it could start loading the Bitcoin chain in the background, and eventually offering the hosing the stantum protocol to other Armoury (and electrum and any other thin client).

It would be best if the Armoury could connect to 10 or 20 different other thin Stratum servers, so one bad server won't be able to scam.

I have not decided how to do it, yet, but I know what I want:

(1) Even before a networking-independent solution, I plan to have Armory insta-load, but into a reduced-functionality interface.  Then the blockchain stuff can load in the background, and unlock those interface elements when it's done.  The user will be able to do wallet management while that is happening. 
(2)  I'm not going to rely on a separate network of servers.  Accessing the Bitcoin network as it was originally intended offers me the highest level of security and reliability, and that's worth it even if it's inconvenient.  I see too many issues relying on an out-of-band network of servers that could be compromised or modified underneath me.   I'm not saying there's anything wrong with an overlay network.  But for standard blockchain operations, I want to rely on the BTC network as it was originally designed.
(3)  However, I will likely use an existing, battle-hardened codebase to implement the peer discovery, networking protocol and full chain verification.  I'm still undecided whether that will be some modification of bitcoind, libcoin or libbitcoin.  Recommendations are welcome.

Can I use patched Bitcoin Clients, like coderrr's, with Armory?

I've never tried it, but there's no reason it wouldn't work.  As long as it runs on the default bitcoind port and implements the same networking protocol, it should be fine.

[OneMINER]

I'm trying to use the -datadir option. No luck so far but I'm just shooting in the dark right now. Can anybody tell me where I'd have to enter that and give me a sample of how it would look? I'm using Ubuntu 10.04.

Thanks.

[etotheipi]

I'm trying to use the -datadir option. No luck so far but I'm just shooting in the dark right now. Can anybody tell me where I'd have to enter that and give me a sample of how it would look? I'm using Ubuntu 10.04.

Thanks.

Armory uses the standard linux command-line options, '--' for long options.  I'm not sure why bitcoin-qt/bitcoind does not follow  (it's supposed to be '-X' for one-letter options, '--LongX" for long options.  Anyways, here's your example:

Code:

python /usr/share/armory/ArmoryQt.py --datadir=/media/usbkey/armorywallets