Armory - Discussion Thread

[cuz0882]

I tried this out earlier today. I had a lot of trouble getting my money back out of client. I only received invalid transaction messages when trying to send btc. 30 minutes later it appeared as send in the transaction history...

[Kluge]

I send 0.1 coins to the client to test this out, and now I can't get it back off. I just get a Invalid transaction error. The amount and address are correct. I also downloaded it on another pc and it does the same thing...

Check address in something like blockchain.info -- looks like they go through, but don't display in Armory.

ETA for e-pi: Win7 x64

[Red Emerald]

I think there is still a problem with releasing RAM.  I'm running Windows 7 Ultimate 64-bit. Armory worked great.  I quit it, and my system shows the RAM usage drop to normal.  However, I went to make a virtual machine with 4GB of RAM (My system has 6), and it kept crashing because it said the system did not have enough RAM.  Then I tried to open a video game, and it crashed.

A reboot seems to have fixed it. Of course, a reboot seems to fix a lot of things in Windows, so it may have nothing to do with Armory ;p  I'm pretty sure it is Armory's fault though.  I'll test to see if I can reproduce it soon.

[etotheipi]

I think there is still a problem with releasing RAM.  I'm running Windows 7 Ultimate 64-bit. Armory worked great.  I quit it, and my system shows the RAM usage drop to normal.  However, I went to make a virtual machine with 4GB of RAM (My system has 6), and it kept crashing because it said the system did not have enough RAM.  Then I tried to open a video game, and it crashed.

A reboot seems to have fixed it. Of course, a reboot seems to fix a lot of things in Windows, so it may have nothing to do with Armory ;p  I'm pretty sure it is Armory's fault though.  I'll test to see if I can reproduce it soon.

Gah!  The sky is falling, the moment I leave on vacation!  I'll have to attend to all this next week.  Sorry!

P.S. - Red Emerald, does task manager still show ArmoryQt.exe?   If not, it shouldn't be locking RAM anymore.

[RoloTonyBrownTown]

Hi etotheipi,

Quick UI bug.   If you select the "Receive Bitcoins" button, but then press cancel on the "This is not your wallet" warning, it just pops up a big empy grey box that covers the UI

Just in case you missed this (it's nothing major, but may as well add it to the to-do list)

[runeks]

Nice new features you've added etotheipi! I have two bugs to report.
The first happens when I run Armory from the command line and the current working directory is not the directory in which ArmoryQt.py resides. I get the following error when I click the Tools->EC Calculator menu item:

Code:

Traceback (most recent call last):
  File "/home/rune/Programming/BitcoinArmory/ArmoryQt.py", line 382, in <lambda>
    actOpenTools  = self.createAction('&EC Calculator',   lambda: DlgECDSACalc(self,self, 1).exec_())
  File "/home/rune/Programming/BitcoinArmory/qtdialogs.py", line 6536, in __init__
    imgPlus  = QImageLabel('img/plus_orange.png')
  File "/home/rune/Programming/BitcoinArmory/qtdefines.py", line 453, in QImageLabel
    raise FileExistsError, 'Image for QImageLabel does not exist!'
armoryengine.FileExistsError: Image for QImageLabel does not exist!
Attempting to close the main window!

Executing ArmoryQt.py after cd'ing to its location and it works fine.

Second bug is that both the messages blocks you've posted, that are supposed to verify that you made these messages, produce a dialog saying "The supplied signature is not valid!". There are no errors on the command line after doing this check. Both these messages fail to validate:

Code:

-----BEGIN-SIGNATURE-BLOCK-------------------------------------
Address:   1ArmoryXcfq7TnCSuZa9fQjRYwJ4bkRKfv
Message:   "I, Alan C. Reiner, have released Armory version "
           "0.55-alpha. The zip files containing the Armory "
           "binaries, have the following md5 hashes: Windows"
           " 32-bit: c0396c88f024289e086ec381a6b74156, Windo"
           "ws 64-bit: a4abfde8a0cd702983e915e9fba01c73. Ple"
           "ase do not use the downloaded zip-files if the m"
           "d5 hashes do not match!"
PublicKey: 0411d14f8498d11c33d08b0cd7b312fb2e6fc9aebd479f8e9a
           b62b5333b2c395c5f7437cab5633b5894c4a5c2132716bc36b
           7571cbe492a7222442b75df75b9a84
Signature: d60215832dbd383485ab0a8ba764f5cdcd206b8f0357f0e434
           d11caeed7303ba5f6a380f4baa3b484583552538067cc398c2
           bd2a13df473872612d8453e78a2a
-----END-SIGNATURE-BLOCK---------------------------------------

Code:

-----BEGIN-SIGNATURE-BLOCK--------------------------
Address:    1ArmoryXcfq7TnCSuZa9fQjRYwJ4bkRKfv
Message:   "On 2012-Feb-29 12:55am EST, I, e"
           "totheipi, released Armory versio"
           "n 0.55-alpha-RC1.  The Windows 6"
           "4-bit zip file has the following"
           " md5 hash:  e8914c803daa31f2bebc"
           "dab20738e7ad"
PublicKey:  04
            11d14f8498d11c33d08b0cd7b312fb2e
            6fc9aebd479f8e9ab62b5333b2c395c5
            f7437cab5633b5894c4a5c2132716bc3
            6b7571cbe492a7222442b75df75b9a84
Signature:  9474474dffba5a49338c9df3f6a24e14
            6757d038a116893f4442baf2ca14fe20
            938147a818e1d1fca45a2bc334998aae
            11bae363e525aa9301f3f915d81fd298
-----END-SIGNATURE-BLOCK----------------------------

When I create a message block myself, signed with one of my own keys, it works fine.

[tgmarks]

watching, and excited

[etotheipi]

Experimental Wallet Migration Tool
https://github.com/downloads/etotheipi/BitcoinArmory/Armory_MigrateWallet.zip
https://github.com/downloads/etotheipi/BitcoinArmory/Armory_MigrateWallet_Win32.zip (for 32-bit)


WARNING:  This tool is experimental, so please make sure everything is backed up appropriately before trying this!

Something very similar will be integrated into Armory, but probably not for another couple weeks.  If you can't wait, go ahead and use this tool.

The zip file linked above contains Joric's pywallet.py, a script I wrote called ArmoryBulkImport.py, and then all the stuff you need to run it on Windows.  You should only need to have python installed (2.7.2 is ideal) to run these scripts.  

If you are on Linux, you should unpack either zipfile, and copy the compiled _CppBlockUtils.so and CppBlockUtils.py files from your BitcoinArmory directory into this one (it is created after the "make swig" step in the instructions).  I am not on a Linux machine, so I can't test it just yet, but the Windows version has been tested (64-bit only).  If there are any problems with it, it will have to wait until next week, but I thought I might be able to get this out the door right now to help people who can't proceed with offline wallets.

Wallet Migration Tool

This is two tools:  pywallet.py from Joric, which will allow you to dump your wallet.dat file from the Satoshi client into a file, and then ArmoryBulkImport.py which will read any file containing a bunch of private keys and import them into a target Armory wallet (it literally breaks down the entire contents of the file, and grabs everything that looks like a private key).

With pywallet, you must use --dumpwallet flag and pipe everything to a file.  Use --datadir=/path/containing/wallet.dat/ if wallet.dat is in a non-std locations.  Use --password if your Satoshi wallet is encrypted.

Code:

python pywallet.py --dumpwallet --datadir=/home/user/.bitcoin/ --password=myEncryptionPassword  > satoshiKeys.txt

Once you have the keys in the file (or any file containing lots of private keys), you can run

Code:

python ArmoryBulkImport.py --importPath=satoshiKeys.txt --toWallet=/home/user/.armory/armory_284kgF44.wallet

The script has a ton of checks built-in, including only importing private keys that have a checksum:  this guarantees that arbitrary 32-byte strings are not treated as private keys.  And if your target Armory wallet is encrypted, it will prompt you for a password to unlock it (without leaving anything in your shell history).

Please let me know if something doesn't work quite right.  I'll take a shot at fixing it, but likely won't get to it until next week.

-Eto

[bitclown]

Violently awesome! Does the migration process support the satoshi client's new compressed pubkeys?

[etotheipi]

Violently awesome! Does the migration process support the satoshi client's new compressed pubkeys?

Ahhhh crap.

Thanks for reminding me that I don't support compressed public keys, yet.  My understanding is that the private keys are going to have an extra byte to identify if it's to be used as a compressed address, and I don't have either implemented yet.  I'm going to have to do a bit of work when I get home to support that (luckily, Crypto++ which is the underlying library I use, has native support for compressed public keys, but I have to adjust some of my blockchain scanning code to recognize them).

So, to answer your question:  no it does not support them.  This will only import regular addresses: it will likely, silently skip any private keys used for compressed addresses.  I need to add compressed public keys to my high-priority to-do list...

[etotheipi]

Please let me know if something doesn't work quite right.

I managed to pull the keys from my wallet on my offline computer but when I try to import them, I get the following error:

***Error  C++ block utilities not available.
              Make sure that you have the SWIG-compiled modules
              in the current directory (or added to the PATH)
              Specifically, you need:
                       CppBlockUtils.py      and
                       _CppBlockUtils.pyd
Traceback (most recent call last):
   File "C:Users\User\Desktop\Armory_MigrateWallet\ArmoryBulkImport.py", line 1
, in  <module>
      from armoryengine import *
   File "C:Users\User\Desktop\Armory_MigrateWallet\armoryengine.py", line 333,
in <module>
      TheBDM = Cpp.BlockDataManager().getBDM()
NameError: name 'Cpp' is not defined



Those files are in the same folder as ArmoryBulkImport.py on the desktop where I originally extracted it.

I notice that it looks at the directories where the Satoshi block chain info resides. Do I need the block chain for this to work?

No, you don't need the blockchain.  It autodetects the directories for a full, online Armory instance for your OS, but doesn't use them for offline mode. 

But for some reason it didn't find CppBlockUtils.py & _CppBlockUtils.pyd.  If those are in the same directory as you are running the script from, then it's failing to load the .pyd... is it a 32-bit system?  Because _CppBlockUtils.pyd is compiled for 64-bit systems.  It wouldn't surprise me if your offline computer was old and running 32-bit Win XP.  Or possibly 64-bit but running 32-bit python...?

I released what I could because I'm on my girlfriend's Win 7 64 bit laptop, but when I get home tomorrow night, I'll compile and release for 32-bit, too. 

If that's not it, I don't know what is.  You might get more information by going to that same directory and typing "C:/Python27/python.exe" then typing "import CppBlockUtils".  It should give you a more-specific error.  I thought I had fixed Armory so that it would give this extra information without doing these extra steps, but this armoryengine.py file is a slightly-older version.

-Eto

[etotheipi]

But for some reason it didn't find CppBlockUtils.py & _CppBlockUtils.pyd.  If those are in the same directory as you are running the script from, then it's failing to load the .pyd... is it a 32-bit system?  Because _CppBlockUtils.pyd is compiled for 64-bit systems.  It wouldn't surprise me if your offline computer was old and running 32-bit Win XP.  Or possibly 64-bit but running 32-bit python...?

I released what I could because I'm on my girlfriend's Win 7 64 bit laptop, but when I get home tomorrow night, I'll compile and release for 32-bit, too. 

If that's not it, I don't know what is.  You might get more information by going to that same directory and typing "C:/Python27/python.exe" then typing "import CppBlockUtils".  It should give you a more-specific error.  I thought I had fixed Armory so that it would give this extra information without doing these extra steps, but this armoryengine.py file is a slightly-older version.

Yes, my offline computer is running a 32-bit system, so I suppose that's the problem. I went ahead and did what you suggested anyway, and after a bunch of stuff it says:

ImportError: DLL load failed: %1 is not a valid Win32 application.

I knew it! (my girlfriend tells me I'm clairvoyant ) I know I'm sending you on a scavenger hunt here, but you can probably use the compiled CppBlockUtils.py and _CppBlockUtils.pyd found in version 0.51-alpha (when I still released pseudo-binaries):  https://github.com/etotheipi/BitcoinArmory/downloads

Download the zip file for 0.5.1-alpha 32-bit, and use the CppBlockUtils files from that.  I bet it will work.  If not... well you'll have to wait  

I think my first priority after getting back from vacation tomorrow will be fixing the send-tx/network bug, and then integrating this functionality into Armory so that it doesn't have to be a hacky script.  Sounds like I better get permission from Joric to include his code as an "add-on" to Armory...

[etotheipi]

I knew it! (my girlfriend tells me I'm clairvoyant ) I know I'm sending you on a scavenger hunt here, but you can probably use the compiled CppBlockUtils.py and _CppBlockUtils.pyd found in version 0.51-alpha (when I still released pseudo-binaries):  https://github.com/etotheipi/BitcoinArmory/downloads

Download the zip file for 0.5.1-alpha 32-bit, and use the CppBlockUtils files from that.  I bet it will work.  If not... well you'll have to wait  

I think my first priority after getting back from vacation tomorrow will be fixing the send-tx/network bug, and then integrating this functionality into Armory so that it doesn't have to be a hacky script.  Sounds like I better get permission from Joric to include his code as an "add-on" to Armory...

Those two files did the trick! It seemed to import successfully. One step closer to offline transactions! Thanks.

Great!  I'm kind of surprised that it worked, but I guess there's no reason for it not to (meshing different versions of compiled code together frequently has unexpected behavior).  Perhaps I'll add a migration-tool download for 32-bit...

EDIT: I just added it to the download page.  Download the Win32 wallet migration tool

One thing I noticed, and I'm sure it's been mentioned already, but it's a long thread and I figure no harm in mentioning it again. Mined transactions are showing as spendable as if they were a typical transaction.

Interesting.  I definitely made an attempt to fix that, but I was never able to set up a test case for it, because I've never mined a block directly with with an Armory address.

I bet this is P2Pool coinbases...  Right?  I haven't setup P2Pool yet, but I should.  Then I can test it with my own addresses...

 

[etotheipi]

Just added the 32-bit download to the original post (#361). 


For reference, all downloads (including older versions) can be found here:  https://github.com/etotheipi/BitcoinArmory/downloads

[etotheipi]

So, for some reason my offline client does not think it has the private keys to sign the transaction.

Sad day  

I wonder if the fact that it's an imported address has anything to do with it.  It shouldn't matter, but it shouldn't behave like this either, so something is obviously awry.   On the window where you load the unsigned transaction, isn't there a button in the bottom right corner that says something like "Click here for more information about this transaction" ...?   Does it show you anything?

I suspect there may be an error condition popping up, but if you are using the ArmoryQt.exe, there's no way to get that information.  I've been meaning to implement a logging system for exactly this purpose, but up until now, I've always had pseudo-binaries and the errors popped up on the console window.   (Maybe there's an ArmoryQt.exe.log?)
 
Try one thing for me:  generate a new offline address and send it 0.1 BTC.  After it gets one confirmation, try to execute an offline transaction with that.  I want to verify that the problem is an imported-address problem and not an any-address problem.  I've executed dozens of offline transactions myself, but I guess I never did with imported addresses... they were always part of the wallet's deterministic chain.  If you have the same problem, I probably injected yet another bug into version 0.55 before release (wouldn't be the first).

If you feel like battling this further, the next thing to try would be version 0.51, which requires installing the extra packages and running ArmoryQt.py.  Download the zipfile. Unfortunately, you'll have to install python-twisted (32bit or 64bit), run the zope script (included in zip file) and then the PyQt installer (32bit or 64bit).  At least it can all be done without deleting 0.55, just close 0.55 before running 0.51.  

There's a good chance 0.51 will just work.  And I'll have to debug 0.55 on my own.  But if you get the same problem, you'll see an error on the console window popup.  

Thanks for your patience with this.  Please continue this conversation via PM or email (etotheipi_gmail_com) and I'll feed the results back into this thread later.   I'll be back on my development computer soon, and will get a chance to tackle all this stuff myself, soon.

 

[cypherdoc]

way to go Holliday.  you're doing what i want to do but haven't gotten around to.

can't wait to get my laptop eto!

[etotheipi]

way to go Holliday.  you're doing what i want to do but haven't gotten around to.

can't wait to get my laptop eto!

cypherdoc,

I'll work on the laptops first thing Monday.  I didn't consider that my donors might want them ASAP    

I'm making a cumulative to-do list, and will have all of Sunday to test and fix everything I broke before I left.  That'll teach me a lesson about releasing software before a vacation!  I also will implement a more rigorous testing-checklist, to execute before every release.  Unfortunately, there's a ton of features, so it's quite tedious to re-check everything, but I really need better quality control now that I'm marketing the app to a wider audience (hopefully it can avoid stupid things like transactions not sending properly, ugh).

Thanks for your patience!
-Eto

[cypherdoc]

Omg, you just gave me wet dreams

Can't wait to try this!

[etotheipi]

Thanks so much Holliday!  I'm glad you finally got it working.

Then I followed the instructions to create an offline transaction. Creating and importing a watching only wallet was a breeze. I created the transaction and plugged the USB key into my offline computer.

This is where I ran into my second problem. The offline computer refused to sign the transaction. After sending a few message to etotheipi he figured out that I had a partial block chain on my offline computer and it was interfering with the transaction signing process. The partial block chain was from creating offline Satoshi wallets. Anyway, I deleted that per etotheipi's instructions and I was able to sign the transaction!

FYI:  this problem is a bug Holliday helped me find -- if there is a blockchain file on the offline computer (~/.bitcoin/blk0001.dat) then it will load it and skip some other code that is needed for offline transactions.  If the system is never going to touch the internet again, you might as well just delete the blk0001.dat file, or run setup your Armory shortcut with the --noblockchain option.  (the blk0001.dat file is usually found at C:\Users\<username>\AppData\Roaming\Bitcoin\blk0001.dat on Windows, /home/<username>/.bitcoin/blk0001.dat on linux)

I will be fixing this bug (along with the send-tx bug) in version 0.60, hopefully by the end of tomorrow.  So,  this "hack" will only be necessary until then.

If there's anyone else who has successfully setup offline wallets and used them, please let me know.  Up until now, Holliday is the only user who has given me direct feedback on it.

[etotheipi]

Armory version 0.56 -- Bugfixes!

• Fixed the send-tx bug -- you should now see transactions show up in the ledger as soon as you send them (no error)
• Fixed the problem causing an offline system to fail to sign tx if it has a stale blockchain file (yes, weird, but it's fixed now)

Windows 32-bit (md5: 1b3e2ccd0fa06d3ac62d578da33f4a1b)
Windows 64-bit (md5: 779f18c1e3cdaa4aae898852b4b7aac5)

Second bug is that both the messages blocks you've posted, that are supposed to verify that you made these messages, produce a dialog saying "The supplied signature is not valid!". There are no errors on the command line after doing this check. Both these messages fail to validate:

Now that I'm home, I'm following up on this bug report.  Between 0.55-alpha-RC2 and 0.55 I updated the message signing interface to improve security a little bit.  It necessarily broke previous signatures.  I botched the previous signature block because it said 0.55 but was actually 0.55-RC2.   I have a 0.55 signature block that will work, but there's no point anymore because I just released 0.56:

Code:

-----BEGIN-SIGNATURE-BLOCK-------------------------------------
Address:    1ArmoryXcfq7TnCSuZa9fQjRYwJ4bkRKfv
Message:    "Armory version 0.56 was released 2012-Mar-11 01:"
            "07am.  The Win32 zip file has the following md5s"
            "um:  1b3e2ccd0fa06d3ac62d578da33f4a1b.  The Win6"
            "4 zip file has the following md5sum: 779f18c1e3c"
            "daa4aae898852b4b7aac5.  Please do not use zip-fi"
            "les that do not have hashes that match the above"
            " strings!"
PublicKey:  0411d14f8498d11c33d08b0cd7b312fb2e6fc9aebd479f8e9a
            b62b5333b2c395c5f7437cab5633b5894c4a5c2132716bc36b
            7571cbe492a7222442b75df75b9a84
Signature:  92652a4f31be8f524a0fc00328fa7b0d496d30e217c2dc9c3d
            05a6f8a08e620cea11f4c5486851e842d42cec76de1822a47e
            17676836b0f5edf802cb336e0c9d
-----END-SIGNATURE-BLOCK---------------------------------------

Please tell me if that doesn't work.  And I'm done messing with the signature block code, so everything after 0.55 should work.