bitpop
Legendary
Offline
Activity: 2912
Merit: 1060
|
|
July 02, 2013, 06:00:46 AM |
|
Newest version gives rapid disconnected message even though it syncs. Only restarting bitcoind fixes this. Bitcoind should be stateless. Why would it need a restart?
PS I dont mind the memory. I have 32gb that are usually wasting away.
|
|
|
|
|
|
|
TalkImg was created especially for hosting images on bitcointalk.org: try it next time you want to post an image
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
chrisrico
|
|
July 02, 2013, 06:27:59 PM |
|
Having problems sending anything without crash, from recent posts I'm guessing it is just a memory issue. 4GB Ram x86 laptop.
What is the easiest way to move out of Armory without sending coins using it?
Start in offline mode, export your private keys, import into another client. Keep in mind that you lose the deterministic nature of Armory's wallet when you do this.
|
|
|
|
|
bitpop
Legendary
Offline
Activity: 2912
Merit: 1060
|
|
July 03, 2013, 10:13:24 PM |
|
Congrats!
|
|
|
|
nibor
|
|
July 03, 2013, 10:14:24 PM |
|
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
|
|
|
|
bitpop
Legendary
Offline
Activity: 2912
Merit: 1060
|
|
July 03, 2013, 10:15:58 PM |
|
Aww the memories of falling in love with php, except reloads were instant.
|
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
July 03, 2013, 10:16:41 PM |
|
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
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.
|
|
|
|
nibor
|
|
July 03, 2013, 10:22:52 PM |
|
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
|
|
|
|
nibor
|
|
July 03, 2013, 10:58:27 PM |
|
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!
|
|
|
|
superresistant
Legendary
Offline
Activity: 2128
Merit: 1120
|
|
July 08, 2013, 10:24:09 AM |
|
|
|
|
|
Polyatomic
|
|
July 21, 2013, 12:56:07 PM |
|
Excellent client .
|
|
|
|
MoneypakTrader.com
Sr. Member
Offline
Activity: 472
Merit: 250
Never spend your money before you have it.
|
|
July 21, 2013, 06:03:47 PM |
|
Excellent client .
Is there a new client that works?
|
|
|
|
Polyatomic
|
|
July 22, 2013, 07:10:34 AM |
|
Excellent client .
Is there a new client that works? 0.88.1 Works on my Windows 7 system , its still Ram intensive though.
|
|
|
|
jimbursch
|
|
July 22, 2013, 07:53:53 PM |
|
Just a quick comment about progress: No, it's not done yet. But I am finally getting some time to do it. And I'm doing it... slowly.
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.
|
MyMindshare -- a commercial messaging system -- check it out at *Link Removed*
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
July 22, 2013, 08:17:07 PM |
|
Just a quick comment about progress: No, it's not done yet. But I am finally getting some time to do it. And I'm doing it... slowly.
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. 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.
|
|
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
July 22, 2013, 09:32:32 PM |
|
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.
|
|
|
|
justusranvier
Legendary
Offline
Activity: 1400
Merit: 1009
|
|
July 22, 2013, 10:29:21 PM |
|
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.
|
|
|
|
Mooshire
|
|
July 24, 2013, 03:54:53 AM |
|
Loved the wallet before it went downhill, hope to use again when it's back up and running.
|
|
|
|
solex
Legendary
Offline
Activity: 1078
Merit: 1002
100 satoshis -> ISO code
|
|
July 24, 2013, 04:02:51 AM |
|
Loved the wallet before it went downhill, hope to use again when it's back up and running.
It works great. It is only 32bit windows which has given up the ghost.
|
|
|
|
|