Topic: Armory - Discussion Thread - page 113. (Read 521829 times)

Well, it does work great if you have 6-8 GB of RAM.  Not so well if you don't.  There's not really an in-between.

I'm making progress on the update so it should use far less than 1 GB when I'm done.  In fact, I'd be surprised if it used required even close to that.  But I won't know for sure until I'm done.

requiring 8GB Ram is not "works great"
(and the main client not disclosing it requires 10+GB of HD is not cool either, but that's a different team).

And machines with less than 8 GB RAM.  But that is not the client going downhill, it's the size of the blockchain going steeply uphill

It works great. It is only 32bit windows which has given up the ghost.

Loved the wallet before it went downhill, hope to use again when it's back up and running.

Eagerly awaiting the new version. I cringe every time I hear about somebody losing coins because they are using a client that doesn't support deterministic and/or offline wallets, but I can't yet recommend the current version of Armory to non-experts.

One of my short-term-sacrifice-for-long-term-gains activities has been making sure that the database design is completely flexible in order to accommodate a future SPV mode as well as super-node mode as well (for doing arbitrary address/UTXO-tree lookup).  It won't be trivial to do either update, but I made sure to break out the data structures in a way that may result in the DB engine not requiring any updates to accommodate it -- only the way the outer application makes calls to the DB engine (of course there's a 0% chance that it will work that cleanly, but we can always dream )

That's part of the reason this upgrade took so long -- I didn't want to rush through it and require another major overhaul (like this one) to do those kinds of upgrades. 

Thanks for the update!

I just read this thread:
Block chain size/storage and slow downloads for new users

Are there any plans for an SPV mode in Armory?

Making tons of progress on it.  As I keep saying in this thread and others:  I had some critical priorities crop up, but I have still had a bit of time to work on it, and I think I'm getting closer to something that works.  I keep trying to make estimates of when I'll have it, but my estimates have been pretty much useless due to the scope of changes and unpredictability of other things. 

So I will not put a timeline on it.   But what I will say what is done:  the DB foundation appears to be functional and working.   I have also incorporated google-test into the project and written 5,000+ lines of testing code (a lot of it is for the pre-existing codebase that didn't have proper automated unit-tests, but at least half of it is for the new DB utilities).  I'm juggling some of the fine details of hooking up the new DB engine to the BlockUtils.cpp which is where all the magic happens -- for instance I didn't anticipate I would have to switch to a headers-first pipeline due to the way I chose to key the databases (all blocks are stored by their height, which means I can't put them into the DB until I know their height).  Headers-first is probably better anyway, but it does require rewriting some solid code that I had hoped to leave in place a bit longer and not complicate this upgrade.  Oh well.

I already have a solid re-org unit test which is basically the ultimate did-I-get-it-right test.  That test took me like a week to create, 18 months ago.  Now that it's done, I don't have to spend any more time on it than just running it through.

Unfortunately, I may have made an extremely inefficient design decision, that will have to be fixed before any official releases go out (though it won't take me more than a day or two to fix it).  Mainly the way I store address histories is going to choke on the SatoshiDice addresses.  It should still work, it will just be super slow when new blocks are received.  I'll get it working without fixing that, and with luck it will just work fine, anyway.  If not, I'll have a unit-test-passing version that can be slowly morphed into the optimized version.  I like having solid unit-tests...

By the way, if you do any C++ development, I can't speak highly enough about googletest.  It's remarkably easy to use, yet has an extraordinary amount of flexibility if you feel it necessary to get creative/advanced. 

Just wanted to check in on progress -- I am gladly waiting for the upgrade and glad to see you are taking the time to improve the foundation.

Are you getting enough support financially? I would be glad to kick in a meager amount to support the cause.

0.88.1 Works on my Windows 7 system , its still Ram intensive though.

Is there a new client that works?

Excellent client .

Congrats

My current process is in .bitcoin/blocks:
mv blk00001.dat blk00001.dat.tmp

This then means Armory only loads the 1st 128meg block which takes seconds.

I then look in the chain for some test txs before block 119k and use those to test my code.

Only when I think it is good do I then run on the full chain by renaming the file back!

Feels a bit 1990's but it is working!

Thanks for speedy reply....

Problem is that the bets specific "form" i.e. are to specific addresses, win/lose is dependent on the hash etc....

The site is provably fair, but I want to prove every bet, and the total P&L of the site.

So using testnet would mean I have to create loads of fake bets etc...


If I just delete all but the last few blk files I assume it is going to complain about there being no genesis block?
If so can I comment out some bit of code to fool it whilst I am testing?

Thanks

Hmm... good question.  I never bothered putting in something like that, because I always just used testnet if I needed to operate on less data.  I suppose you could create a temporary directory with just the first couple blk files and point your script to that using --satoshi-datadir, and then disable it when you're ready for the full blockchain.

Aww the memories of falling in love with php, except reloads were instant.

I am using the example in extra/sample_armory_code.py to analyse a betting websites transactions much like the satoshidice example in there.

I think the job is simple. Only issue I have is that each time I run the code to debug what I have coded I have to wait 5mins for it to rescan the whole blockchain. Is there anyway I can when testing my code get it to just read one blk file or a few blocks?

It is just so every time there is a minor typo in my code I do not have to wait 5 mins to see if I have fixed it. It is driving me crazy!

Thanks

Congrats!