Pages:
Author

Topic: RAM-Reduction & Backup Center Testing (version 0.89.99.16) (Read 41296 times)

legendary
Activity: 1498
Merit: 1000
So, Armory is going to turn into a SPV wallet? Or will it keep a copy of the blockchain? That would make sense, and besides I personally would still run a full node anyway, so I can have Armory pointed there.

It sounds like it be the same, which is basically a full node, without verification of the transactions. It will just switch the method of getting the blockchain.
sr. member
Activity: 302
Merit: 250



Now that the conference is over, I took a stab at OSX.  I finally got it compiling and running!  But, I don't have the full blockchain on my Mac, so I can't really test it...  Try it out!

https://s3.amazonaws.com/bitcoinarmory-releases/Armory_0.90-beta_OSX_test1.tar.gz


Woo-hoo! this what I've been waiting for. Will try out tonight and report back. Thanks!!
full member
Activity: 135
Merit: 107
Works well so far on MBP Retina 15" w/ OS 10.9.  Fully synched but haven't tried any transactions yet.
legendary
Activity: 1498
Merit: 1000



Now that the conference is over, I took a stab at OSX.  I finally got it compiling and running!  But, I don't have the full blockchain on my Mac, so I can't really test it...  Try it out!

https://s3.amazonaws.com/bitcoinarmory-releases/Armory_0.90-beta_OSX_test1.tar.gz

It works for me, I am on maverick 10.9.0, not 10.9.1.
legendary
Activity: 1428
Merit: 1093
Core Armory Developer



Now that the conference is over, I took a stab at OSX.  I finally got it compiling and running!  But, I don't have the full blockchain on my Mac, so I can't really test it...  Try it out!

https://s3.amazonaws.com/bitcoinarmory-releases/Armory_0.90-beta_OSX_test1.tar.gz
newbie
Activity: 49
Merit: 0
I've been able to reproduce the error and fix the error.

When install Bitcoin-QT and reload the blockchain with bootstrap.dat the error pops up. But if i install the bitcoin-QT fresh and let it download the whole blockchain over two days, it works.

I hope this, along with the log files i sent you, help you solve problem.

Thanks again for such a great piece of software!

I'm starting to notice some patterns in this.  It may have to do with the version of Bitcoin-Qt that produces the blk*.dat files.  It's very possible that there are artifacts in the blk*.dat files that I don't handle gracefully. 

So where did your bootstrap file come from?  Do you know the version that created it? 

On the other hand, I'd like to move away from reading the blk*.dat files entirely, and just request it as a regular blockchain download via P2P (via localhost).  This would solve a lot of problems and should make the version of Bitcoin-Qt irrelevant, in addition to allowing remote Bitcoin-Qt instances.  In fact, I wanted to do this for 0.90-beta, but the change was too dramatic, and decided to keep it simple for now.  But now that this version is stabilizing, it may make sense to do that, especially if it wipes out these kinds of bugs, which may be elusive and difficult to debug (basically allow bitcoin-qt to read its own blk*.dat files properly, and pass us the data in standardized network messages).

I swiped the file from this thread: https://bitcointalksearch.org/topic/ann-bitcoin-blockchain-data-torrent-145386

as for what version that created it, I have no idea.

Those changes to how it gets the blockchain sound like a great idea! Take all the time you need to implement it! Smiley

Great job again!
legendary
Activity: 3416
Merit: 1912
The Concierge of Crypto
So, Armory is going to turn into a SPV wallet? Or will it keep a copy of the blockchain? That would make sense, and besides I personally would still run a full node anyway, so I can have Armory pointed there.
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
I've been able to reproduce the error and fix the error.

When install Bitcoin-QT and reload the blockchain with bootstrap.dat the error pops up. But if i install the bitcoin-QT fresh and let it download the whole blockchain over two days, it works.

I hope this, along with the log files i sent you, help you solve problem.

Thanks again for such a great piece of software!

I'm starting to notice some patterns in this.  It may have to do with the version of Bitcoin-Qt that produces the blk*.dat files.  It's very possible that there are artifacts in the blk*.dat files that I don't handle gracefully. 

So where did your bootstrap file come from?  Do you know the version that created it? 

On the other hand, I'd like to move away from reading the blk*.dat files entirely, and just request it as a regular blockchain download via P2P (via localhost).  This would solve a lot of problems and should make the version of Bitcoin-Qt irrelevant, in addition to allowing remote Bitcoin-Qt instances.  In fact, I wanted to do this for 0.90-beta, but the change was too dramatic, and decided to keep it simple for now.  But now that this version is stabilizing, it may make sense to do that, especially if it wipes out these kinds of bugs, which may be elusive and difficult to debug (basically allow bitcoin-qt to read its own blk*.dat files properly, and pass us the data in standardized network messages).
newbie
Activity: 49
Merit: 0
Hi!

Just installed the new version (0.90) but it keeps getting stuck at the "building databases" part with "15 seconds" left.

I tried "rebuild and rescan databases" in the help menu and it builds up to 99% again but keeps getting stuck with "15 seconds" left. I left it on for a full day but it never budged, then it started giving a crapload of "bitcoin-qt disconnected" errors.

I'm using windows 8 64-bit with 32GB of ram and a 256GB SSD.

Send a log file to support at bitcoinarmory com

I've been able to reproduce the error and fix the error.

When install Bitcoin-QT and reload the blockchain with bootstrap.dat the error pops up. But if i install the bitcoin-QT fresh and let it download the whole blockchain over two days, it works.

I hope this, along with the log files i sent you, help you solve problem.

Thanks again for such a great piece of software!
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
I had some fun with 0.9 lateley. The backup center is just mindblowingly awesome. All the safety questions are addressed. e.g. I was wondering if testing of backup is safe. Just then it tells me that no keys will be written to disk. Great stuff.

I noticed one little flaw though. Might have been mentioned before. Wehn printing a 1/1 (normal) paper backup the last block of of the chain key on each line does not stay within the given frame. two letters were just on top of the line. Does not happen with fragmented backups though. Let me know if you need a screenshot.

Smiley   Thanks! 

I have battled with the text sizes and fonts on those backups, but Qt just does not want to obey me.  I think I'm missing something, and maybe it's somethign we should investigate for 0.91-beta... apparently your desktop DPI and default font affects it even though I explicitly tell Qt the exact size and font to use.  And on Mac it doesn't even use fixed-width font!

I'll make a note for the next version to do a bit more investigation of that (as well as spend some time on the Mac build, which got lost in the conference preparations)

full member
Activity: 226
Merit: 100
I had some fun with 0.9 lateley. The backup center is just mindblowingly awesome. All the safety questions are addressed. e.g. I was wondering if testing of backup is safe. Just then it tells me that no keys will be written to disk. Great stuff.

I noticed one little flaw though. Might have been mentioned before. Wehn printing a 1/1 (normal) paper backup the last block of of the chain key on each line does not stay within the given frame. two letters were just on top of the line. Does not happen with fragmented backups though. Let me know if you need a screenshot.
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
I don't know if this was posted or not, but i have a problem. I'm using Armory with the "--datadir=" command and it keeps crashing at 99% scanning transaction history with every version that i try. Using the default directory works, but what should i do to work with the "--datadir=" option?


Solved. Deleted the "databases" folder and now works like a charm.

This may have been the last major bug I never found before releasing

Code:
-ERROR - 1384746267: (..\StoredBlockObj.cpp:1063) Cannot get tx copy, because don't have full StoredTx!

It's in my plans to fix that for 0.91-beta.  I got a couple people to pass me their databases that have this error so I can debug it.  Will tend to it after I get back from the conference (in addition to fixing all the broken optimizations in the LevelDB code which causes it to scan so slowly!)
legendary
Activity: 1904
Merit: 1007
I don't know if this was posted or not, but i have a problem. I'm using Armory with the "--datadir=" command and it keeps crashing at 99% scanning transaction history with every version that i try. Using the default directory works, but what should i do to work with the "--datadir=" option?


Solved. Deleted the "databases" folder and now works like a charm.
legendary
Activity: 1904
Merit: 1007
I don't know if this was posted or not, but i have a problem. I'm using Armory with the "--datadir=" command and it keeps crashing at 99% scanning transaction history with every version that i try. Using the default directory works, but what should i do to work with the "--datadir=" option?

Edit: I am thinking that using a .wallet file may pose some kind of security breach. How hard would it be to implement the use of custom named wallets? For examtle abc.jpg or abc.xyz? The format can be the same i assume, only the name changes.
sr. member
Activity: 353
Merit: 250
Update, seems to be solved by reboot ..  Huh
sr. member
Activity: 353
Merit: 250
I am currently switching to armory, used to have .88, now updated to .90

I use a second computer as offline wallet. Testing the offline transactions workd in .88, but the online version was eating up my ram - made the switch to .90 and this is fine now.

HOWEVER, when I try to make an offline transaction clicking the "create unsigned transaction" will not have an effect. When looking into the armory log I find this exception for each button click:

2013-12-04 21:15 (ERROR) -- Traceback (most recent call last):
  File "qtdialogs.pyc", line 5225, in createOfflineTxDPAndDisplay
  File "qtdialogs.pyc", line 5514, in validateInputsGetTxDP
  File "armoryengine.pyc", line 6493, in createFromTxOutSelection
  File "armoryengine.pyc", line 6362, in createFromPyTx
  File "armoryengine.pyc", line 4274, in copy
  File "armoryengine.pyc", line 4263, in unserialize
  File "armoryengine.pyc", line 4111, in unserialize
UnserializeError

Any ideas?
newbie
Activity: 49
Merit: 0
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
Hi!

Just installed the new version (0.90) but it keeps getting stuck at the "building databases" part with "15 seconds" left.

I tried "rebuild and rescan databases" in the help menu and it builds up to 99% again but keeps getting stuck with "15 seconds" left. I left it on for a full day but it never budged, then it started giving a crapload of "bitcoin-qt disconnected" errors.

I'm using windows 8 64-bit with 32GB of ram and a 256GB SSD.

Send a log file to support at bitcoinarmory com
newbie
Activity: 49
Merit: 0
Hi!

Just installed the new version (0.90) but it keeps getting stuck at the "building databases" part with "15 seconds" left.

I tried "rebuild and rescan databases" in the help menu and it builds up to 99% again but keeps getting stuck with "15 seconds" left. I left it on for a full day but it never budged, then it started giving a crapload of "bitcoin-qt disconnected" errors.

I'm using windows 8 64-bit with 32GB of ram and a 256GB SSD.
hero member
Activity: 490
Merit: 500
I forgot to make the RAM usage for that first build configurable (or at least dynamically adjustable based on available RAM).  But right now it should only use 1 GB to build the DB.  However it is likely to slow things down because it's doing very heavy disk accessing. But after that process is done, it should only use 200-300 MB, and start up very quickly. And not station the system much at all.

Please let us know if your experience differs significantly.

Thanks for the update.  It was slow initially, but now that the scanning transaction history part is done, it's pretty quick again.  Good work.
Pages:
Jump to: