Topic: Blockchain Rescanning (Read 1933 times)
Thank you so much .
oh, thought it was tagged alright let me check it out and see thank you.
I build it the same way v0.94.1 was built right?
Yes. I build it the same way v0.94.1 was built right?
oh, thought it was tagged alright let me check it out and see thank you.
I build it the same way v0.94.1 was built right?
I build it the same way v0.94.1 was built right?
I am looking at goatpig's fork of BitcoinArmory under the dev branch and I dont see v0.95.
It's not tagged. The dev branch is 0.95.
I am looking at goatpig's fork of BitcoinArmory under the dev branch and I dont see v0.95.
oh is it v0.5.1 alpha?
No... What are you talking about? Where are you seeing that?
oh is it v0.5.1 alpha?
Is version 94.1 the version that is referred to as version 5?
Version 5? If you're talking about 0.95, no it is not. 0.95 has not been released yet, it is about to enter the official testing phase. Currently it's the dev branch so if you want to try it out, checkout the dev branch and build it yourself.
Is version 94.1 the version that is referred to as version 5?
Hi Goatpig,
That is awesome, okay will be getting it today from git, will let you know how it goes.
Thank you.
Alright,
I will try that instead but I noticed on your website ( https://www.bitcoinarmory.com/using-armory-python/ ) you have:
"Note that, unless you have built the Armory databases with the –supernode option, Armory will automatically initiate a rescan if there are any addresses in the wallet not there in previous loads" does this still hold?
That's information that holds true for 0.93, the latest version ATI supports. This project is a fork of ATI's work, and 0.94 then 0.95 come with nuances to that old statement. Notably in your case, 0.95 will not rescan.
0.95 keeps constant record of any addresses you show it, as opposed to previous versions that only keep up to date with addresses they are loaded with. This change is due to the database being it's own binary starting 0.95, which means it isn't necessarily loaded with any wallet data at init.
In order to prevent constant rescanning from detached db inits, the db address list is now append only. In your case it simply means it fixes your issue 100%
Alright,
I will try that instead but I noticed on your website ( https://www.bitcoinarmory.com/using-armory-python/ ) you have:
"Note that, unless you have built the Armory databases with the –supernode option, Armory will automatically initiate a rescan if there are any addresses in the wallet not there in previous loads" does this still hold?
Hi Goatpig
As promised I familiarized myself with the architecture, and I am just wondering if there is a way then to speed up the
time it takes to do a fresh scan?
Currently it takes close to an hour.
Thank you for your help.
As promised I familiarized myself with the architecture, and I am just wondering if there is a way then to speed up the
time it takes to do a fresh scan?
Currently it takes close to an hour.
Thank you for your help.
0.95 will fix your issue 100%. You should help testing with that.
Hi Goatpig
As promised I familiarized myself with the architecture, and I am just wondering if there is a way then to speed up the
time it takes to do a fresh scan?
Currently it takes close to an hour.
Thank you for your help.
As promised I familiarized myself with the architecture, and I am just wondering if there is a way then to speed up the
time it takes to do a fresh scan?
Currently it takes close to an hour.
Thank you for your help.
Thanks goatpig
Okay let me do that and familiarise myself more.
Okay let me do that and familiarise myself more.
Any idea why it has to load the database for an hour when I create a transaction or check the balance?
It you modify address sets in between inits it will rescan from scratch:
You got wallet A and B.
You init the db against wallet A. That's a fresh scan.
You then shutdown Armory and restart with wallet B instead of wallet A. This is again a fresh scan, first time it saw that wallet.
Now you redo this with wallet A, it will start with a fresh scan again because the address sets have changed and you have just registered addresses that are out of sync with the last good DB state.
Same will happen if you scan A, shutdown, extend A's address chain offline, then restart with the longer A address set. It will scan from the start.
This is why I asked about the databases you are using. Seeing you are not familiar with the architecture, I'd suggest you look at the DB code starting here:
https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/DatabaseBuilder.cpp#L28
Any idea why it has to load the database for an hour when I create a transaction or check the balance?
Hi goatpig
Is the Armory db in the .armory folder. Because in this folder I have a database directory but inside I have the following:
blkdata headers history ssh stxo subssh txhints zeroconf
blkdata-lock headers-lock history-lock ssh-lock stxo-lock subssh-lock txhints-lock zeroconf-lock
Is the Armory db in the .armory folder. Because in this folder I have a database directory but inside I have the following:
blkdata headers history ssh stxo subssh txhints zeroconf
blkdata-lock headers-lock history-lock ssh-lock stxo-lock subssh-lock txhints-lock zeroconf-lock
That's the right directory, and the right list of files that comprises the Db, I believe.
Hi goatpig
Is the Armory db in the .armory folder. Because in this folder I have a database directory but inside I have the following:
blkdata headers history ssh stxo subssh txhints zeroconf
blkdata-lock headers-lock history-lock ssh-lock stxo-lock subssh-lock txhints-lock zeroconf-lock
Is the Armory db in the .armory folder. Because in this folder I have a database directory but inside I have the following:
blkdata headers history ssh stxo subssh txhints zeroconf
blkdata-lock headers-lock history-lock ssh-lock stxo-lock subssh-lock txhints-lock zeroconf-lock
I'm talking about the Armory DB, not the blockchain. Are you running this sample code with its own DB?
Jump to: