Armory - Discussion Thread

[xhoud01]

Hi is it possible to create many bitcoin addresses from Armory? I need to create 10.000 BTC addresses in Armory. Any hack?

Daniel

[1714199998]

1714199998

[1714199998]

1714199998

[1714199998]

1714199998

[1714199998]

1714199998

[1714199998]

1714199998

[1714199998]

1714199998

[etotheipi]

Hi is it possible to create many bitcoin addresses from Armory? I need to create 10.000 BTC addresses in Armory. Any hack?

Daniel

Funny you ask -- I just added a feature for doing this in the latest version (0.84.5)!

If you install the latest version, run Armory, then switch to "Expert" usermode, your wallet properties will have a new button allowing you to generate more addresses.  You can have it generate 10,000 addresses (though it might take a few minutes).  Once they are created, you can go into "Backup Individual Keys" and export just the private keys.  Now, I don't know how you intend to read them, but they may not be in the best format for importing into another application.   If you really need them formatted another way, I can create a very short python script for you to export them however you want (or if you are capable of it yourself, I can tell you exactly how to read the wallet files and pull private keys out of it (using armoryengine.py).

EDIT - Sorry, running the script yourself will be difficult unless you are on a Linux-based system.  It is rather difficult to get it all setup in Windows.  Let me know if the GUI interface is not sufficient and we'll figure something out

[picobit]

Should I still use the "threading" branch, or has it been merged into the trunk?

[etotheipi]

Should I still use the "threading" branch, or has it been merged into the trunk?

Not merged yet.  The threading branch is the correct place to be.  Head of the "threading" branch is currently 0.84.5-alpha+, which hopefully will just be renamed to 0.85-beta... but there are probably a few more minor bugs/polishing details that will be fleshed out before then.

Speaking of that, I never even posted here that I did a semi-official release of 0.84.5!   I posted about it in the base forum, but never mentioned it here (sorry).  So read it about in the new thread!.

I am pretty comfortable with 0.84.5, but I needed a wider audience to test it before the official beta release.  And I couldn't get that audience without doing a semi-official, GPG-signed release so that people are comfortable with it.  It's kind of a catch-22, but it seems to be working so far

[HorseRider]

@etotheipi

Last time I tried to install the Armory in Win7 and WinXP but failed. This weekend I installed vmware first and build a Ubuntu 10.04 VM, and it works. I have an offline laptop now, but the online computer still have not downloaded the blockchain yet. I will try the offline signing function tonight.

thanks for your great effort!

[picobit]

Hi etotheipi,

I am afraid that the threading branch does not work well on Mac OS X.  The file save dialogs are unresponsive, you can write a file name, but no other widgets react, and pressing return does not result in the file being saved.  This essentially renders offline mode useless, as I cannot save the unsigned transactions. 

Suspecting an update of a library or something, I reverted to the master branch and recompiled, and then it works as it always did (but I immediately miss the multithreading stuff).

I actually do suspect some kind of race conditions, for even in the master branch the save window behaves slightly inconsistently.  Sometimes the file name is prefilled with a file name for the unsigned transition, sometimes it is not, apparently randomly.  Is it possible that the save window is somehow popped up before it is 100% initialized?

All this mess leads me to an unrelated question regarding offline transactions.  I now created a number of unsigned transactions that never got saved.  Will Armory remember these and by trying to avoid creating double spends prevent me from spending some of my funds.  If not, what if I create two or more offline transactions and wait signing them to later, will I then risk that they contain double spends when I transmit them?

[etotheipi]

Hi etotheipi,

I am afraid that the threading branch does not work well on Mac OS X.  The file save dialogs are unresponsive, you can write a file name, but no other widgets react, and pressing return does not result in the file being saved.  This essentially renders offline mode useless, as I cannot save the unsigned transactions. 

Suspecting an update of a library or something, I reverted to the master branch and recompiled, and then it works as it always did (but I immediately miss the multithreading stuff).

I actually do suspect some kind of race conditions, for even in the master branch the save window behaves slightly inconsistently.  Sometimes the file name is prefilled with a file name for the unsigned transition, sometimes it is not, apparently randomly.  Is it possible that the save window is somehow popped up before it is 100% initialized?

All this mess leads me to an unrelated question regarding offline transactions.  I now created a number of unsigned transactions that never got saved.  Will Armory remember these and by trying to avoid creating double spends prevent me from spending some of my funds.  If not, what if I create two or more offline transactions and wait signing them to later, will I then risk that they contain double spends when I transmit them?

picobit,

That is unfortunate about the save-file dialogs.  I'm really not sure how I can do anything about that, since the chunk of code that runs those dialogs is entirely out of my control.  Perhaps it is a Qt library upgrade on OSX?  What version of OSX?  @RedEmerald: do you see this too?  I am not near an OSX machine or VM, so I can't really do anything at the moment.  I will examine the code around those calls and see if I can find anything that looks suspicious.  But I doubt it -- those save dialogs are 100% part of the Qt library (I'll check to make sure I'm not doing something stupid before I invoke them).

The question about offline transactions is a good one.  The answer is:  nothing is saved.  You could go either way with the design, but I think they are both annoying, and actually putting in the work to save off the maybe-used-coins info might get the user into more of a mess than the way I did it.  So the answer is that Armory does not remember anything at all about unsigned transactions it saves.  Thus, if you create two consecutive ones without broadcasting the first, it is likely to create an invalid second transaction.   One solution is to make a single, multi-output transaction...

The converse is not only more work, but could put the user into states of unusability.  If they create an offline tx and then decide not to ever send it, then Armory would treat those coins as "locked," yet the user would believe they should still have access to the coins.  Maybe they were just messing around with the interface to see if things would work, and then canceled out when it told them to take it to the offline computer.  Their balance would be artificially low, and they'd have to do something to unlock the coins.  I could see that being confusing.  (I could probably find a way to make the interface accommodate both, but it won't be high on priority list, right now).

The way it's done right now:  if the user takes two transactions over and only one is valid, then one will go through, the second one won't, and then they'll be annoyed, but they'll try the second one again... which will now go through.  It was a bit extra work, but it gets done.

[picobit]

I will examine the code around those calls and see if I can find anything that looks suspicious.  But I doubt it -- those save dialogs are 100% part of the Qt library (I'll check to make sure I'm not doing something stupid before I invoke them).

The strange thing is that the behaviour is different in the two versions, perhaps multithreading is somehow interfering with Qt's own multithreading.  I will try to look at it myself, and also try if I can get another version of Qt.  I use the version in homebrew:
qt: stable 4.8.3 (bottled), HEAD
pyqt: stable 4.9.4

The question about offline transactions is a good one.  The answer is:  nothing is saved. 

Good.  I think this way of doing it is the least of many evils.  Any attempt to be "smart" is just going to cause grief, and as you say the failure mode in this case is benign.

[etotheipi]

I will examine the code around those calls and see if I can find anything that looks suspicious.  But I doubt it -- those save dialogs are 100% part of the Qt library (I'll check to make sure I'm not doing something stupid before I invoke them).

The strange thing is that the behaviour is different in the two versions, perhaps multithreading is somehow interfering with Qt's own multithreading.  I will try to look at it myself, and also try if I can get another version of Qt.  I use the version in homebrew:
qt: stable 4.8.3 (bottled), HEAD
pyqt: stable 4.9.4

The question about offline transactions is a good one.  The answer is:  nothing is saved. 

Good.  I think this way of doing it is the least of many evils.  Any attempt to be "smart" is just going to cause grief, and as you say the failure mode in this case is benign.

I thought about it, it seems doable to actually have a button on the screen where you save the unsigned transaction, that says "Lock these coins".  The tooltip will explain that it will "lock" the coins for 24 hours to prevent subsequent transactions from using conflicting coins.  I suppose that's not too bad...

[Red Emerald]

Hi etotheipi,

I am afraid that the threading branch does not work well on Mac OS X.  The file save dialogs are unresponsive, you can write a file name, but no other widgets react, and pressing return does not result in the file being saved.  This essentially renders offline mode useless, as I cannot save the unsigned transactions. 

Suspecting an update of a library or something, I reverted to the master branch and recompiled, and then it works as it always did (but I immediately miss the multithreading stuff).

I actually do suspect some kind of race conditions, for even in the master branch the save window behaves slightly inconsistently.  Sometimes the file name is prefilled with a file name for the unsigned transition, sometimes it is not, apparently randomly.  Is it possible that the save window is somehow popped up before it is 100% initialized?

All this mess leads me to an unrelated question regarding offline transactions.  I now created a number of unsigned transactions that never got saved.  Will Armory remember these and by trying to avoid creating double spends prevent me from spending some of my funds.  If not, what if I create two or more offline transactions and wait signing them to later, will I then risk that they contain double spends when I transmit them?

picobit,

That is unfortunate about the save-file dialogs.  I'm really not sure how I can do anything about that, since the chunk of code that runs those dialogs is entirely out of my control.  Perhaps it is a Qt library upgrade on OSX?  What version of OSX?  @RedEmerald: do you see this too?  I am not near an OSX machine or VM, so I can't really do anything at the moment.  I will examine the code around those calls and see if I can find anything that looks suspicious.  But I doubt it -- those save dialogs are 100% part of the Qt library (I'll check to make sure I'm not doing something stupid before I invoke them).

I am experiencing this issue, too. I would have found it earlier, but I've been doing most of my testing on my ubuntu system, and less on my mac recently.  It appears to affect all of the save dialogs, I was unable to "Export Transactions"

[etotheipi]

Hi etotheipi,

I am afraid that the threading branch does not work well on Mac OS X.  The file save dialogs are unresponsive, you can write a file name, but no other widgets react, and pressing return does not result in the file being saved.  This essentially renders offline mode useless, as I cannot save the unsigned transactions. 

Suspecting an update of a library or something, I reverted to the master branch and recompiled, and then it works as it always did (but I immediately miss the multithreading stuff).

I actually do suspect some kind of race conditions, for even in the master branch the save window behaves slightly inconsistently.  Sometimes the file name is prefilled with a file name for the unsigned transition, sometimes it is not, apparently randomly.  Is it possible that the save window is somehow popped up before it is 100% initialized?

All this mess leads me to an unrelated question regarding offline transactions.  I now created a number of unsigned transactions that never got saved.  Will Armory remember these and by trying to avoid creating double spends prevent me from spending some of my funds.  If not, what if I create two or more offline transactions and wait signing them to later, will I then risk that they contain double spends when I transmit them?

picobit,

That is unfortunate about the save-file dialogs.  I'm really not sure how I can do anything about that, since the chunk of code that runs those dialogs is entirely out of my control.  Perhaps it is a Qt library upgrade on OSX?  What version of OSX?  @RedEmerald: do you see this too?  I am not near an OSX machine or VM, so I can't really do anything at the moment.  I will examine the code around those calls and see if I can find anything that looks suspicious.  But I doubt it -- those save dialogs are 100% part of the Qt library (I'll check to make sure I'm not doing something stupid before I invoke them).

I am experiencing this issue, too. I would have found it earlier, but I've been doing most of my testing on my ubuntu system, and less on my mac recently.  It appears to affect all of the save dialogs, I was unable to "Export Transactions"

It is disappointing but not surprising.  I ran into some bizarre but documented issues with vector<>  iteration when using swig with -threads option.  Unfortunately, I can't figure out how I would work around it, and I haven't found anything searching the internet for related discussion.  Suggestions are welcome...

[picobit]

It is disappointing but not surprising.  I ran into some bizarre but documented issues with vector<>  iteration when using swig with -threads option.  Unfortunately, I can't figure out how I would work around it, and I haven't found anything searching the internet for related discussion.  Suggestions are welcome...

@etotheipi
Could you be a little more specific, then I would like to look into it.  Not that I have great hopes...

But I have used swig a lot some years ago - abandoned it to writing the C/Python interface manually, as 90% of the work had to be done anyway in the form of typemaps, and debugging was kind of hard.  No experience with threading and swig, though.

I am experiencing this issue, too. I would have found it earlier, but I've been doing most of my testing on my ubuntu system, and less on my mac recently.  It appears to affect all of the save dialogs, I was unable to "Export Transactions"

@Red Emerald
Which Qt are you using?  Homebrew, fink, macports or a fourth option?  Are you using the Apple-supplied Python or the one provided by homebrew/macports/whatever?

[prezbo]

Would it be possible to implement armory connecting to stratum servers for the necessary blockchain information? Something like that would greatly improve usability for people that don't have the time to wait for the blockchain to sync. Maybe have users choose how they want to be connected, via bitcoin-qt or a lite-client server? I'd be willing to pledge some bitcoins for something like that.

[picobit]

I looked a bit at the code, and experimented with a few print statements.

It looks like it is the call to QFileDialog.getSaveFileName() that fails.  It is called with sensible arguments, but never returns, as the resulting dialog is mostly dead.  It looks like the events generated by that dialog are never processed.  I can change the file name, and TAB will move between the file name, the search bar, and the sidebar.  It never gives focus to the buttons at the bottom (New Folder, Cancel and Save).

Since this only happens in the multithreaded version of Armory, it is most likely either a bug in Qt manifesting itself under MacOS (but then why does it not affect other programs - there does not seem to be any open bug reports on it).  Or Armory is doing something with threads which is technically not allowed, but just happens to work in most circumstances.  It it the same Python thread making all Qt calls?  Does Qt make callbacks into Python from a different thread?  Does the swig library mess up the thread state of Python?

Of course I am idly speculating, and it is not likely that it will be useful.  But just in case...

[Red Emerald]

It is disappointing but not surprising.  I ran into some bizarre but documented issues with vector<>  iteration when using swig with -threads option.  Unfortunately, I can't figure out how I would work around it, and I haven't found anything searching the internet for related discussion.  Suggestions are welcome...

@etotheipi
Could you be a little more specific, then I would like to look into it.  Not that I have great hopes...

But I have used swig a lot some years ago - abandoned it to writing the C/Python interface manually, as 90% of the work had to be done anyway in the form of typemaps, and debugging was kind of hard.  No experience with threading and swig, though.

I am experiencing this issue, too. I would have found it earlier, but I've been doing most of my testing on my ubuntu system, and less on my mac recently.  It appears to affect all of the save dialogs, I was unable to "Export Transactions"

@Red Emerald
Which Qt are you using?  Homebrew, fink, macports or a fourth option?  Are you using the Apple-supplied Python or the one provided by homebrew/macports/whatever?

I use brew to install all the dependencies, and I compiled armory against the system python.

[etotheipi]

I looked a bit at the code, and experimented with a few print statements.

It looks like it is the call to QFileDialog.getSaveFileName() that fails.  It is called with sensible arguments, but never returns, as the resulting dialog is mostly dead.  It looks like the events generated by that dialog are never processed.  I can change the file name, and TAB will move between the file name, the search bar, and the sidebar.  It never gives focus to the buttons at the bottom (New Folder, Cancel and Save).

Since this only happens in the multithreaded version of Armory, it is most likely either a bug in Qt manifesting itself under MacOS (but then why does it not affect other programs - there does not seem to be any open bug reports on it).  Or Armory is doing something with threads which is technically not allowed, but just happens to work in most circumstances.  It it the same Python thread making all Qt calls?  Does Qt make callbacks into Python from a different thread?  Does the swig library mess up the thread state of Python?

Of course I am idly speculating, and it is not likely that it will be useful.  But just in case...

The  BlockDataManager thread runs in its own little loop, and only executes non-Qt-related code in its own little bubble... via Queue.Queue objects.  The main thread dumps "work" for it onto the BDM.inputQueue, and it dumps the result to the BDM.outputQueue -- it does not use a callback structure because my computer almost imploded when I attempted Qt/Qapp calls from the BDM thread.

Thanks for getting your hands dirty with this.  I just got back from an extended vacation and don't have a lot of time to deal with this.  If you have some time, do you think you could construct a very simple example worthy of posting in a bug report (or maybe we discover a workaround)?  I'm thinking -- super simple C++ code that does nothing (basically a single main.cpp file), make an importable swig module with it using the "-threads" option, then creating a blank app that only calls getSaveFileName().  I will get to it eventually, if you don't.  But I may not have time until this weekend...

I did some more specific searching for this problem, and I still found nothing.  I suspect it's not a widely triggered bug:  only SWIG+threading+PyQt+OSX.

[LordMord]

Is it normal that i have to run armory with sudo? If i don't i can't see any transactions.

I installed it on arch linux from the AUR.

[etotheipi]

Is it normal that i have to run armory with sudo? If i don't i can't see any transactions.

I installed it on arch linux from the AUR.

No, definitely not normal.  Since you're using Arch Linux, I'll assume you're familiar enough with the FS to understand what I'm about to say:

Armory installation directory:  If you checked out from git, it's the git directory.  If it was installed with a package, probably /usr/share/armory.  This is the directory that holds the source code, and all the .py files that actually execute the app/GUI.  Clearly you need read access to this directory, but it sounds like you do, since it runs without root access.
~/.bitcoin directory:  This is the directory that holds all the data from Bitcoin-Qt, including the blkXXXX.dat files needed by Armory.  But Armory only needs to read the files in this directory, it never writes anything.  Say, if you run Bitcoin-Qt with sudo, then it's possible it is setting permissions on the blkXXXX.dat files that allow only root to read them.  That would be a very good explanation for what you see, though not very likely.  Do you run Bitcoin-Qt with sudo?
~/.armory directory:  This directory needs both read and write access.  This is where all the settings and wallet files are kept.  This directory is also created the first time Armory runs. If you ran Armory the first time with sudo, it is possible this directory was created with root permissions.  This would prevent Armory from doing quite a few things, though I expect Armory would flat out crash if it couldn't write the .armory dir... but weirder things have happened.

Also, please run the latest version:  version 0.84.5 (it's the current head of the "threading" branch).  This version has a lot more auto-detection capability and tells you what is missing (if it can figure it out).  If it does work, it will help narrow this down...

[LordMord]

Is it normal that i have to run armory with sudo? If i don't i can't see any transactions.

I installed it on arch linux from the AUR.

No, definitely not normal.  Since you're using Arch Linux, I'll assume you're familiar enough with the FS to understand what I'm about to say:

Armory installation directory:  If you checked out from git, it's the git directory.  If it was installed with a package, probably /usr/share/armory.  This is the directory that holds the source code, and all the .py files that actually execute the app/GUI.  Clearly you need read access to this directory, but it sounds like you do, since it runs without root access.
~/.bitcoin directory:  This is the directory that holds all the data from Bitcoin-Qt, including the blkXXXX.dat files needed by Armory.  But Armory only needs to read the files in this directory, it never writes anything.  Say, if you run Bitcoin-Qt with sudo, then it's possible it is setting permissions on the blkXXXX.dat files that allow only root to read them.  That would be a very good explanation for what you see, though not very likely.  Do you run Bitcoin-Qt with sudo?
~/.armory directory:  This directory needs both read and write access.  This is where all the settings and wallet files are kept.  This directory is also created the first time Armory runs. If you ran Armory the first time with sudo, it is possible this directory was created with root permissions.  This would prevent Armory from doing quite a few things, though I expect Armory would flat out crash if it couldn't write the .armory dir... but weirder things have happened.

Also, please run the latest version:  version 0.84.5 (it's the current head of the "threading" branch).  This version has a lot more auto-detection capability and tells you what is missing (if it can figure it out).  If it does work, it will help narrow this down...

Thanks for the answer found the problem it is on my side don't worry about it.

[prezbo]

I've been using armory for a short while now and I'm very impressed by how far it has come. One thing bothers me though, armory won't update blockcount, even when blockchain is synchronized in bitcoinqt. For every new block I have to restart armory (and wait forever for it to scan the blockchain again). Is this a bug or is it like this by design?