Armory - Discussion Thread

[etotheipi]

If anyone wants to donate time to me, you can help me figure out how to script Resource Hacker to add the Armory icon to the Armory.exe file in Windows.

The icon is in the img/armory48x48.ico.  It needs to be attached to the ArmoryStandalone/Armory.exe file (which is created by the bulld process).  I guess you you don't need the specifics, I just need to be able to add a *.ico file to a *.exe file from the command line, and then I can add to my MSVS post-build scripts to do it automatically on each build.  

I have tried this a couple times, but it never worked.  It returned no errors, it just failed to change the Armory.exe icon.  Here's a reference for the ResHack command line:

http://www.autoitscript.com/forum/topic/47720-reshack-command-line-option/

Right now, I have to manually open resource hacker, "Add Resource", then navigate to that icon, then name the resource and save it.  This is just an extra step in a multi-step process to create Windows .msi installers, and anything that makes that easier means more readily creating releases in Windows.  Right now, in Linux, I only execute "python dpkgfiles/make_deb_package.py" and I get a Debian installer that is ready for distribution (minus the signature, which is done offline).    

[1713507370]

1713507370

[1713507370]

1713507370

[1713507370]

1713507370

[1713507370]

1713507370

[K1773R]

If anyone wants to donate time to me, you can help me figure out how to script Resource Hacker to add the Armory icon to the Armory.exe file in Windows.

The icon is in the img/armory48x48.ico.  It needs to be attached to the ArmoryStandalone/Armory.exe file (which is created by the bulld process).  I guess you you don't need the specifics, I just need to be able to add a *.ico file to a *.exe file from the command line, and then I can add to my MSVS post-build scripts to do it automatically on each build.  

I have tried this a couple times, but it never worked.  It returned no errors, it just failed to change the Armory.exe icon.  Here's a reference for the ResHack command line:

http://www.autoitscript.com/forum/topic/47720-reshack-command-line-option/

Right now, I have to manually open resource hacker, "Add Resource", then navigate to that icon, then name the resource and save it.  This is just an extra step in a multi-step process to create Windows .msi installers, and anything that makes that easier means more readily creating releases in Windows.  Right now, in Linux, I only execute "python dpkgfiles/make_deb_package.py" and I get a Debian installer that is ready for distribution (minus the signature, which is done offline).    

http://stackoverflow.com/questions/708238/how-do-i-add-an-icon-to-a-mingw-gcc-compiled-executable

[2112]

I guess you you don't need the specifics, I just need to be able to add a *.ico file to a *.exe file from the command line, and then I can add to my MSVS post-build scripts to do it automatically on each build.  

In Visual Studio all you need to do is right-click on the executable project and do "Add->Resource->Icon". Visual Studio will generate the resource script (*.rc) for you and automatically invoke the resource compiler (rc) and add the compiled resource file (*.res) to the linker's input.

[Stephen Gornick]

There is this question from a forum user who is still stuck in newbie jail, so I am reposting it here as I don't know the answer:

on an online computer with a "Watch Only Waller".
I notice that the option under Wallet Properties:  "Backup Individual Keys" is available on the online computer as well as the Offline computer. 

If you click on this and put in the password won't this spit out the private keys that are supposed to be only on the Offline Computer?

[Red Emerald]

There is this question from a forum user who is still stuck in newbie jail, so I am reposting it here as I don't know the answer:

on an online computer with a "Watch Only Waller".
I notice that the option under Wallet Properties:  "Backup Individual Keys" is available on the online computer as well as the Offline computer. 

If you click on this and put in the password won't this spit out the private keys that are supposed to be only on the Offline Computer?

The private keys are cleared out of the watching only wallet.  Knowing a password won't do anything.

If you click export and check "Private Key (Plain Hex)" you can see empty strings. It doesn't even prompt for the password.

If you check "Private Key (Plain Base58) you can clearly see that the exported private keys are invalid as they all are FXjQL6.  I'm pretty sure that this has been brought up in this thread before.  There should be some sort of warning or error or at the very least an empty string when the private key is empty rather than garbage output to ease this confusion.

[etotheipi]

http://stackoverflow.com/questions/708238/how-do-i-add-an-icon-to-a-mingw-gcc-compiled-executable

In Visual Studio all you need to do is right-click on the executable project and do "Add->Resource->Icon". Visual Studio will generate the resource script (*.rc) for you and automatically invoke the resource compiler (rc) and add the compiled resource file (*.res) to the linker's input.

The problem with these solutions is that the final executable is not created by the compiler/MSVS.  It is created by py2exe.  MSVS is only compiling a DLL that gets bundled into the final distributable with the python code (containing the C++ blockchain utilities).

However, as I was writing this response, I realized that I bet py2exe has a solution for this.  Sure enough, this page shows that it's pretty simple.  So yeah, I wish I'd realized that before...

Haven't tried it yet, but this looks pretty damned easy...

[2112]

The problem with these solutions is that the final executable is not created by the compiler/MSVS.  It is created by py2exe.  MSVS is only compiling a DLL that gets bundled into the final distributable with the python code (containing the C++ blockchain utilities).

However, as I was writing this response, I realized that I bet py2exe has a solution for this.  Sure enough, this page shows that it's pretty simple.  So yeah, I wish I'd realized that before...

Haven't tried it yet, but this looks pretty damned easy...

Well, the next problem you'll going to run into will be related to the manifest files. I took a quick look at the py2exe web page and it seems like it was developed with Visual Studio .NET 2003 in mind (MSVC 7.1). This is the last release that didn't require manifest files for full functionality and full security.

I don't know how to fully solve this problem without modifying py2exe.

Edit: I looked at the news "py2exe 0.6.9 released (2008/11/15)" and they talk about supporting Vista UAC, which means that they may have some rudimentary, unfinished support for manifests.

[Grecoin]

Etotheipi, which Armory release should i use for a Windows XP SP3 32-bit client?

[etotheipi]

Etotheipi, which Armory release should i use for a Windows XP SP3 32-bit client?

Use the "windows_all" version.  That version is actually built on WinXP 32-bit, though it works fine on Win7-64bit too.

[Grecoin]

Etotheipi, which Armory release should i use for a Windows XP SP3 32-bit client?

Use the "windows_all" version.  That version is actually built on WinXP 32-bit, though it works fine on Win7-64bit too.

cool thanks

[etotheipi]

Please help test version 0.86.2-beta!  Lots of bug fixes and small improvements that should make the Armory experience smoother.  Please help test and give me feedback.

Luckily, most of the changes in this version are isolated, so there's not a lot of bugs expected.  But you never know until people start using it!  But the point was, it should be fairly stable already.



Windows 64 installer:   armory_0.86.2-beta_win64.msi
Windows 32 installer:   armory_0.86.2-beta_windows_all.msi
Ubuntu/Debian 64-bit installer:  armory_0.86.2-beta_amd64.deb
Ubuntu/Debian 32-bit installer:  armory_0.86.2-beta_i386.deb

For those compiling from source, the latest is on the "dev" branch i nthe git repo.  I just realized I should start a "testing" branch, and use that as a holding-cell for soon-to-be-master upgrades, and then I don't have to keep telling you guys what branch to use.  Not sure why I didn't do this sooner...


All features new to 0.86.2:

   - Added Root Key to "Backup Individual Keys"
        So you can backup your imported keys and deterministic "seed"
        from one operation, instead of two.  Key pool addresses are now
        accessible, too.

   - Right-click Ledger Options
        Added right-click menu to ledger for quick access to transaction
        and wallet information.  Also includes options for opening your
        web-browser right to tx or address information in blockchain.info.

   - Offline-Sign Confirmation & Warnings
        Offline signing now displays appropriate warnings about what users
        should verify for before signing and broadcasting.

   - Added Comments to Coin Control (Expert Mode)
        Abbreviated comments are now show in the coin control selection
        window, with full comments available via mouse-over text.

   - Bugfix: Disappearing Addresses
        Some startup operations were inadvertantly "rewinding" wallets with
        unused addresses, causing those addresses to disappear from the
        address list, and then shown again when the user requested another
        address.  Resolved.

   - Bugfix: Ledger Sorting
        All fields in the primary ledger are sortable.  Some fields become
        unsortable as a side-effect of ledger optimizations in v0.85.

[Ploo]

Has anyone given thought to a web-based armory client?

For security reasons it would only handle watch-only wallets and you'd still have to sign transactions on a desktop client. Or it could be a full implementation, at the cost of security but there'd be no need for syncing.

An ideal scenario would be a service where I import a watch only copy of my wallet, from there I can view my wallet as I would an online desktop wallet and generate offline transactions.

The bottom line is that this would be the ultimate e-wallet solution, coupled with an android/iOS offline-only armory app for signing transactions. It would offer both security (no need to trust host with your keys) and comfort (no need to sync the blockchain)

[Ente]

Has anyone given thought to a web-based armory client?

For security reasons it would only handle watch-only wallets and you'd still have to sign transactions on a desktop client. Or it could be a full implementation, at the cost of security but there'd be no need for syncing.

An ideal scenario would be a service where I import a watch only copy of my wallet, from there I can view my wallet as I would an online desktop wallet and generate offline transactions.

The bottom line is that this would be the ultimate e-wallet solution, coupled with an android/iOS offline-only armory app for signing transactions. It would offer both security (no need to trust host with your keys) and comfort (no need to sync the blockchain)

Do you mean a webserver running on the machine with the regular armory client, which provides a html frontend to the internet?
I like this, I like this a lot!
Security? Do it with certificates, maybe even require a textmessage to do a transaction?

I didn't really think of this yet.. But now, hell, this is the one-in-all solution for everyday bitcoin handling! Everything in one [armory] spot, reachable from every device, secure, local, and with all the armory goodies like offline tx, paperbackups etc! This solves all pains I have, from trusting external servers, to centralized gox, to trusting your ability to not lose your mobile, to have enough funds on all of those devices and keeping track of all that mess!

Hell yeah! :-)

Ente

[etotheipi]

Has anyone given thought to a web-based armory client?

For security reasons it would only handle watch-only wallets and you'd still have to sign transactions on a desktop client. Or it could be a full implementation, at the cost of security but there'd be no need for syncing.

An ideal scenario would be a service where I import a watch only copy of my wallet, from there I can view my wallet as I would an online desktop wallet and generate offline transactions.

The bottom line is that this would be the ultimate e-wallet solution, coupled with an android/iOS offline-only armory app for signing transactions. It would offer both security (no need to trust host with your keys) and comfort (no need to sync the blockchain)

Good idea.  It's a very good idea ...

...and I secretly came up with this idea a couple weeks ago  Inspired by a user coming to me for help because he couldn't download the blockchain from his crappy internet connection.  He wanted to send me his watching-only wallet and I would generate the tx for him.  I've been pondering this idea for the last couple weeks, and it's something I'm keeping my eyes open for.  I was keeping it secret, and maybe it would just show up in some random Armory release one day

I seriously don't have any plans for this in the next one month.  But 2+ months, it's a distinct possibility...

[justusranvier]

For those compiling from source, the latest is on the "dev" branch i nthe git repo.  I just realized I should start a "testing" branch, and use that as a holding-cell for soon-to-be-master upgrades, and then I don't have to keep telling you guys what branch to use.  Not sure why I didn't do this sooner...

Is the lack of a git tag for the 0.87 release intentional or an oversight?

[etotheipi]

For those compiling from source, the latest is on the "dev" branch i nthe git repo.  I just realized I should start a "testing" branch, and use that as a holding-cell for soon-to-be-master upgrades, and then I don't have to keep telling you guys what branch to use.  Not sure why I didn't do this sooner...

Is the lack of a git tag for the 0.87 release intentional or an oversight?

I'll tag it when it's a real release -- right now it's still in dev branch because it's still a testing release.  Second, I have been pretty lazy about tagging versions, but I will start doing so more religiously, now that there are a couple build systems relying on them.  So, I will be sure to tag all future full-releases.   Third, this will actually be 0.86.2 -- it's really just a bugfix/polishing release.

On the topic of testing... anyone currently using it?  Any problems with it?  It's mostly small updates, so I don't expect a lot to go wrong with it.  But I still need some feedback to know for sure.

[OpenYourEyes]

May have found a small bug (v0.86-beta):

I created a new receiving address in offline mode. Now when I close Armory and re-launch it, the receiving address is gone. If I click the "receive bitcoins" (within a wallet) button again, the exact same address gets re-created along with the comment.

[etotheipi]

May have found a small bug (v0.86-beta):

I created a new receiving address in offline mode. Now when I close Armory and re-launch it, the receiving address is gone. If I click the "receive bitcoins" (within a wallet) button again, the exact same address gets re-created along with the comment.

Actually, there's a bug fix for that in 0.86.2 -- please verify for me that the issue is resolved (without breaking anything).  Thanks!

[Ente]

On the topic of testing... anyone currently using it?  Any problems with it?  It's mostly small updates, so I don't expect a lot to go wrong with it.  But I still need some feedback to know for sure.

I would like to test dev releases.
I am a bit vary about using the dev branch of a beta software on funds, though..
What would you, generally, suggest as a good way to handle this?
Of course I have external backups of the wallet files.

Ente

[etotheipi]

On the topic of testing... anyone currently using it?  Any problems with it?  It's mostly small updates, so I don't expect a lot to go wrong with it.  But I still need some feedback to know for sure.

I would like to test dev releases.
I am a bit vary about using the dev branch of a beta software on funds, though..
What would you, generally, suggest as a good way to handle this?
Of course I have external backups of the wallet files.

Ente

I would only be concerned if I make updates to the wallet code, thus risking the possibility of making errors in computing addresses, etc.  But the wallet code hasn't been touched in months (except for some tweaks to the keypool). 

When I make the new wallet, I expect people will want to test on testnet first, or with smaller amounts of coins.  For these types of releases, though, the worst thing that will happen is that pressing some buttons will throw errors strange errors, or maybe even crash Armory.  If that happens, please send me the log file.  But I wouldn't worry about losing coins...