Armory - Discussion Thread

[N.Z.]

So...I won`t see transaction details until you implement the new wallet design, right?

[1713548832]

1713548832

[1713548832]

1713548832

[1713548832]

1713548832

[etotheipi]

So...I won`t see transaction details until you implement the new wallet design, right?

Are you in Linux or Windows?  If you are in linux, you could modify the code yourself, to remove the one offending line (well, change it).  It's the same line as you see the error:  first try changing it from "str(...)" to "unicode(...)".  If that doesn't work, then just remove the line entirely and change it to "txtime='0'".  That second one should definitely work...

The new wallet needs to support unicode strings, but I will be going through and updating ALL of Armory for unicode support.  I should've done it from the start, but I wasn't really familiar with unicode when I started... (yes, silly American...)

[61197da925c1]

maybe you should work on an anti-trojan solution or an automatic lock-out feature after a certain number of seconds

if you copy keepass, it should be more successful

[N.Z.]

changing it from "str(...)" to "unicode(...)"

Yes, it fixed that, thanks

[etotheipi]

changing it from "str(...)" to "unicode(...)"

Yes, it fixed that, thanks

I'll throw that into my next update, since it clearly improves the situation for some users, without any risk of harm (as far as I can tell...).  I mean, as a band-aid until I get official support throughout the app.

[etotheipi]

Just a random update:  I have been experimenting with LevelDB, and it appears there is an excellent compromise upgrade I can make:  it would be to swap out the underlying C++ txMap_ and headerMap_ normally held in RAM using std::map<a,b>, with a disk-based equivalent using LevelDB.  The change looks like it would pretty transparent to all code that leverages the C++ utilities (besides creating an extra directory to store the map data).   If that's the only thing I changed, I think I'd get quite a bit of value out of it (and some downside):

++ RAM usage would drop considerably;  probably from 1.5 GB (proportional to blockchain size) to 200 MB (should be pretty flat)
++ Quite a bit of data would be saved between loads naturally, probably leading to much faster startup times
-- HDD usage would go up quite a bit;  probably from 50 MB (for installed files and wallets), to about 1 GB (proportional to blockchain size)
-- Creates a much more "stateful" Armory, which is a downside;  Since I currently always rescan the chain, every load is a fresh start free from problems from the last load.  No matter what bad state Armory got into before, a restart will fix it (because the initial scan is much more robust than handling all the crazy event sequences that users can induce). 

I suppose, if necessary, I could keep the rescanning (so keep the load time high) and just swap RAM for HDD usage.  But I think rebuilding the maps every time would be quite a bit slower than the current RAM solution (gah, always a trade-off).  On the other hand, the underlying C++ libraries have become much more robust over the months, such that it may not actually be that much effort to produce similar robustness with the saved data.  To be clear: it's not *that big of a deal*, but with this scheme comes extra risks that a user could get "locked out" by a bad state of the saved data and have no clear way to recover (as happens with Bitcoin-Qt when blkindex.dat gets corrupted).

Edit: In fact, the most frustrating (and frequent) bug reports I've received, have been because the one file I keep between loads (mempool.bin, for holding zero-conf tx), would get corrupted and prevent Armory from finishing loading.  I actually built into the latest release a way to detect that loading failed three times in a row, and to just delete it.  Perhaps I'll do the same thing for this data -- delete the disk maps and let Armory rebuild them if there's a problem.

I'm pretty busy the next couple weeks, but I guess I can relax a bit, now that beta finished   
Please let me know if you have tried (and succeeded) testing coin control.  I think it will be worth a full release just for that feature if I didn't break anything else.

[K1773R]

Just a random update:  I have been experimenting with LevelDB, and it appears there is an excellent compromise upgrade I can make:  it would be to swap out the underlying C++ txMap_ and headerMap_ normally held in RAM using std::map<a,b>, with a disk-based equivalent using LevelDB.  The change looks like it would pretty transparent to all code that leverages the C++ utilities (besides creating an extra directory to store the map data).   If that's the only thing I changed, I think I'd get quite a bit of value out of it (and some downside):

++ RAM usage would drop considerably;  probably from 1.5 GB (proportional to blockchain size) to 200 MB (should be pretty flat)
++ Quite a bit of data would be saved between loads naturally, probably leading to much faster startup times
-- HDD usage would go up quite a bit;  probably from 50 MB (for installed files and wallets), to about 1 GB (proportional to blockchain size)
-- Creates a much more "stateful" Armory, which is a downside;  Since I currently always rescan the chain, every load is a fresh start free from problems from the last load.  No matter what bad state Armory got into before, a restart will fix it (because the initial scan is much more robust than handling all the crazy event sequences that users can induce). 

I suppose, if necessary, I could keep the rescanning (so keep the load time high) and just swap RAM for HDD usage.  But I think rebuilding the maps every time would be quite a bit slower than the current RAM solution (gah, always a trade-off).  On the other hand, the underlying C++ libraries have become much more robust over the months, such that it may not actually be that much effort to produce similar robustness with the saved data.  To be clear: it's not *that big of a deal*, but with this scheme comes extra risks that a user could get "locked out" by a bad state of the saved data and have no clear way to recover (as happens with Bitcoin-Qt when blkindex.dat gets corrupted).

Edit: In fact, the most frustrating (and frequent) bug reports I've received, have been because the one file I keep between loads (mempool.bin, for holding zero-conf tx), would get corrupted and prevent Armory from finishing loading.  I actually built into the latest release a way to detect that loading failed three times in a row, and to just delete it.  Perhaps I'll do the same thing for this data -- delete the disk maps and let Armory rebuild them if there's a problem.

I'm pretty busy the next couple weeks, but I guess I can relax a bit, now that beta finished   
Please let me know if you have tried (and succeeded) testing coin control.  I think it will be worth a full release just for that feature if I didn't break anything else.

could you maybe implemented and support both ways? in the meaning of writting a loader and you have to specify if it should use the HD more or the RAM. not everyone hasnt enough RAM

[prezbo]

I've had armory crashing twice after running for about two days with the following error:

Code:

2012-12-04 10:22 (ERROR) -- armoryengine.pyc:10344 - Waiting for BDM output that didn't come after 10s.
2012-12-04 10:22 (ERROR) -- armoryengine.pyc:10345 - BDM state is currently: BlockchainReady
2012-12-04 10:22 (ERROR) -- armoryengine.pyc:10346 - Called from: armoryengine.pyc:10471 (46447880)
2012-12-04 10:22 (ERROR) -- armoryengine.pyc:10347 - BDM currently doing: ReadBlkUpdate (46447880)
2012-12-04 10:22 (ERROR) -- armoryengine.pyc:10348 - Direct traceback
2012-12-04 10:22 (ERROR) -- armoryengine.pyc:10350 - Traceback:
Traceback (most recent call last):
  File "armoryengine.pyc", line 10340, in waitForOutputIfNecessary
  File "Queue.pyc", line 176, in get
Empty

These are the two lines before the error, which might be of interest

Code:

2012-12-04 03:26 (INFO) -- ArmoryQt.py:3315 - New Block! : 210818
2012-12-04 03:30 (INFO) -- ArmoryQt.py:3315 - New Block! : 210818

Maybe something to do with chain reorganization?

(Armory 0.85-beta, Windows 7 64 bit)

edit: Ok, maybe not reorg, this is from 3 days ago:

Code:

2012-12-01 03:29 (INFO) -- ArmoryQt.py:3300 - New Block! : 210374
2012-12-01 03:30 (INFO) -- ArmoryQt.py:3300 - New Block! : 210375
2012-12-01 09:00 (ERROR) -- armoryengine.pyc:10335 - Waiting for BDM output that didn't come after 10s.
2012-12-01 09:00 (ERROR) -- armoryengine.pyc:10336 - BDM state is currently: BlockchainReady
2012-12-01 09:00 (ERROR) -- armoryengine.pyc:10337 - Called from: armoryengine.pyc:10462 (74163504)
2012-12-01 09:00 (ERROR) -- armoryengine.pyc:10338 - BDM currently doing: ReadBlkUpdate (74163504)
2012-12-01 09:00 (ERROR) -- armoryengine.pyc:10339 - Direct traceback
2012-12-01 09:00 (ERROR) -- armoryengine.pyc:10341 - Traceback:
Traceback (most recent call last):
  File "armoryengine.pyc", line 10331, in waitForOutputIfNecessary
  File "Queue.pyc", line 176, in get
Empty

[etotheipi]

I've had armory crashing twice after running for about two days with the following error:

Code:

2012-12-04 10:22 (ERROR) -- armoryengine.pyc:10344 - Waiting for BDM output that didn't come after 10s.
2012-12-04 10:22 (ERROR) -- armoryengine.pyc:10345 - BDM state is currently: BlockchainReady
2012-12-04 10:22 (ERROR) -- armoryengine.pyc:10346 - Called from: armoryengine.pyc:10471 (46447880)
2012-12-04 10:22 (ERROR) -- armoryengine.pyc:10347 - BDM currently doing: ReadBlkUpdate (46447880)
2012-12-04 10:22 (ERROR) -- armoryengine.pyc:10348 - Direct traceback
2012-12-04 10:22 (ERROR) -- armoryengine.pyc:10350 - Traceback:
Traceback (most recent call last):
  File "armoryengine.pyc", line 10340, in waitForOutputIfNecessary
  File "Queue.pyc", line 176, in get
Empty

These are the two lines before the error, which might be of interest

Code:

2012-12-04 03:26 (INFO) -- ArmoryQt.py:3315 - New Block! : 210818
2012-12-04 03:30 (INFO) -- ArmoryQt.py:3315 - New Block! : 210818

Maybe something to do with chain reorganization?

(Armory 0.85-beta, Windows 7 64 bit)

edit: Ok, maybe not reorg, this is from 3 days ago:

Code:

2012-12-01 03:29 (INFO) -- ArmoryQt.py:3300 - New Block! : 210374
2012-12-01 03:30 (INFO) -- ArmoryQt.py:3300 - New Block! : 210375
2012-12-01 09:00 (ERROR) -- armoryengine.pyc:10335 - Waiting for BDM output that didn't come after 10s.
2012-12-01 09:00 (ERROR) -- armoryengine.pyc:10336 - BDM state is currently: BlockchainReady
2012-12-01 09:00 (ERROR) -- armoryengine.pyc:10337 - Called from: armoryengine.pyc:10462 (74163504)
2012-12-01 09:00 (ERROR) -- armoryengine.pyc:10338 - BDM currently doing: ReadBlkUpdate (74163504)
2012-12-01 09:00 (ERROR) -- armoryengine.pyc:10339 - Direct traceback
2012-12-01 09:00 (ERROR) -- armoryengine.pyc:10341 - Traceback:
Traceback (most recent call last):
  File "armoryengine.pyc", line 10331, in waitForOutputIfNecessary
  File "Queue.pyc", line 176, in get
Empty

I think the chain re-org there was a coincidence.  I, too, have observed the occasional crash in Windows with the exact same thing in the log file -- it seems to be exponentially distributed with an average of about 1 day (its happened within 8 hours before, but usually within 4 days).  I can't tell for sure what is causing it, because it happens so infrequently, but the fact that every time it says "BDM currently doing: ReadBlkUpdate" gives me a good idea of where to look.  I have timed readBlkUpdate, and it takes between 200 and 400 microseconds to run, normally.  I'm not sure what could possibly happen to push it above 10s. 

Also, this only appears to happen in Windows.  Let me know if you've seen it on any other OS.  I'll put some debugging stuff into my Windows VM and see if I can catch more info... it seems that 90% of my bug reports have to do with this problem.

[picobit]

I got it yesterday on my Mac, but first it printed that it had lost connection to the Satoshi client, so I assumed that was the problem.

[etotheipi]

I got it yesterday on my Mac, but first it printed that it had lost connection to the Satoshi client, so I assumed that was the problem.

I think losing connection is a symptom, not a cause.  I just put a ton of debug statements in and will start it up and hopefully get a crash in the not-too-distant future.

[prezbo]

I got it yesterday on my Mac, but first it printed that it had lost connection to the Satoshi client, so I assumed that was the problem.

I think losing connection is a symptom, not a cause.  I just put a ton of debug statements in and will start it up and hopefully get a crash in the not-too-distant future.

Got another one of those just now, two in one day. Could you make an executible with the added debug statements so we can help?

[HorseRider]

etotheipi,

I used Armory for several weeks now, and really appreciate the feeling of 100% safety confidence, thank you very much.

Would you plan to develop the function to let users to send bitcoin from a specified address? There is such function in the blockchain.info.

Regards,

HorseRider

[etotheipi]

etotheipi,

I used Armory for several weeks now, and really appreciate the feeling of 100% safety confidence, thank you very much.

Would you plan to develop the function to let users to send bitcoin from a specified address? There is such function in the blockchain.info.

Regards,

HorseRider

Yes!  I just implemented "Coin Control" in Armory, in version 0.86-beta.  It will let you do exactly that if you are in expert mode!

If you are in Linux or OSX, you can get it right now by switching to the "coincontrol" branch.  If not, you'll have to wait for me to compile Windows versions, but I can do that later tonight.  They won't be official, but since you asked for it, you can help me test it

[etotheipi]

I just posted a copy of 0.86-testingversion. 

http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.86-beta_windows_testing.msi

Make sure you switch into "Expert" mode, and then there will be a button on the send screen.  It should be self-explanatory

[prezbo]

I just posted a copy of 0.86-testingversion. 

http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.86-beta_windows_testing.msi

Make sure you switch into "Expert" mode, and then there will be a button on the send screen.  It should be self-explanatory

This won't start for me...

Code:

Traceback (most recent call last):
  File "ArmoryQt.py", line 38, in <module>
    from PyQt4.QtCore import *
  File "PyQt4\QtCore.pyc", line 12, in <module>
  File "PyQt4\QtCore.pyc", line 10, in __load
ImportError: DLL load failed: The specified procedure could not be found.
Traceback (most recent call last):
  File "ArmoryQt.py", line 38, in <module>
  File "PyQt4\QtCore.pyc", line 12, in <module>
  File "PyQt4\QtCore.pyc", line 10, in __load
ImportError: DLL load failed: The specified procedure could not be found.

[etotheipi]

This won't start for me...

Ack!  Haven't seen that before!  I assume you are on 64-bit Windows?  I wonder if the 32-bit compiled version doesn't work on 64-bit Windows now, or maybe the installer didn't do everything it was supposed to...?  Can you please try uninstalling it and reinstalling it?  

I can't recompile the Win64 version just yet, because I just caught the dreaded crash in a debugger and I need examine it.  It looks juicy, though!  It thinks there was a blockfile split, and looking for blk0004.dat.   Hopefully this will be a quick fix!  When I'm done, I'll revert the debugging code and compile a Win 64bit version.

[prezbo]

This won't start for me...

Ack!  Haven't seen that before!  I assume you are on 64-bit Windows?  I wonder if the 32-bit compiled version doesn't work on 64-bit Windows now, or maybe the installer didn't do everything it was supposed to...?  Can you please try uninstalling it and reinstalling it?  

I can't recompile the Win64 version just yet, because I just caught the dreaded crash in a debugger and I need examine it.  It looks juicy, though!  It thinks there was a blockfile split, and looking for blk0004.dat.   Hopefully this will be a quick fix!  When I'm done, I'll revert the debugging code and compile a Win 64bit version.

Yup, 64 bit win 7. Nice, reinstallation seems to have done the trick.

[Ente]

Where is the option to import private keys? I saw various pages mentioning that it is located in the wallet properties page but I can't seem to find it.

Also, is there a way to import a public key as a "Watch only" type of address?

You have to create a wallet first, and then select the wallet into which you want to import the keys.  From the wallet properties, there's an option on the bottom right for importing private keys.

Unfortunately, there is no way to import public keys into a watch-only wallet.  There's a couple reasons for this, and not all of them are laziness

I finally am in the process of switching to armory!
A few questions..

a) I guess no news about "importing" an address when only the public address is known? I imagine this should be possible, as we have the blockchain with all transactions of this address?
edit: It doesn't have to be a watch-only-wallet. Would it be more possible to have a whole new type of "wallet" for this?

b) Imported addresses: The paper backup warns that imported addresses are not included in the paper backup. Are they included in the digital backup / wallet file?

c) and OT: I wish to have bitcoind always running in background. Does anyone know a way to "connect" bitcoin-qt to the running bitcoind, instead of armory, when armory is closed? I would like that option, as I have a lot of wallets from bitcoin-qt left, and start all fresh on armory. And yes, that's nothing I expect the programmer of armory to code ;-)

Thank you for this nice client! I already love it, never restarting the client again to switch wallets! :-)
Also, what is currently the limiting factor in armory's development? Time, funds, tasks, coders?

Ente

[etotheipi]

I finally am in the process of switching to armory!
A few questions..

a) I guess no news about "importing" an address when only the public address is known? I imagine this should be possible, as we have the blockchain with all transactions of this address?

b) Imported addresses: The paper backup warns that imported addresses are not included in the paper backup. Are they included in the digital backup / wallet file?

c) and OT: I wish to have bitcoind always running in background. Does anyone know a way to "connect" bitcoin-qt to the running bitcoind, instead of armory, when armory is closed? I would like that option, as I have a lot of wallets from bitcoin-qt left, and start all fresh on armory. And yes, that's nothing I expect the programmer of armory to code ;-)

Thank you for this nice client! I already love it, never restarting the client again to switch wallets! :-)
Also, what is currently the limiting factor in armory's development? Time, funds, tasks, coders?

Ente

Thanks Ente:

(a) There are no updates on that yet.  If you have the private key, can you import it into the offline wallet and re-create the watching-only wallet and re-import that on your online computer.  Also, even if I had the pub-key import feature, you can't import public-key-only addresses into a full wallet.  Every address in the wallet must have the private key, or not have the private key (it's too complicated to deal with mixed wallets... you would just create a new wallet for that).

(b) The digital backup does include all imported addresses.  However, I'm more of a fan of paper backups, so I recommend printing out the individual keys (select "Imported Addresses Only").  Especially, if you are importing lots of keys and making digital backups, you don't know which ones have been backed up already without loading the digital backup and checking -- it's obvious if you have them printed, though.

(c) I'm not sure I understand this.  There should be no problem running only bitcoind, and Armory should connect to it the same as it would to Bitcoin-Qt.  Unless you are talking about running bitcoind on a different computer...  (it will be possible to connect to remote nodes, in the future, but it's not ready yet).

Time is definitely a limiting factor in the development.  Almost-full-time job, just got engaged, holiday parties, etc.  My fiance knows how much enjoy working on this, and gives me lots of room/time to work on it, but it would definitely help if I didn't have a job.  But I also don't see how I could sustain on Armory alone without converting it to a paid-product model (and even then, I'm not sure the market is big enough, and the stability of Armory is high enough for that).  Right now I'm mostly happy with the arrangement, despite wanting to spend more time on Armory and less at work, but this is the most stable for me. 

People getting more involved in the code would be great.  Though, I understand Armory code base is big and scary  (about 25k lines of code, so far).  It is fairly well-commented, but it's also flush with corner-case catching, error detection, and luxurious informational dialogs which really obfuscate the intent of the code.  It can be tough for someone to see what the code is doing exactly when I've add multiple ways to detect various error conditions and half a dozen message box warnings to accommodate different conditions.  But I'm not sure there's a good way around that...

I was considering making a plugin system for Armory, that would allow users to create new tabs on the main screen.  There's some details that need to be worked out so that it can be done "safely" (or as safe as is reasonable).  That would definitely make it easy for users to contribute new features that could later be merged when they're fully developed.  Though, I'm not sure that's the best way to get other people involved in the code...