Armory - Discussion Thread

[etotheipi]

Besides the bulk-import feature missing, has anyone found any issues with the RAM-reduction (0.70) that should make me concerned about merging it into master?  As far as I can tell:

(1) Linux-64:
          -- Previous:  Required 3+ GB of RAM, super fast
          -- Now:  Works with 0.5 GB of RAM! And same speed if you have the spare RAM
(2) Linux-32:
          -- Previous:  Kind of worked with 3.9 GB of RAM if you did nothing else.
          -- Now:      Works!  With 0.5 GB of RAM!
(3) Windows-64:
          -- Previous:  Worked with 4+ GB of RAM, but used all of it.  Fast!
          -- Now:      Works with 1.5 GB, but 2 GB needed if you want it to load in less than 2 min.
(4) Windows-32:
          -- Previous:  Didn't work at all!
          -- Now:      Doesn't work at all!

Note:  "Requires X GB of RAM" means "Your system must have this much RAM for Armory to be usable", not "Armory consumes this much RAM"

Does this seem like an accurate assessment?  I'm a little concerned about Torus mentioning double-counted addresses, but I can't replicate the problem and it apparently goes away on restart -- and who knows, that might've been there before, too.

On another note:  Here's my short term priority list:

• Bulk Import Dialog (already like 80% done... just have to figure out some input and validation details)
• Address books!  FINALLY going to get this implemented
• New Wallet Format!  (Compressed Public Keys), (Compatibility with Satoshi 0.7.0 deterministic wallets), (Any-version Satoshi wallet migrate), (Much faster wallets), (P2SH support [preparation])

The new wallet format is likely to take be a HUGE time investment, especially because I have to maintain the old wallet format entirely and start dealing with multiple-versioning.  But it's totally worth it, in the long run.  

[jim618]

Hi Alan,

You must be pleased with the results of your memory mapping work !

I thought I would cross post about the Satoshi 0.7.0 deterministic wallets on the bitcoinj mailing list.
Do you have any links to either the discussion about it or an actual spec ?

Thanks,

Jim

[da2ce7]

(4) Windows-32:
          -- Previous:  Didn't work at all!
          -- Now:      Doesn't work at all!

People whom are using windows for Finance, should be using Windows 7.  If you are using windows 7, there is no reason why you wouldn't be using the 64bit version.

Windows XP is hard to keep secure, and is about to run-out on its security updates.

My conclusion is:  Windows XP is old, and soon to be insecure. Don't worry about not being able to support it.

[etotheipi]

Hi Alan,

You must be pleased with the results of your memory mapping work !

Pleased enough!  It's disappointing it didn't work better on Windows, since most users in the target audience are Windows users, but there's still a very high proportion of Linux users in this community, so the fact that it works so amazingly well, there, is quite pleasing.  

Eventually, the full-blockchain-scan-on-load is going to be silly (it already is, on Windows).  At some point (but not high priority) I will be upgrading it even further, to save info between loads, so it will load instantly but be in "reduced" mode until balances can be verified.  At that time, it might support 32-bit Windows systems, too.

I thought I would cross post about the Satoshi 0.7.0 deterministic wallets on the bitcoinj mailing list.
Do you have any links to either the discussion about it or an actual spec ?

Good question!  I've been talking to Sipa about it on IRC mostly.  At some point he had written something up, but when I asked, he said he was going to start a BIP on it.  My understanding is that he has a branch with a working deterministic wallet, and I know the technical details of it, so I can get started implementing it right away.  Perhaps if you ask him, he will provide his original pastebin/gist proposal.  But he might be preparing the BIP right now...

If you're interested, I can go into the gory details of it right now, but sipa is probably already in-progress, so I'll defer the question.

[jim618]

Hi Alan,

Thanks for your reply.
I will talk to sipa about it.

Would be logical to implement the same key generation alg etc as the Satoshi client.

[Raoul Duke]

Been testing Armory in Ubuntu 12.04 with the Unity interface and there are some visual errors.

http://imgur.com/a/W4PmW

[etotheipi]

Been testing Armory in Ubuntu 12.04 with the Unity interface and there are some visual errors.

http://imgur.com/a/W4PmW

Indeed, there are some issues with Armory layouts on small screens.  It looks like yours is on a super-small screen! 

In fact, I'm not sure how to appropriately handle that, besides noting that if you stretch the windows out just a little bit (but still within the screen size) they get much better.  That's obviously not a solution, but more of a comment about how to deal with it until I get a solution.   

Recommendations for how to accommodate for this more intelligently in my design layouts would be great.  I can't imagine that just changing the font size depending on desktop resolution would even do anything.  Maybe I just need to put less stuff on my GUIs...?

[Raoul Duke]

1366x768 is a small screen? That's a 15.4" laptop HD screen, so i wouldn't qualify it as a small screen, much less super-small

And yes, the window resizing trick makes it go away.

Also, sent you a small 1.5 BTC donation.

[etotheipi]

1366x768 is a small screen? That's a 15.4" laptop HD screen, so i wouldn't qualify it as a small screen, much less super-small

And yes, the window resizing trick makes it go away.

Also, sent you a small 1.5 BTC donation.

Hmm... those screenshots look more scrunched than Armory looks on 1024x600 screen on my EeePC.  Admittedly, I have the same problems on the Eee, but it only takes stretching it out a few pixels to make it look right. 

I'll see if there's a global change I can make to help: like setting minimum button/label heights (based on font) that will prevent the dialogs from opening too small...

[guruvan]

Maybe I'm doing it wrong? (or missed a post about this?)

Importing encrypted private key (hex) generated by vanitygen

Using the Privkey (hex) output from vanitygen I get this:

Code:

Traceback (most recent call last):
  File "/home/rob/devel/BitcoinArmory/qtdialogs.py", line 1636, in processUserString
    QMessageBox.critical(self, 'Invalid Data', e, QMessageBox.Ok)
TypeError: arguments did not match any overloaded call:
  QMessageBox.critical(QWidget, QString, QString, QMessageBox.StandardButtons buttons=QMessageBox.Ok, QMessageBox.StandardButton defaultButton=QMessageBox.NoButton): argument 3 has unexpected type 'BadInputError'
  QMessageBox.critical(QWidget, QString, QString, int, int, int button2=0): argument 3 has unexpected type 'BadInputError'
  QMessageBox.critical(QWidget, QString, QString, QString, QString button1Text=QString(), QString button2Text=QString(), int defaultButtonNumber=0, int escapeButtonNumber=-1): argument 3 has unexpected type 'BadInputError'

dialog operated correctly when attempting to import invalid key - proper error displayed.

=========
P.S. I have much the same issue as psy on my ubuntu box with the window sizes, and I'm running 1280x1024 on this machine. I haven't seen the oddness he saw in the balance display, just incorrect window sizes.

[etotheipi]

Maybe I'm doing it wrong? (or missed a post about this?)

Importing encrypted private key (hex) generated by vanitygen

Using the Privkey (hex) output from vanitygen I get this:

Code:

Traceback (most recent call last):
  File "/home/rob/devel/BitcoinArmory/qtdialogs.py", line 1636, in processUserString
    QMessageBox.critical(self, 'Invalid Data', e, QMessageBox.Ok)
TypeError: arguments did not match any overloaded call:
  QMessageBox.critical(QWidget, QString, QString, QMessageBox.StandardButtons buttons=QMessageBox.Ok, QMessageBox.StandardButton defaultButton=QMessageBox.NoButton): argument 3 has unexpected type 'BadInputError'
  QMessageBox.critical(QWidget, QString, QString, int, int, int button2=0): argument 3 has unexpected type 'BadInputError'
  QMessageBox.critical(QWidget, QString, QString, QString, QString button1Text=QString(), QString button2Text=QString(), int defaultButtonNumber=0, int escapeButtonNumber=-1): argument 3 has unexpected type 'BadInputError'

dialog operated correctly when attempting to import invalid key - proper error displayed.

=========
P.S. I have much the same issue as psy on my ubuntu box with the window sizes, and I'm running 1280x1024 on this machine. I haven't seen the oddness he saw in the balance display, just incorrect window sizes.

Guruvan, is this on 0.70?  I messed with the import box recently, so maybe I botched something.

In fact, it must be a bug, because it would pop up an error message if it wasn't.  I'll check it out tonight.

Thanks!

[guruvan]

Guruvan, is this on 0.70?  I messed with the import box recently, so maybe I botched something.

In fact, it must be a bug, because it would pop up an error message if it wasn't.  I'll check it out tonight.

Thanks!

Yep. 0.70 on ubuntu precise beta. Thank you!!

[etotheipi]

Renamed this to the "discussion thread", started a new "Announcement thread" just for major release information.  The discussion here was getting excessive/annoying for users who only want to know about major developments!

The new annoucement thread is:  https://bitcointalk.org/index.php?topic=75647.0

PLEASE DO NOT POST ON THAT THREAD!  Use the notify button at the top to subscribe!

I merged 0.70 into master, and compiled binaries for Windows.  Find them:  http://bitcoinarmory.com/index.php/get-armory

[etotheipi]

ACK!  Heads up, I totally flaked on my quality control, and didn't do testing with the new RAM-Reduction + Offline mode.  Strictly speaking, you can execute offline transactions with 0.70, but any other wallet management is a disaster!!!   Like really bad!

I apologize to cypherdoc, who has been complaining endlessly of things not working in offline mode, and I just assumed he didn't know what he was doing!    Sorry Cypher!

If you want to setup an offline system, us 0.60 or 0.61.  I'll be making a new release soon, though, fixing this along with (hopefully) bulk-address-import, and address books!  

[cypherdoc]

all the bugs i mentioned to you last night were in 0.61 (alpha) Ubuntu version namely:

1.  multiple instances of Armory open simultaneously.
2.  truncated displays in fund balances like psy mentioned.
3.  freeze when multiple instances of Armory are open.
4.  -0.00000001 balance displayed (nothing in wallet)

[etotheipi]

all the bugs i mentioned to you last night were in 0.61 (alpha) Ubuntu version namely:

1.  multiple instances of Armory open simultaneously.
2.  truncated displays in fund balances like psy mentioned.
3.  freeze when multiple instances of Armory are open.
4.  -0.00000001 balance displayed (nothing in wallet)

Please please please do not open Armory twice!  All my super-fancy corruption-resistant, auto-error-correcting wallet files were *not* designed to be accessed simultaneously by two processes.  It's on my list for BETA, to make the application a "singleton" which means that it will detect other instances of Armory being open when you try to start it and refuse, if necessary.

And along with all the 0.70+offline bugs I have mentioned, I have fixed the -0.00000001 balances in offline mode.  It should now display nothing when in offline mode.

Layouts on small screens... I'll devote some time to that after getting address books implemented.

[Red Emerald]

Please please please do not open Armory twice!  All my super-fancy corruption-resistant, auto-error-correcting wallet files were *not* designed to be accessed simultaneously by two processes.

This is irony right? I can never remember what is irony and what is just sad and funny.

[etotheipi]

Please please please do not open Armory twice!  All my super-fancy corruption-resistant, auto-error-correcting wallet files were *not* designed to be accessed simultaneously by two processes.

This is irony right? I can never remember what is irony and what is just sad and funny.

Is it?   The fancy anti-corruption features were intended to guarantee against corruption due to process crashes or power outtages.  No matter what nano-second your computer loses power, your wallet will either not be corrupted, or will be automatically restored from a non-corrupt backup.  And it's been pretty thoroughly tested.  The thought never entered my mind that someone would have two instances of it open! (maybe I should've...)

[Red Emerald]

Please please please do not open Armory twice!  All my super-fancy corruption-resistant, auto-error-correcting wallet files were *not* designed to be accessed simultaneously by two processes.

This is irony right? I can never remember what is irony and what is just sad and funny.

Is it?   The fancy anti-corruption features were intended to guarantee against corruption due to process crashes or power outtages.  No matter what nano-second your computer loses power, your wallet will either not be corrupted, or will be automatically restored from a non-corrupt backup.  And it's been pretty thoroughly tested.  The thought never entered my mind that someone would have two instances of it open! (maybe I should've...)

So you put in a bunch of code to protect the wallets from corruption, but if you open Armory twice, that fancy code can actually lead to corruption. I think irony is the right word.

[etotheipi]

Please please please do not open Armory twice!  All my super-fancy corruption-resistant, auto-error-correcting wallet files were *not* designed to be accessed simultaneously by two processes.

This is irony right? I can never remember what is irony and what is just sad and funny.

Is it?   The fancy anti-corruption features were intended to guarantee against corruption due to process crashes or power outtages.  No matter what nano-second your computer loses power, your wallet will either not be corrupted, or will be automatically restored from a non-corrupt backup.  And it's been pretty thoroughly tested.  The thought never entered my mind that someone would have two instances of it open! (maybe I should've...)

So you put in a bunch of code to protect the wallets from corruption, but if you open Armory twice, that fancy code can actually lead to corruption. I think irony is the right word.

Any file that is constantly modified by two processes at once is at risk of being corrupted in unpredictable ways.   I'm not sure there's anything special about my code that does it.  It's more the fact that I never put in any extra code/locks to protect against this situation.

I'm looking into file locks right now to see if I can prevent Armory from opening twice.  Looks like it needs some OS-specific code....