Armory - Discussion Thread

[Inaba]

Hey.. windows 64 version .86-beta, sorting columns appears to be broken (probably related to the pagination code I would imagine).

Clicking columns won't sort any of them anymore, which makes finding a transaction difficult.  A global search function would be really nice, too... I have a bunch of wallets and thousands of transactions, so finding a particular transaction in a particular wallet is sometimes problematical.

[1714199925]

1714199925

[1714199925]

1714199925

[1714199925]

1714199925

[Cryptoman]

I don't think you need ".so.1.0", I think ".so" is sufficient (since it's just a symlink to .so.1.0, probably)

Right.  Edited the original.

Code:

> ls -l /usr/lib64/libpython2.7.so
lrwxrwxrwx 1 root root 19 Dec  8 14:06 /usr/lib64/libpython2.7.so -> libpython2.7.so.1.0

[etotheipi]

Hey.. windows 64 version .86-beta, sorting columns appears to be broken (probably related to the pagination code I would imagine).

Clicking columns won't sort any of them anymore, which makes finding a transaction difficult.  A global search function would be really nice, too... I have a bunch of wallets and thousands of transactions, so finding a particular transaction in a particular wallet is sometimes problematical.

Awww crap.  I forgot I had to mess with that in order to not have a ridiculously slow ledger when you have thousands of transactions (as you do).  I never quite figured out how to resolve it, and then promptly forgot about it!  The issue is that the comments are dynamically retrieved, because transactions that don't have comments will still display the address comments if there is one.  The sample wallet I had consisted of a lot of tx with hundreds of outputs each, and the search was taking like 2 seconds per operation (w/ GUI freeze).

So, what's the solution?  I'm not exactly sure...

One thing I can do, is sort by tx-specific comments first (which is very fast), then only display address comments on the page shown.  This may look weird -- some fields will appear to be out of order.  But you're probably looking for tx-specific comments, anyway, which will be sorted.  I guess I could also look into supplementing the data somehow to improve the efficiency.  It's a kind of frustrating problem because the slow version works for 99% of users, but is a terrible experience needing to be addressed for the other 1%...

[Inaba]

Hmm, yeah I've run into similar problems on various projects, so I share your pain.  Just throwing a few ideas out there (I have not looked at the Armory code, though, so these may be off base):

• Store the visual transaction records in an array for each page when the page is up, and sort by columns from the visual record, instead of taking the record directly from the Armory DB.  So you would pull the records for that page into memory and just manipulate it as if it were all text.
• Do away with column sorting and allow for a global search based on lots of different criteria (I would like this regardless). Searching across wallets would be a good idea - so you could index all the visual data, again, in a DB and then allow searches across all of it.  This would be very handy.
• Allow filtering on columns, which would somewhat negate the need for sorting (but not completely)

On a related note, how do I make transaction specific comments?  That would be really handy, I didn't know that was a feature.  Anytime I edit a comment, it seems to be tied to the address not the transaction.

[etotheipi]

• Store the visual transaction records in an array for each page when the page is up, and sort by columns from the visual record, instead of taking the record directly from the Armory DB.  So you would pull the records for that page into memory and just manipulate it as if it were all text.

By the way, if you change address comments, I want the ledger to update all the address-relevant transactions appropriately.  That's why I prefer it be dynamic.

On a related note, how do I make transaction specific comments?  That would be really handy, I didn't know that was a feature.  Anytime I edit a comment, it seems to be tied to the address not the transaction.

If you double-click on the comment field in the ledger, it will set the comment just for that tx.  Same with the address list in the wallet properties.  If you double click any other field, it will show you the transaction details (or address properties).  Maybe I should add a button to the tx details dialog to let you change the comment right there, for those that didn't notice the comment updating directly.

I have had a few requests for a search function.  It makes a lot of sense, so I will consider that for the next round of updates (it shouldn't be hard).

[Inaba]

• Store the visual transaction records in an array for each page when the page is up, and sort by columns from the visual record, instead of taking the record directly from the Armory DB.  So you would pull the records for that page into memory and just manipulate it as if it were all text.

By the way, if you change address comments, I want the ledger to update all the address-relevant transactions appropriately.  That's why I prefer it be dynamic.

On a related note, how do I make transaction specific comments?  That would be really handy, I didn't know that was a feature.  Anytime I edit a comment, it seems to be tied to the address not the transaction.

If you double-click on the comment field in the ledger, it will set the comment just for that tx.  Same with the address list in the wallet properties.  If you double click any other field, it will show you the transaction details (or address properties).  Maybe I should add a button to the tx details dialog to let you change the comment right there, for those that didn't notice the comment updating directly.

I have had a few requests for a search function.  It makes a lot of sense, so I will consider that for the next round of updates (it shouldn't be hard).

I've had instances where I want to edit all comments associated with an address and instances where I just want to modify one transactions comments.  Maybe make a button that "Apply to all" or "Apply here" or something... then if they click Apply to All, update the DB ledger for all entries... I'm not sure I see the advantage of having a dynamic ledger when you are viewing it in a page by page scenario... can't you still update the ledger entrie(s) if it's not on the current page?

[etotheipi]

• Store the visual transaction records in an array for each page when the page is up, and sort by columns from the visual record, instead of taking the record directly from the Armory DB.  So you would pull the records for that page into memory and just manipulate it as if it were all text.

By the way, if you change address comments, I want the ledger to update all the address-relevant transactions appropriately.  That's why I prefer it be dynamic.

On a related note, how do I make transaction specific comments?  That would be really handy, I didn't know that was a feature.  Anytime I edit a comment, it seems to be tied to the address not the transaction.

If you double-click on the comment field in the ledger, it will set the comment just for that tx.  Same with the address list in the wallet properties.  If you double click any other field, it will show you the transaction details (or address properties).  Maybe I should add a button to the tx details dialog to let you change the comment right there, for those that didn't notice the comment updating directly.

I have had a few requests for a search function.  It makes a lot of sense, so I will consider that for the next round of updates (it shouldn't be hard).

I've had instances where I want to edit all comments associated with an address and instances where I just want to modify one transactions comments.  Maybe make a button that "Apply to all" or "Apply here" or something... then if they click Apply to All, update the DB ledger for all entries... I'm not sure I see the advantage of having a dynamic ledger when you are viewing it in a page by page scenario... can't you still update the ledger entrie(s) if it's not on the current page?

You get a very similar behavior by just setting address comments, and then they will be displayed with all transactions on the ledger.  If you manually specify a comment for one of those transactions, that will be displayed instead of the address comments.  If I understand you correctly, that's 90% of what you were looking for (besides sorting).  

However, there is currently no way to force all tx for a given address to a given string, such that it would overwrite any explicit tx comments.  Right now, if you set a tx comment manually, it will always show that comment until you explicitly change it (but if you make it an empty string, it will be shown with the address comment)

If I spent some time with it, I'm sure I could come up with a better way to make this work the way you would expect it to.  I just put it on my TODO list

[Inaba]

No problem, I understand.  Is there something you can do about the sorting though?  I have a transaction I need to find, but I have no way to find it without sorting the columns unless I go through each transaction in each wallet individually.  Maybe have the ability to turn off pagination and use the old method until such time as there is a viable solution?  I guess I could just revert to an earlier version if need be.

[etotheipi]

No problem, I understand.  Is there something you can do about the sorting though?  I have a transaction I need to find, but I have no way to find it without sorting the columns unless I go through each transaction in each wallet individually.  Maybe have the ability to turn off pagination and use the old method until such time as there is a viable solution?  I guess I could just revert to an earlier version if need be.

For now, I would just use an earlier version (for when you need to do this).  Since this qualifies as an "incomplete" feature (since I started the upgrade, but didn't finish it), I'll make it a priority to fix it in the near future.

[marcus_of_augustus]

So I'm finally quite happy with my offline wallet setup, and I wanted to share it with others.

I have been using a Rapsberry Pi to run the offline instance of Armory. It was hooked up to my monitor through HDMI, and I had an extra keyboard around. When I wanted to perform an offline transaction, I would create it on my main computer, put it on a USB drive, plug the keyboard and USB drive into the Pi, run Armory, sign the transaction, transfer it back to the main computer, and broadcast it.

Last week, I purchased a USB to TTL, and that whole process changed for the better. The cable provides power to the Pi and allows for a terminal login to the device, so I no longer need an HDMI cable, power cable, or keyboard. I merely keep it unplugged, and plug it in when I want to perform a transaction. I log in using screen (screen /dev/ttyUSB0 115200), then run this script which does the following...

Opens a new file called armory.unsigned.tx in Nano, allowing me to paste in the ascii-serialized transaction
Runs this script against the unsigned file
If the file was signed, then display it using Less (at which point I copy it and paste into the broadcast transaction form)
Shutdown the Pi

I'm pretty sure that the TTY device only allows for a single login at a time, so I don't think it would be possible, and certainly not feasible, for an attacker to steal bitcoins from the Pi during the short time that it's connected to my computer. Any thoughts?

Interesting approach. Seems pretty tight ... safer to  use $cat rather than $less to display your signed file in case of line wrapping or extra whitespaces that might get copy/pasted and could cause errors.

Any time you have a data cable between machines your "air-gap" security guarantee is obviously void  ... but how paranoid do you want to get? (risk versus reward rules as always) ... and a rooted USB stick is as much a concern anyway maybe.

[marcus_of_augustus]

Congratulations to etotheipi for reaching beta stage on this fantastic Bitcoin client.  What follows are build instructions for OpenSUSE 12.2 (64-bit).  I did a clean install of SUSE with default packages to find out which were needed for a plain-vanilla install.  If you've been using your system for development, chances are you won't need all of the packages.

1. Install the following packages using your preferred package manager (zypper, YaST, rpm, etc.):

Code:

git-core
swig
make
gcc-c++
python-devel
python-twisted

2. Open a terminal window and get the source:

Code:

git clone git://github.com/etotheipi/BitcoinArmory.git

3. Edit BitcoinArmory/cppForSwig/Makefile and change:

Code:

STATICPYTHON += "$(DEPSDIR)/lib/libpython$(PYVER).a"

to:

Code:

STATICPYTHON +=   "$(DEPSDIR)/lib64/libpython$(PYVER).so.1.0"

4. Build and run as described in the Ubuntu instructions, viz:

Code:

cd BitcoinArmory/cppForSwig
make swig
cd ..
python ArmoryQt.py

Fantastic!  Now I have SuSE, Gentoo, Ubuntu, Fedora (somewhere).  Maybe I'll start a list of such instructions on the website.  

Two things:
(1) I don't think you need ".so.1.0", I think ".so" is sufficient (since it's just a symlink to .so.1.0, probably).  
(2) Everyone can avoid the Makefile modifications if I could just figure out how to autodetect the .a file, and switch the .so file if the .a does not exist.  Unfortunately, my bash scripting is garbage (my failed attempt is commented out in the Makefile).  Perhaps someone with more bash experience could just fix it for me and then I'll update the repo with it.

This is the biggest "hurdle" for people compiling on non-Ubuntu systems, and I could make it go away if I just got the bash commands figured out.  Then your compile instructions would pretty much be the same as I already have on the webpage.

Anyone want to help with that?

I can take a look ...

[etotheipi]

So I'm finally quite happy with my offline wallet setup, and I wanted to share it with others.

I have been using a Rapsberry Pi to run the offline instance of Armory. It was hooked up to my monitor through HDMI, and I had an extra keyboard around. When I wanted to perform an offline transaction, I would create it on my main computer, put it on a USB drive, plug the keyboard and USB drive into the Pi, run Armory, sign the transaction, transfer it back to the main computer, and broadcast it.

Last week, I purchased a USB to TTL, and that whole process changed for the better. The cable provides power to the Pi and allows for a terminal login to the device, so I no longer need an HDMI cable, power cable, or keyboard. I merely keep it unplugged, and plug it in when I want to perform a transaction. I log in using screen (screen /dev/ttyUSB0 115200), then run this script which does the following...

Opens a new file called armory.unsigned.tx in Nano, allowing me to paste in the ascii-serialized transaction
Runs this script against the unsigned file
If the file was signed, then display it using Less (at which point I copy it and paste into the broadcast transaction form)
Shutdown the Pi

I'm pretty sure that the TTY device only allows for a single login at a time, so I don't think it would be possible, and certainly not feasible, for an attacker to steal bitcoins from the Pi during the short time that it's connected to my computer. Any thoughts?

Of course, I can't endorse it as a general solution, but it seems like an okay compromise for users that are knowledgeable and crave convenience.  It sounds like the risks are:

(1) Remembering to disconnect the cable when you're done
(2) Making sure that your offline system username & password is not the same as online computer or any of the saved logins in your browser.
(3) Keyloggers

Keyloggers should be bolded there, because that seems like a big risk.  Once a keylogger gets your username and password, it would only take a couple seconds to login and fetch the wallet file.  I guess, if you kept the wallet file in some non-standard location, such automated attacks wouldn't be so clean.  Although, if your wallet encryption password is further different than online, offline, and all your browser-saved passwords, then this is considerably safer than an encrypted online wallet.  If the encryption password is unique, then the encryption would really shine, as there's no real way to get that password from the host system (I assume you still have to explicitly type your password on the offline computer, not through the terminal... and assuming they didn't get a keylogger onto the offline machine, synchronized with the data transfer).  Their only choice would be to brute force it, and that would take a very long time with the default key-stretching parameters.

But depending on how much BTC you hold and/or how paranoid you are, this could be a reasonable solution.  

[marcus_of_augustus]

So I'm finally quite happy with my offline wallet setup, and I wanted to share it with others.

I have been using a Rapsberry Pi to run the offline instance of Armory. It was hooked up to my monitor through HDMI, and I had an extra keyboard around. When I wanted to perform an offline transaction, I would create it on my main computer, put it on a USB drive, plug the keyboard and USB drive into the Pi, run Armory, sign the transaction, transfer it back to the main computer, and broadcast it.

Last week, I purchased a USB to TTL, and that whole process changed for the better. The cable provides power to the Pi and allows for a terminal login to the device, so I no longer need an HDMI cable, power cable, or keyboard. I merely keep it unplugged, and plug it in when I want to perform a transaction. I log in using screen (screen /dev/ttyUSB0 115200), then run this script which does the following...

Opens a new file called armory.unsigned.tx in Nano, allowing me to paste in the ascii-serialized transaction
Runs this script against the unsigned file
If the file was signed, then display it using Less (at which point I copy it and paste into the broadcast transaction form)
Shutdown the Pi

I'm pretty sure that the TTY device only allows for a single login at a time, so I don't think it would be possible, and certainly not feasible, for an attacker to steal bitcoins from the Pi during the short time that it's connected to my computer. Any thoughts?

Of course, I can't endorse it as a general solution, but it seems like an okay compromise for users that are knowledgeable and crave convenience.  It sounds like the risks are:

(1) Remembering to disconnect the cable when you're done
(2) Making sure that your offline system username & password is not the same as online computer or any of the saved logins in your browser.
(3) Keyloggers

Keyloggers should be bolded there, because that seems like a big risk.  Once a keylogger gets your username and password, it would only take a couple seconds to login and fetch the wallet file.  I guess, if you kept the wallet file in some non-standard location, such automated attacks wouldn't be so clean.  Although, if your wallet encryption password is further different than online, offline, and all your browser-saved passwords, then this is considerably safer than an encrypted online wallet.  If the encryption password is unique, then the encryption would really shine, as there's no real way to get that password from the host system (I assume you still have to explicitly type your password on the offline computer, not through the terminal... and assuming they didn't get a keylogger onto the offline machine, synchronized with the data transfer).

But depending on how much BTC you hold and/or how paranoid you are, this could be a reasonable solution.  

I suppose you could set up ssh keys on the rasbpi and access it like that ... no user/password typing for keylogger (once intialisation is complete). Seem to remember some tricky stuff you can do to wrap the screen tty session inside (around?) a ssh shell .

http://serverfault.com/questions/21806/how-can-i-launch-a-screen-session-with-a-command-over-ssh-on-a-remote-server-fro

[Red Emerald]

So I'm finally quite happy with my offline wallet setup, and I wanted to share it with others.

I have been using a Rapsberry Pi to run the offline instance of Armory. It was hooked up to my monitor through HDMI, and I had an extra keyboard around. When I wanted to perform an offline transaction, I would create it on my main computer, put it on a USB drive, plug the keyboard and USB drive into the Pi, run Armory, sign the transaction, transfer it back to the main computer, and broadcast it.

Last week, I purchased a USB to TTL, and that whole process changed for the better. The cable provides power to the Pi and allows for a terminal login to the device, so I no longer need an HDMI cable, power cable, or keyboard. I merely keep it unplugged, and plug it in when I want to perform a transaction. I log in using screen (screen /dev/ttyUSB0 115200), then run this script which does the following...

Opens a new file called armory.unsigned.tx in Nano, allowing me to paste in the ascii-serialized transaction
Runs this script against the unsigned file
If the file was signed, then display it using Less (at which point I copy it and paste into the broadcast transaction form)
Shutdown the Pi

I'm pretty sure that the TTY device only allows for a single login at a time, so I don't think it would be possible, and certainly not feasible, for an attacker to steal bitcoins from the Pi during the short time that it's connected to my computer. Any thoughts?

Of course, I can't endorse it as a general solution, but it seems like an okay compromise for users that are knowledgeable and crave convenience.  It sounds like the risks are:

(1) Remembering to disconnect the cable when you're done
(2) Making sure that your offline system username & password is not the same as online computer or any of the saved logins in your browser.
(3) Keyloggers

Keyloggers should be bolded there, because that seems like a big risk.  Once a keylogger gets your username and password, it would only take a couple seconds to login and fetch the wallet file.  I guess, if you kept the wallet file in some non-standard location, such automated attacks wouldn't be so clean.  Although, if your wallet encryption password is further different than online, offline, and all your browser-saved passwords, then this is considerably safer than an encrypted online wallet.  If the encryption password is unique, then the encryption would really shine, as there's no real way to get that password from the host system (I assume you still have to explicitly type your password on the offline computer, not through the terminal... and assuming they didn't get a keylogger onto the offline machine, synchronized with the data transfer).

But depending on how much BTC you hold and/or how paranoid you are, this could be a reasonable solution.  

I suppose you could set up ssh keys on the rasbpi and access it like that ... no user/password typing for keylogger (once intialisation is complete). Seem to remember some tricky stuff you can do to wrap the screen tty session inside (around?) a ssh shell .

http://serverfault.com/questions/21806/how-can-i-launch-a-screen-session-with-a-command-over-ssh-on-a-remote-server-fro

While keys are more secure than passphrases, they won't protect you in the case we are talking about.

If your system is compromised enough to have a keylogger, it is more than likely compomised enough for the attacker to use your ssh keys. They would just record you password for unlocking the ssh key (assuming you set a password) and use that key instead of the password.

I don't think having your offline system connected like this to a computer that is connected to the Internet can be considered safe.  There are some other hardware wallet implementations being worked on where restricted communication happens over USB. Allowing a full remote login into the rpi is too risky IMO

[marcus_of_augustus]

NB : I just built/ran Amory on linux mint 13, it needed also the package pyqt4-dev-tools in addition to those listed in the Install instructions of the readme ... otherwise seems to build and run with only a few warnings.

[Cryptoman]

Is there an easy way to move a single private key from one wallet to another?  I know I can do a backup from one wallet and then an import to another wallet, but there are a number of steps and warnings to get past, and then you have to make sure you delete the key from the source wallet.  Seems like a natural fit for a wallet menu item, or maybe right click on an address and have the choice to move it to another wallet.

[etotheipi]

Is there an easy way to move a single private key from one wallet to another?  I know I can do a backup from one wallet and then an import to another wallet, but there are a number of steps and warnings to get past, and then you have to make sure you delete the key from the source wallet.  Seems like a natural fit for a wallet menu item, or maybe right click on an address and have the choice to move it to another wallet.

This would only work for imported addresses.  There is no way to "remove" a deterministic address from a wallet:  it's intrinsically part of the wallet.

If you deal with a lot of imported addresses, this does make sense.  And Armory is prepared... you may have noticed if you remove an address an re-add it, Armory will say it doesn't need to rescan, because the tx history for that addr is available already.   I guess it would just be a matter of writing a single function that does both importing and deleting...

[etotheipi]

Code:

STATICPYTHON += "$(DEPSDIR)/lib/libpython$(PYVER).a"

...

Anyone want to help with that?

I can take a look ...

Looks like I already had such a function, in a previous (dumber) version of the Armory makefile.  I think it would looks like this:

Code:

   ifneq (exists, $(shell [ -d "$(DEPSDIR)/lib/libpython$(PYVER).a" ]  && echo exists ))
      STATICPYTHON +=   "$(DEPSDIR)/lib/libpython$(PYVER).so"
   else
      STATICPYTHON +=   "$(DEPSDIR)/lib/libpython$(PYVER).a"
   endif

Can someone who has the .so problem, do a fresh checkout and confirm they have the problem, then replace the (non-Darwin) STATICPYTHON line with the code above, and tell me if it works?  So far, it seems that it should... I just don't have such a system where it fails to test it.  If it does work, or you figure out how it needs to be modified, then I will commit to the master branch and every compiling user's life will become a tad easier...

[Ploo]

Installed 0.86-beta_windows_all on fresh win xp pro sp3 installation. Tried to run but get

C:\Program Files\Armory\Armory Bitcoin Client\Armory.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

Reinstalled, repaired, rebooted multiple times to no avail. Am I missing some dependencies?

[etotheipi]

Installed 0.86-beta_windows_all on fresh win xp pro sp3 installation. Tried to run but get

C:\Program Files\Armory\Armory Bitcoin Client\Armory.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

Reinstalled, repaired, rebooted multiple times to no avail. Am I missing some dependencies?

Hmmm... I haven't seen that before.  I might expect that if you had downloaded the 64-bit version and tried to run it on 32-bit Windows.  Are you maybe running 64-bit WinXP?  I wouldn't expect it to matter for "windows_all", but if so, the 64-bit version would be your friend...

All "dependencies" of Armory are already included in the installer.  So that shouldn't be the problem.

I just downloaded the "windows_all" installer from the website on my WinXP virtual machine, and it installs and runs no problem.  But mine isn't a fresh install of XP, not even close.   Try manually removing the "C:\Program Files\Armory Bitcoin Client" directory.  Make sure there is absolutely nothing left of it, then redownload from the website and do a fresh install.  Then run it by doubleclicking on Armory.exe in that Program Files directory, directly.  Just want to be extra sure you're installing and clicking the right stuff (and maybe somehow your .msi was corrupted?).

If that doesn't work, I'm not sure what else I could do...

EDIT:  A search of the error suggests that somehow the VC++ runtime files are not present.  That would be msvcp90.dll (or related).  It should be copied into the application directory by the installer, but if it's not, that's the source of it the problem.