Topic: Armory - Discussion Thread - page 142. (Read 521749 times)

um, i haven't been following this thread for a while, but here i'll dump my current wish list:

• ability to vertically stretch the list of Available Wallets.
• ability to sort available wallets by Name, Security, or Balance (and have Armory actually remember that setting)
• ability to add a custom Filter to show transactions for a personally chosen group of wallets
• ability to Remove Imported Addresses in bulk
• ordinal numbers in first column of 'Addresses in Wallet' list
• ability to set permanent default to 'Multiple Keys' in Private Key Import
• ability to set permanent default to 'Import these addresses...' in Private Key Import
• option to always or never rescan after import, so it doesn't prompt every time
• option to keep Use wallet encryption unchecked by default on wallet creation dialogue
• get rid of header text and string "   (Imported)" when exporting list of addresses.
• handle the blockchain itself, without relying on qt
• option to only use imported or specific addresses when receiving change
• automatically calculate for me the maximum send amount for a given fee amount (instead of making me play a tedious game of higher/lower until it gives the confirmation screen)

and of course saved the best for last...

• ability to handle a wallet with 10,000 imported addresses on an i7 + 8gb RAM without 'Not Responding' for 10 minutes on every click

thanks for reading!

There is no search function.  Sorry.  I haven't yet figured out how display search results without doing a lot of work.  It's on my todo list.  I assume that sorting the column doesn't help? 

Am I really missing a search function for comments?

@etotheipi
On your site the instruction to make a offline wallet might need some addtional instructions.
In: Using an offline wallet in Armory -> 4. Double click on the wallet and click on “Create Watching-Only Copy”
It seems to me this is only possible in the Advanced and Expert mode (not in Standard).

Can someone please do me a favor and update How to set up a secure offline savings wallet wiki page with some reference to Armory.  There's a couple other linked pages, there too.  It's depressing to see not even a hint that other applications exist that make this so much easier.  It would be even better if there was a second half of the page that explained how to do it with Armory (and screenshots?), but that's not totally necessary...

There's a lot of pages there for which it would be wholly appropriate to at least have a reference to Armory (and probably Electrum, too), even it only mentions it as an afterthought. 

Here's some links that can be used to update the wiki:

http://bitcoinarmory.com/
http://bitcoinarmory.com/index.php/using-offline-wallets-in-armory
http://bitcoinarmory.com/index.php/armory-quick-start-guide
http://bitcoinarmory.com/index.php/get-armory

The second part that you quoted of me answered your first part -- having it scan completely in the background without stalling the BDM is what I will do.  It will require a bit of work, because right now "scanning" involves updating the BDM as it is scanning, which is why it must go offline to avoid race conditions.  But I can execute the scan in a ghost thread, then extract just the collected data and inject it into TheBDM when it's done.  The injection would take a fraction of a second, so it would hardly be noticeable. 

The downside is that I need to implement more interface options, such is "isScanning", "queuedAddresses", etc.  It's doable and necessary -- it's just not trivial.

I know how important 24/7 stability is.  And I'm almost there -- I currently, already, run Armory for 5+ days at a time, in both Windows and Linux.  The last couple issues are tough to track because of how infrequent they are, but I am fairly certain they have to do with timing issues related to clashing with Bitcoin-Qt in the blkfiles.  If I simply got everything from Bitcoin-Qt via sockets and managed my own blockchain files, those would go away, by definition, but I think I will be fixing them, as-is, right now.

Btw, I only use Bitcoin-Qt as a regular peer -- no JSON-RPC -- but it is a trusted peer (critical!).  It is essentially a filter/gateway between Armory and the rest of the network, endowing Armory users with the network security of Bitcoin-Qt/bitcoind, filtering out invalid tx and blocks, etc.  Armory still organizes the headers, calculates the longest chain, invalidates orphans, etc.  But it relies on bitcoind/-qt for the nitty-gritty verification activities, and DoS protection, etc.

Is it a option to do the rescan in a (parallel) external process? If this process returns the input, to the under laying database or memory, it takes a time span to obtain the data but the armoryd processes can keep running?
Or a temporary armoryd for the rescan of the specific new wallet. Gathered additional info (addresses and transactions for this wallet) put into the database/memory and the temporary armoryd exits.
I'm very n00b with this kind of processes, but I do hope this kind of solution is possible.
I still prefer a stable and 24/7 daemon. The add/rescan process is necessary, can take some time, but should not stall any daemon/JSON processes.


I cannot understand exactly what you are trying to say, but it seem to me this is a big and crucial decision for the way Armory functions within the bitcoin (software) environment.
I do remember your primary reason to stick with the original bitcoin client are the network functions. If you maintain your own blockdata, can you still use the networkfunctions?
Scanning the blockdata to be able to add a wallet (concerning historical data) is a lot different than to add data to the (own) blockdata yourself (concerning new data).

On the other hand, maybe the way the original bitcoin client adds data is not difficult at all?

Thanks

Yeah, I definitely want to have the add/remove/create/rescanwallet functions.  Armory is capable of doing it, though adding a wallet will usually induce a rescan which could make your make your JSON interface useless for a couple minutes.  Even though I have multithreading already, I realized it shouldn't be too difficult to do a raw rescan without TheBDM at all, meaning it could happen without putting Armory into offline mode, and then it would simply injected the registered transactions it finds when it's done (it would be a bit of work modify it like this, but it would work).

Unfortunately, 24/7 is a stretch at the minute:  I am experiencing seg faults when Bitcoin-Qt/bitcoind splits block files, even though I have a unit-test that tests exactly that event!  I'm going to have to dig into this again.

On the other hand, this all goes away when I do the full/final RAM reduction and finally have Armory maintaining its own blockdata.  Once I have this, there is no more clashing with Bitcoin-Qt, and a whole host of problems will go away.  I'm very temped to jump back to this before the new wallets, because of the usability improvement in addition to al lthese stupid problems going away.



N.Z.  I just pushed a signed tag into the git repo.  You can checkout the tag, v0.87.2-beta, and verify it using "git tag -v v0.87.2-beta". 

I will not, without change there is no progress!


For a daemon it is a good thing if the functions "addwallet(filename.wallet)", "removewallet(wallet name or file name)" and "rescanwallets" are available. If you want the daemon run for 24/7 a restart (to load a new wallet or exclude one) is not preferred.
Also the memory requirements is a attention. I do not know how the memory requirement with ArmoryQT for a additional wallet works, but I expect it is not 1.5Gb for each wallet.


Yes you did, I will happy to do so and thanks!

0.87 tag in git is signed, but I never actually signed any tar balls or anything.   I will make sure to go sign 0.87.2 tonight since I forgot.  Use "git tag -v v0.87"

I know the website is down-my webhost told me it should only be another day... They just moved their entire operation.

etotheipi, could you upload latest signed archive with source tarball to your site (or amazon)?

The JSON-RPC interface is still a work in progress.  I haven't really ironed out things like this yet.  But I can give you some workarounds, as long as you promise not be upset when it changes later

Specifically, I will be making armoryd.py multi-wallet, just like ArmoryQt is.  It will load all wallets in a given directory, and you will be able to "selectwallet", "getwalletinfo", "sendfromwallet", etc.   Until then, I guess you'll just have to run multiple copies.

So first thing to do is that armoryd.py detects itself via the --rpcport option.  I forget the default but you should be able to start more instances by changing that value.  If you run armoryd.py on the same port as another one that's already open, it switches from "start-server" mode to "pass-CLI-arguments-to-existing-server" mode.  It reads the /home/user/.armory/armoryd.conf file for authentication info, opens a connection with it through the port, then it passes the command line arguments to it as a native JSON-RPC call.  It receives the response, prints it out, and disconnects.  After all... if they could somehow listen on the same port, how would PHP know which one it was talking to? 

I think the last part is answered by my multi-wallet answer.  If you have recommendations for how to accommodate multi-wallet armoryd that more intelligently, I'm happy to entertain it!

Testing the armoryd branch...and armoryd... 

Setting up a watch-only wallet and make a php jsonrpc call works!
Now testing the process of getting unsigned transactions.

I have some troubles to add a additional watch-only wallet to armoryd.
I get this error after the notification 'Another instance of armoryd.py is already runnning!':

It looks like I have to put in some extra arguments to make a second armoryd work with another watch-only.
I can't find what the arguments should be. (has it something to do with: AuthServiceProxy  def __call__(self, *args) ??)
Also I suspect armoryd does not except more arguments (your code states: # The only argument that armoryd.py takes is the wallet to serve)

Please let me know where to find some clues to get a second watch-only armoryd running.
I'm also wondering how the jsonrpc call is made. Is it to a different RPC_PORT? If not, how do I make a jsonrpc call to a specific wallet? If so, how do I know the rpc_port's of all wallets running?

I'm also wondering if it is possible to make use of the authentication of the (proxy) service to identify a wallet/user from the (php) jsonrpc. (otherwise I have to make a authentication for a wallet/user before the (php) jsonrpc call's could be done)

Ahh right.  I received notification that my webhost was ... moving.  They will be down part of today.   If you don't need directions, you can download the latest directly from the googlecode hosting (this is what is linked to from the bitcoinarmory.com website, anyway):

bitcoinarmory.googlecode.com downloads page

(If you're in linux, just checkout the "testing" branch)

Speaking of that:  Here is 0.87.2 which has a couple more stability fixes in it.  It turns out that I induced some problems with reorg handling a while ago, and had not rerun the reorg-unittest since then.  Now I have, and it should be smooth sailing through reorgs in version 0.87.2:

Testing version 0.87.2-testing for Windows 64-bit
Testing version 0.87.2-testing for Windows 32- and 64-bit
Testing version 0.87.2-testing signed SHA256 hashes of installers

As with 0.87.1:  the updates are tiny bugfixes with big stability impact.  Therefore, I believe that 0.87.1 and 0.87.2 are as stable as a full release, and hence I have provided signatures with them so users can feel comfortable with them.

---

Yes, I am completely retarded when it comes to bash/shell scripting.  I wish everything could be python.  I'll try what you suggested.  Or maybe you can help me by figuring out how to detect that dynamic filename there...

---

I've wanted to add a few options to that dialog for a while, but it never seemed like a high priority.  I need to look at what other import formats other services use, and perhaps add some site-specific list-formatting choices.  For now, I have simply written things out to optimize having to manually type it in.  But of course, I know many will be copy-pasting so I should accommodate that, too.

---

Interesting... maybe there just haven't been any real users on RH before you?  I definitely have not (or do not remember) having to deviate from the format that is there for any previous complaints.  I will have to investigate further how to accommodate this (I definitely need a smarter makefile)

I've decided to give armory a go (most of the rest of the world spells it armoury, so my spell checker is going nuts right now ) and the site's not loading

You have to have some knowledge of what type of shell it is dropping into ... most POSIX-like shells will only accept variables inside curly brackets, e.g. ${VAR}

I have a suggestion: in "Backup Individual Keys" and "View Address Keys", please allow the user to choose whether the keys are delimited by spaces. Keys with spaces are not C&P friendly

SUCCESS!!!!   

Okay, normally, this is the time I move on with my life, but I really think it would be a good idea to share all of the steps I had to take, so that etothepi can put these instructions on the BitcoinArmory website for the NEXT person who runs Fedora and wants to install Bitcoin Armory. There are a lot of Fedora users out there and it would be a shame for them to turn away from using Bitcoin Armory because they couldn't figure out how to get it installed, or perhaps they saw there weren't installation instructions and didn't even try. So, here's everything I did in order to get Bitcoin Armory installed. I hope you'll put this up.

In addition to all of the packages you list to install, also include:

gcc-c++
python-devel
PyQt4-devel

Then have them edit cppForSwig/Makefile and

replace line 26 with:

26    STATICPYTHON +=   "/usr/lib64/libpython2.7.so.1.0"

and line 29 with:

29    STATICPYTHON +=   "$(DEPSDIR)/lib64/libpython2.7.so.1.0"

making sure to put either 64 or 32 depending on the architecture.

Then it should work great! And you've just increased the number of users that can and will use Bitcoin Armory.

Thanks for all the help guys!

Okay, the locate helped. I apologize for my noobness.

Here's what I've got:


So, I edited my Makefile to:


and still got: