|
Use the same offline and online version.
|
|
|
|
|
tagged 0.96.4 earlier this week, have to come up with builds.
|
|
|
|
USB2 is 10x slower than SATA HDDs. Yes, but it works fine for me, since I'm sitting behind a 6 MBit/s download connection.  Or do I miss the point? It won't be TOO much of a pain when syncing the chain, but when bootstrapping an ArmoryDB, it will slow stuff down to a halt. That makes it harder on you to detect issues with your setup, but if you can get away with it, more power to you. However I'd prefer you don't recommend that to newbies. |
|
|
|
Any hdd would do it. It doesn't have to do anything with being an SSD or not. Any regular sata-based hdd would to it too, even an external one connected via USB 2.0. You want a SSD because HDDs are just too slow. There is over 150GB of data to process to parse the blockchain, and it's not getting smaller. A modern HDD can handle at best ~120MB/s of sequential read. That's over 20min in ideal conditions for a single pass of the chain. You need 2 passes to build & scan, and the conditions are obviously not going to be ideal, since the code doesn't only access data sequentially, and it is writing back the DB at the same time. USB2 is 10x slower than SATA HDDs. |
|
|
|
|
This feature is currently broken. Will be fixed when 0.96.4 is finalized.
|
|
|
|
|
You would have to start Armory with --datadir=*custompath*
|
|
|
|
when Exporting Key Lists, clicking Save File saves them where? i don't see a dialog box allowing me to choose name or destination.
That's botched, fixing it. |
|
|
|
|
Delete this folder and try again:
C:\Users\Peter\AppData\Roaming\Armory\databases
|
|
|
|
|
Add listen=1 in there and try again.
|
|
|
|
Unfortunatelly armory shows me "node offline (513764 blocks)".
That means ArmoryDB cannot find your node. What settings are you running BitcoinQt with? |
|
|
|
Now - does that *Forever* mean, that also all future addresses from that wallet, including the segwit adresses are save to be restored?
Yes. Forever means forever, at least in here. |
|
|
|
|
These are the one. The .lmdb wallets do not carry the same file ID cause the ID is built differently. You can nuke any .lmdb (and lock files) file with anything prior to 0.97 (this is to future proof this comment) as they are built on the fly WO copies of the python wallets.
|
|
|
|
What I am asking is whether you delete the .lmdb mirror wallet files in the Armory datadir at all.
no, why? what does that do? It's a watching only copy of your wallet used to interface with the DB. This most likely still has the imported public key in it, which is why the DB returns those UTXO in coin control. |
|
|
|
|
There are no changes in 0.16 that pertains to what Armory uses of Core.
|
|
|
|
|
What I am asking is whether you delete the .lmdb mirror wallet files in the Armory datadir at all.
|
|
|
|
after signing, i always delete/remove the wallet in the GUI, nothing more.
On the online side? |
|
|
|
i updated the online machine to 0.96 and it worked.
You should upgrade, not downgrade. i have no idea how the hell the first one went through, but it did. anyway, thanks to everyone for their responses.
Most likely didn't involve any P2SH constructs. |
|
|
|
|
Show Posts
