(edit) : FIXED - I reinstall Armory again and now its fine... (admin delete this post if needed)

I Cant start Armory because of some Runtime Error ! Actualy it starts, syncs with network, downloads new blocks, and then starts to scan for transaction history.When it reach 71% scan progress or 1.98Gb of RAM then I get C++ Runtime Error.

I installed Bitcoin-Qt 0.8.4 and sync it with blockchain database.All installatio was default. default path for BTC-Qt and for Blockchain database.

I downloaded Armory 0.88.1-beta x64https://code.google.com/p/bitcoinarmory/downloads/detail?name=armory_0.88.1-beta_win64.msi&can=2&q=.But when I start installation, setup program wants to install it to "c:\Program Files (x86)\Armory", why there?Isnt that x64 version, so it mast go to Program files not in program files (x86)

Unfortunately, there was just too many problems with super-node Armory. LevelDB has been extremely inconsistent in keeping up with the stress of constantly updating address ledgers. On slower systems, I observed random "missing tx" messages and seg faults on one run, then I would re-run on the same data and it would cruise through that part. I cannot attest that my code was bug-less (though, there's like 2,000 lines of unit-testing code to test the new database stuff, including re-orgs). But it appears that I cannot worry about code bugs if it's not going to work even without those bugs.

Super-node Armory is likely to be put on hold for a while. Now, I know that sounds like it's going to be a serious disruption to my progress...

The good news:

All of the modularization I have put into Armory just paid off. Tremendously! In 8 hours I was able to swap out the super-node DB operations with something that resembles the previous version, but without super-node capability. Super-node code would process all the headers, find the longest chain, write out all the raw blocks to disk, apply all the blocks (updated addr histories, mark TxOuts spent/unspent, etc), and then grab all the transactions relevant your wallets and scan them.

Now, it skips the "apply blocks" section entirely, and does a blockchain scan on the raw blocks in the DB to find all the transactions relevant to your wallets. It injects them into the wallet and everything operates the same! In those 8 hours, I now have a mostly-working version of Armory that rescans the blockchain on every load, but has the database backing so that it uses dramatically less RAM. Also, it will be trivial to save the registered tx data between loads, now, so rescanning will only be necessary on the first load or import/restore wallets. When I originally tried to do this, there was too many subtle issues with where the transactions were on disk, swapping blkfiles/homedirs, etc. With Armory managing its own database, it can do this reliably now!

I am in the process of reverting many of the skip-this-operation-because-not-needed-for-super-node operations to the old way, so that it still pops up with all the original warnings about needing rescans etc. This should be done today, meaning it only cost me two days to do a major operational shift!

If you want to play on the new branch, it has been renamed rrld_planB. It is a fork of ramreduceleveldb, which I wanted to keep around for when it's time to revisit super-node Armory. Still some UI feedback issues, and doesn't handle being interrupted on the initial build, but it is usable on Linux for simple use (and testing!).

Unfortunately, there was just too many problems with super-node Armory. LevelDB has been extremely inconsistent in keeping up with the stress of constantly updating address ledgers. On slower systems, I observed random "missing tx" messages and seg faults on one run, then I would re-run on the same data and it would cruise through that part. I cannot attest that my code was bug-less (though, there's like 2,000 lines of unit-testing code to test the new database stuff, including re-orgs). But it appears that I cannot worry about code bugs if it's not going to work even without those bugs.

Super-node Armory is likely to be put on hold for a while. Now, I know that sounds like it's going to be a serious disruption to my progress...

The good news:

All of the modularization I have put into Armory just paid off. Tremendously! In 8 hours I was able to swap out the super-node DB operations with something that resembles the previous version, but without super-node capability. Super-node code would process all the headers, find the longest chain, write out all the raw blocks to disk, apply all the blocks (updated addr histories, mark TxOuts spent/unspent, etc), and then grab all the transactions relevant your wallets and scan them.

Now, it skips the "apply blocks" section entirely, and does a blockchain scan on the raw blocks in the DB to find all the transactions relevant to your wallets. It injects them into the wallet and everything operates the same! In those 8 hours, I now have a mostly-working version of Armory that rescans the blockchain on every load, but has the database backing so that it uses dramatically less RAM. Also, it will be trivial to save the registered tx data between loads, now, so rescanning will only be necessary on the first load or import/restore wallets. When I originally tried to do this, there was too many subtle issues with where the transactions were on disk, swapping blkfiles/homedirs, etc. With Armory managing its own database, it can do this reliably now!

I am in the process of reverting many of the skip-this-operation-because-not-needed-for-super-node operations to the old way, so that it still pops up with all the original warnings about needing rescans etc. This should be done today, meaning it only cost me two days to do a major operational shift!

If you want to play on the new branch, it has been renamed rrld_planB. It is a fork of ramreduceleveldb, which I wanted to keep around for when it's time to revisit super-node Armory. Still some UI feedback issues, and doesn't handle being interrupted on the initial build, but it is usable on Linux for simple use (and testing!).

Stay tuned!

Wow, this sounds like great progress. I totally feel like my Armory donation was money well spent.

Trying to access my online portion of my offline wallet, and its taking quite some time to load. I am on OSx and have 8gb of ram, but armory is now stuck at using 2.47gb of Real Memory and 4.96 Virtual Mem and using 100% CPU of 1 core. IT is stuck at 15 seconds.

Is there anything that can be done here to make this usable ?

Thank you

kosta

I have a similar setup (OSX, 8 GB ram) and have no problems. It takes forever to load (5 min or so), and once loaded it occationally hangs for 10-20 sec at a time.

If you start it in the terminal, you can see the output while it reads the block files. That shows progress :-)

I did a sendmany transaction recently and added individual comments. Before, I never added comments in sendmany txs, because I was pretty sure it wouldn't be displayed usefully, but I was proven wrong. Armory separates comments in the transaction and even adds in a rounded amount next to each comment based on how much was sent to the address the comment's attached to. Surprises me every day.

I did a sendmany transaction recently and added individual comments. Before, I never added comments in sendmany txs, because I was pretty sure it wouldn't be displayed usefully, but I was proven wrong. Armory separates comments in the transaction and even adds in a rounded amount next to each comment based on how much was sent to the address the comment's attached to. Surprises me every day.

No detail is too small for me Glad to see people appreciating the time I put into those details!

Still a 2 BTC bounty available! (I'm looking in goatpig's direction).

I've determined that I don't care what version of MSVS is used for compiling the C++ side of Armory. I've been meaning to upgrade to MSVS 2010 or 2012 anyway... if someone gives me a solution using one of those, you get the 2 BTC. The "checkout" criteria for the bounty is that the project must successfully compile leveldb (or I must be able to do it myself), and then it must link properly to the code in the ramreduceleveldb branch. And of course, some documentation on how it was done...

The reason I haven't upgraded to MSVS 2010 or 2012 is because there's a bit of pain doing so (like MSVS 2010 now supports the equiv of <cstdint> in Linux, so it complains about my redefinitions). Whatever, if someone can take a shot at it, or at least give me a partial solution, you get part of the bounty!

I've determined that I don't care what version of MSVS is used for compiling the C++ side of Armory. I've been meaning to upgrade to MSVS 2010 or 2012 anyway... if someone gives me a solution using one of those, you get the 2 BTC. The "checkout" criteria for the bounty is that the project must successfully compile leveldb (or I must be able to do it myself), and then it must link properly to the code in the ramreduceleveldb branch. And of course, some documentation on how it was done...

The reason I haven't upgraded to MSVS 2010 or 2012 is because there's a bit of pain doing so (like MSVS 2010 now supports the equiv of <cstdint> in Linux, so it complains about my redefinitions). Whatever, if someone can take a shot at it, or at least give me a partial solution, you get part of the bounty!

I'll give it a look but I won't be around from Friday to Sunday night, so don't expect speedy delivery =P

I'll attempt to compile the whole project on vc11 express for the following reasons: express is free to download, and free to use to deploy open source projects, makes sense so far, and it's MS dedicated compiler. On top of that, vc11 adds some of the C11 improvements, including atomics, and leveldb relies on std::atomics to compile. This is partly why it's such a pain to compile it with vc10 and vc9, as you have to use WinAPI's Interlocked functions to support atomicity. That and setting up the environment >_>

In case you're having trouble with warnings from a version of msvc to another, consider defining _CRT_SECURE_NO_WARNINGS

(2) How long does it take to build the DB? NOTE: there's actually two steps to building the DB: one is writing the raw blocks to the DB, the other is actually walking through those blocks and updating the DB with spentness info, and building histories for each address. The system currently does not give you any real indication that the first step is happening (though it should on the command line, if you run with --debug). Until I fix that, it may not be obvious that anything is happening... and that first step usually takes like 45 min!

(3) How much space does the new .armory/databases directory use? I've seen widely different results, and I think it has to do with seemingly-random times that leveldb decides to do DB compactions. My first test left me with an 18 GB databases dir. A more recent had it at 25 GB. I'm wondering how widely this varies.

Whoa, how'd you do that? Isn't that the ramreduceleveldb branch? 2.7 hours is almost twice as fast as my system did it! Do you have an SSD? I ask especially because 14 GB seems too low. Did you scan the whole blockchain up to like 257k blocks?

I have successfully compiled the ramreduceleveldb branch on vc11 x86 (msvs2012 express). The method outlined can be reproduced on vc9/10 (msvs 2008/2010) with no extra changes to either projects (leveldbwin and armoryengine_msvs2005). Keep in mind that to since the compile relies on a library compilation of leveldbwin, you need to compile armory with the same compiler as you used for leveldb. (Don't go around building leveldb with vc9 and then linking it to an armory project built with vc11)

Note: this is a compile of armoryengine_msvs2005 project only, not the SWIG to python part, which is trivial in this case from what I understand of the project (i don't know squat about python and swig). The compile is untested, I simply went as far as yielding a ArmoryEngine_MSVS2005.dll (no main declared in this branch)

1) Pick the project of your liking in the build folder (msvc9 or msvc10). I used msvc10 and converted the project to msvc11 since this is my compiler.

1.a) To compile you need ATL. If you're using an express version of msvc, you'll have to install WinDDK 7.1 (Driver Development Kit): http://www.microsoft.com/en-us/download/details.aspx?id=11800. Make sure you grab 7.1 and not 8.0 or WinSDK as those do not support ATL anymore. Skip this step if you have a pay version of msvs.

2) In the configuration manager, pick Release (for the static lib compilation). Don't bother compiling test, you don't need it. I used snappy for compilation, so no defines to drop at this point.

3) Right click each project (leveldb and snappy), go to "Config properties -> C/C++ -> Code generation". Make sure Runtime Library is set as Multi Threader (/MT). This defines whether the C librairies used to compile are statically or dynamically linked. My understanding of this project is that you'd rather not distribute msvc runtime binaries so stick to static compile.

4) Rebuild the project, pick up leveldb.lib in ./_exports/Release and shove it where you want to have it for the armory compile (either make a new folder for it or directly link to it from the project)

Step #2: Armory

Here is the list of all the modifications I did to the code and the project to get it to compile:

# added compiler directives in log.h to not overload logstream and children class >> operator with both size_t and unsigned int arguments in msvc. They're considered the same and the compiler willcomplain about method redefinition.

# added leveldb include folder to msvc project

# excluded FileDataPtr and BlockUtilsTest from msvc project (not in the branch but in the msvc project)

# added leveldb_wrapper.cpp to project

# added StoreBlockObj.cpp to project

# NowTimeInt wasn't defined for win32 (log.h). Defined it by copying the non win32 code and including<time.h>. This version of time returns the amount of seconds since the unix epoch on my machine(win7 x64 sp1). It's safe to assume all version of windows will behave in such fashion as this library iswrapped around a WinAPI call on Windows.

# added new folder to hold static leveldb.lib

# added leveldb.lib to addional dependencies

# changed project from .exe to .dll as there is no main defined (probably cause there is no test code)

# got rid of build events for armoryengine_msvs2005.sln

# make sure you're using Multi Threaded (/MT) for the runtime library.

# rebuild only the armoryengine_msvs2005 project so that it doesn't trigger errors with the custom build events failing to grab guardian or py2exe.

voila

Note: I first tried to dynamically link leveldb to armory, but it failed to export leveldb::DestroyDB properly. The issue disappeared with the static link so I stuck to that for now. On top of that leveldbwin has no x64 build setup, so I'll consider making my own compile of leveldb to allow for dynamic linking and x64 releases.

There are about 100 warnings, 90% of them are related to possible data loss due to assignment without type casting. The rest seems to be msvc complaining about unsafe routines. Both cases are irrelevant.

P.S. - This is still the Armory discussion thread, I just changed the topic temporarily to draw attention to the big news!

@goatpig -- thanks! you may yet get the bounty. But I'll be back to you later after the media storm subsides

I doubt many people deserve it more, congrats!

What are the ideas for developing Armory as a business btw? Will everything remain open source? What are you guys planning on charging for? (I'm kinda hoping it'll be customer specific customizations ).