My OS? Windows 7 Ultimate 64-bit.
I was hoping for OSX. I'll look into it. |
|
|
|
Seems to have solved my issue of needing to dump and reload the entire blockchain every time I loaded Armory. Updated, opened it, and within 10 seconds was back up and running.
My only complaint is an aesthetic one, the text in the bottom right corner (the "Offline" and "Connected (Number of Blocks)") seems to have been pushed down and to the right a little. It's barely just staying on my screen.
OS? |
|
|
|
Interesting, I didn't expect to react so well to so little RAM
83% now and 14 hours for the remaining 17% The deeper you get in the more expensive each % gets, because all this data gets really fragmented within the one big DB file. Next version should help a lot with that. If I had one tip to give you, it would be to close Armory when it's done scanning and create a copy of the DB folder. This way if it gets corrupted you can start right off of that one. Again, next version will be resilient to the kind of corruption this version suffers from. |
|
|
|
|
Interesting, I didn't expect to react so well to so little RAM
|
|
|
|
What's your wallet address chain length? How does it compare to the one on the full wallet?
I'm not sure what a wallet address chain length is, but my armory wallet is fully synched with the blockchain. A watch only version of my wallet sees all my wallet's transactions, including ones made after I upgraded to 0.93, but my full wallet doesn't. I bring that up because AFAIK each wallet is using the same blockchain data. Each wallet may not be extended to the same address chain length. Pick expert in the User menu then go to your wallet property dialogs and click the figure next to the "Addresses Used" line. |
|
|
|
|
I dont expect that will be enough to be significant.
|
|
|
|
|
What's your wallet address chain length? How does it compare to the one on the full wallet?
|
|
|
|
I'm starting in supernode mode with a virtual machine with 4GB Ram and quad-core CPU. It took about 20 hours and it's still in 51% of "building databases". It says it will take 1.5day to complete. Is this speed normal?
SSD? With 4GB of RAM, in a VM, I'm not too surprised. I takes me ~4h at this blockchain size with 5820k, 32GB of RAM and SSD raid. I'm working on some changes that should speed that thing considerably (and mostly make it more stable). |
|
|
|
|
Just pushed the missing txio fix. It will attempt to repair the DB but I don't think I can guarantee proper balance after the repair. It should prevent the issue from reoccurring on top of a clean DB, but again I'm not sure. I'm getting closer to finishing the DB changes so I'm trying to focus on that instead of coming up with a large fix for the current state of supernode.
|
|
|
|
I have some feature requests:
I'd like for Armory's coin control feature to display choices based on inputs rather than addresses, and I'd like for it to show more in-depth information regarding inputs, such as priority, source address, TX hash of the origin, and maybe the same thing when sending bitcoins, perhaps a display for the size and priority of the transaction for expert users.
That has been on our list for a time, should be done in the coming months, I hope. |
|
|
|
|
TimS: I should have a fix for the missing txio issue sometimes today.
|
|
|
|
|
Turn off auto bitcoind and just manage BitcoinQt manually then.
|
|
|
|
What I meant was I assume to import new keys after the initial import during armory setup, that you have to manually import via a menu somewhere where as I was asking about telling armory to check for new keys from the QT client and import if found. So everything otherwise would remain automatic with new keys needing to be imported.
Nothing like that sorry. All key imports are manual. |
|
|
|
I'll have to read up on auto bitcoind, I've seen it referenced a few times. As for the import thing, could armory be told to "look" for changes and import at x intervals ?
I'm not sure what you mean by that. You will get full up-to-date transaction history for any private key you import into an Armory wallet, past, present and future. If you create new private keys in a wallet from another client, you will have to import these new keys into your Armory wallet to get their history. |
|
|
|
Sounds like a good plan.
I don't currently use SDM anyway, just trying to help clear your workload so you can develop the features I'm more interested in (reduced DB, input level coin control, BIP32 based wallet format)
And I'm grateful for that. BIP32 is etotheipi's task, that's not dependent on anything I do =P. |
|
|
|
Just to update, still getting problems with RPC connection and BDM errors using SDM mode on 93.0.82. The BDM errors are reduced to a rare event, but still occasionally happen (1 so far since testing .82).
I'm fairly sure all/most of these BDM are false positives, as the BDM reports zero problems on subsequent runs whether you re-build Db or not. It'd be good to hear ATI's opinion on that. I'm fairly certain that the old Armory Db would fail deterministically once an error was detected.
I think we're not gonna touch the RPC comm layer any furter for now. It needs to be reworked to a certain extend and that's too disruptive for the class of fixes we are aiming to ship in this version. I personally think the remaining RPC errors aren't deal breakers, and that our users will have the good grace to endure them until I come up with a rework of that 2 years old code (instead of band aid patches here and there, which haven't played up to expectation). As for the BDM errors, I dialed down the error message because I expect all left over issues are false positives. The BDM error just shuts down Armory now (rebuild and rescan isn't checked by default in the error message), and the next start will just repair the issue (if there is one indeed) until I get to the bottom of it. I did push a tiny but significant change a couple days ago which should fix some latent BDM errors. |
|
|
|
Hello,
Armory's CPU usage remains high even in this version, spiking up to 25% every 2-3 seconds even in prolonged idle state.
Yes we are aware of that, this fix is rather complicated so we'll ship it with the next version of DB changes. |
|
|
|
Ahh, well here's hoping we get 32bit back. Would hate to downgrade QT to use armory on my laptop.
We said we'll deliver next version 1) Can I use my own rpc user / pass with armory or does it have to be those supplied when installing armory ?
Not if you use auto bitcoind. With BitcoinQt you can set your own RPC password 2) If when setting up armory, you import an existing wallet from the QT client. If something RPC's in to the node and modifies the wallet by making new ones with labels etc. Since during Armory setup you requested to import the existing wallet. Do changes made to the wallet via RPC continue to import over ?
No, Armory and Core wallets are completely different. You can't import Core wallets into Armory as is, you have to import the private keys, which will become part of the Armory wallet. New private keys created in the Core wallet will be unknown to Armory until you import these too. |
|
|
|
|
Show Posts
