Bitcoin Forum

Bitcoin => Armory => Topic started by: goatpig on January 15, 2018, 01:12:28 AM



Title: 0.96.4 RC3
Post by: goatpig on January 15, 2018, 01:12:28 AM
Binaries: https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.3.992

Test away.


Title: Re: 0.96.4 RC3
Post by: PhoenixFire on January 15, 2018, 02:06:16 AM
No problems so far. Thanks, goatpig!


Title: Re: 0.96.4 RC3
Post by: idoB on January 15, 2018, 05:14:22 PM
Verified: the problem with splashscreen freeze that was present in RC2 ('Start in' field in shortcut) is solved in RC3. THANKS!


Title: Re: 0.96.4 RC3
Post by: jojo69 on January 15, 2018, 11:13:47 PM
awesome, been waiting for this one, grabbing now


Title: Re: 0.96.4 RC3
Post by: TimS on January 16, 2018, 04:24:47 AM
I started Armory with --satoshi-datadir="D:\Bitcoin" and it's not connecting to my Bitcoin Core node. The log looks like it reads this, but then looks for the DB in the wrong place:
Code:
2018-01-15 22:07:29 (INFO) -- ArmoryUtils.pyc:1301 -     satoshiHome     : D:\Bitcoin
2018-01-15 22:07:32 (ERROR) -- BDM.pyc:197 - DB error: C:\Users\[user]\AppData\Roaming/Bitcoin/blocks is not a valid path
Let me know if I should provide full logs or do something different.


Title: Re: 0.96.4 RC3
Post by: droark on January 16, 2018, 06:05:23 AM
Is that the full path where the blockchain resides? It's not in D:\Bitcoin\blocks or something similar?


Title: Re: 0.96.4 RC3
Post by: TimS on January 16, 2018, 12:20:48 PM
Is that the full path where the blockchain resides? It's not in D:\Bitcoin\blocks or something similar?
No, D:\Bitcoin\ is the home directory, and then D:\Bitcoin\blocks\ is where the blockchain resides. I tried it the other way, no change:
Code:
2018-01-16 06:18:41 (INFO) -- ArmoryUtils.pyc:1301 -     satoshiHome     : D:\Bitcoin\blocks
...
2018-01-16 06:18:44 (ERROR) -- BDM.pyc:197 - DB error: C:\Users\[user]\AppData\Roaming/Bitcoin/blocks is not a valid path


Title: Re: 0.96.4 RC3
Post by: droark on January 16, 2018, 05:50:41 PM
satoshi-datadir does need to be D:\Bitcoin\blocks, but anyway, please post your full logs using this particular flag. Thanks.


Title: Re: 0.96.4 RC3
Post by: TimS on January 16, 2018, 06:39:58 PM
Soo the problem is solved. I noticed that ArmoryDB.exe (probably from an older version of Armory) was still running. I ended that process, moved log files, and now Armory is working. Thanks for the help. :)


Title: Re: 0.96.4 RC3
Post by: alomar on January 16, 2018, 11:06:23 PM
as a housekeeping note, when we compile this new version, armory_0.96.3.992_src.tar.gz, should we be doing anything to the old version first (uninstall)?  or just compile over the top of the old version w/o worrying about anything?


Title: Re: 0.96.4 RC3
Post by: goatpig on January 17, 2018, 12:00:16 AM
compile or install?

Before you compile you should "make clean". If you install, you should "make uninstall" on the previous version before "make clean".


Title: Re: 0.96.4 RC3
Post by: alomar on January 17, 2018, 02:28:30 AM
compile or install?



hmm, what's the difference in this case and which one should i do and why?  i want to upgrade to this new version from 0.96.3.991


Title: Re: 0.96.4 RC3
Post by: goatpig on January 17, 2018, 09:53:30 AM
"Compile" is to build the binaries. Install is to setup the binaries on your system. If you use my builds you are only installing, if you build from source, you are "compiling" then installing. If you build from source you could also only "compile" and run the binaries from the source folder, without installing.

I put compile in quotes cause the actual term is to build the binaries.


Title: Re: 0.96.4 RC3
Post by: alomar on January 17, 2018, 03:41:21 PM
"Compile" is to build the binaries. Install is to setup the binaries on your system. If you use my builds you are only installing, if you build from source, you are "compiling" then installing. If you build from source you could also only "compile" and run the binaries from the source folder, without installing.

I put compile in quotes cause the actual term is to build the binaries.

so i compiled my current version and run armory via the CLI by typing "armory" using the /usr/local/bin.  thus, i'm running the binaries from the source folder without an install, correct, ?  if so, do i just "make clean" before i compile this new version?

edit:  wait, i think i ran "sudo make install" after compiling on my system for my current version.  does that mean i did both a compile and a local install?  if that's the case, then i need to run "make uninstall" on the previous version before "make clean", right?


Title: Re: 0.96.4 RC3
Post by: PhoenixFire on January 17, 2018, 07:00:36 PM
so i compiled my current version and run armory via the CLI by typing "armory" using the /usr/local/bin.  thus, i'm running the binaries from the source folder without an install, correct, ?  if so, do i just "make clean" before i compile this new version?

edit:  wait, i think i ran "sudo make install" after compiling on my system for my current version.  does that mean i did both a compile and a local install?  if that's the case, then i need to run "make uninstall" on the previous version before "make clean", right?

No to the first paragraph, yes to the second:

make uninstall  (sudo if it fails)
make clean
make
make install (sudo if it fails)


Title: Re: 0.96.4 RC3
Post by: goatpig on January 18, 2018, 06:49:34 PM
"sudo make install" after compiling on my system for my current version.  does that mean i did both a compile and a local install?  if that's the case, then i need to run "make uninstall" on the previous version before "make clean", right?

Typically you don't need to, as the same files as the previous install will be copied over, overwriting the previous install. But it's preferable to "make uninstall", as it guarantees the old files are removed, in case some of these files are not covered by the new install.


Title: Re: 0.96.4 RC3
Post by: alomar on January 18, 2018, 07:18:45 PM
"sudo make install" after compiling on my system for my current version.  does that mean i did both a compile and a local install?  if that's the case, then i need to run "make uninstall" on the previous version before "make clean", right?

Typically you don't need to, as the same files as the previous install will be copied over, overwriting the previous install. But it's preferable to "make uninstall", as it guarantees the old files are removed, in case some of these files are not covered by the new install.

yeah, so i didn't do a "make uninstall", just a "make clean", before compiling this new version and everything is running well.  

thank you very much for all the great work.  this software is as well honed and running as i've ever seen it.  give me a way to sort thousands of UTXO's in Coin Control or search quickly for specific one's and i'll have an orgasm :)


Title: Re: 0.96.4 RC3
Post by: goatpig on January 18, 2018, 07:49:14 PM
Sorting is a PITA to implement in GUI so don't hold your breath for that one.


Title: Re: 0.96.4 RC3
Post by: bwhm on January 22, 2018, 09:04:03 PM
Not sure where to ask this question so I'm trying here:

I have tried installing Armory on an offline computer using Ubuntu 16.04, but failed due to the missing dependencies a couple other people have mentioned. I saw using 14.04 would help, but based on the age of my CPU (https://www.cpubenchmark.net/cpu.php?cpu=Intel+Pentium+T2390+%40+1.86GHz), I guess I would stop at the same point as rothbart in the 0.96.2 release thread (https://bitcointalk.org/index.php?topic=2133694.0;all).

I'm sure you have better things to do, but are there any plans on making an offline bundle compatible with shitty old CPUs?

Thanks for all your work!


Title: Re: 0.96.4 RC3
Post by: goatpig on January 22, 2018, 10:45:32 PM
There are builds for old CPUs (gcc4.7). Offline bundles are a different thing. They're a build + the collection of necessary dependencies to run the software. You can get these dependencies from the relevant public repository and they will work with your CPU as long as you chose the right architecture.

Put another way, if you are missing dependencies, you can simply grab those on your own. I test the offline bundles against freshly installed VMs, so as far as I know, they are fully functional. If you are missing dependencies on your machine, might as well list them here so that I can get an idea what's missing.

Installing dependencies is a one time thing (as long as you don't reinstall the OS). Once you have an offline bundle installed and functional, you most likely won't need the offline bundle for the next version, just package. I make a point in not inflating the list of dependencies needlessly, so that part should remain true. Matter of fact, I've drastically reduced it since 0.93. In other words, you could install the 0.93 offline bundle, update Armory to 0.96.4 and most likely get away with it.


Title: Re: 0.96.4 RC3
Post by: bwhm on January 23, 2018, 08:36:43 AM
Not sure I follow regarding the offline bundle. The reason I asked was because of a post saying an offline release compatible with old CPUs was expected in october. I interpreted this as no offline bundle can be installed on old CPUs. Are you saying the older versions are compatible, so I can install 0.93 and upgrade?

I did try following the bitzuma (https://bitzuma.com/posts/offline-installation-of-armory-on-tails-and-ubuntu-linux/) guide with its 11 dependencies, but had already installed ubuntu 16.04. Both this and the offline bundle was lacking python-qt4. I grabbed that one, but it also failed due to dependencies and I read there were quite a lot of them for 16.04.

Anyways I'll try again on 14.04 both with aforementioned guide and a gcc4.7 release, and if it fails with an old offline package.

Thanks again for your help.


Title: Re: 0.96.4 RC3
Post by: bwhm on January 25, 2018, 07:59:32 AM
So I followed your advise, and installing the offline bundle (I used 0.92.2) on Ubuntu 14.04 worked perfectly, and I was able to upgrade to current version without any additional dependencies or tweeks. Thanks!

My online system was initially running on windows 10, with core 0.15.1 and armory 0.96.3, which I knew ran well, and received transactions. I then upgraded the online version to 0.96.3.992, and sent a test transaction to the watch only wallet I had saved on it. This led some issues as others have also described. First, armory stopped syncing, and despite saying it was online, it was frozen multiple blocks behind without. I only noticed this when it didn't pick up my test transaction, as 0.96.3 had did. After restarting it and rescanning, I quit armory and started core, allowing it to sync. Then starting armory and rescan/rebuilding, it still didn't pick up the transaction despite it now being confirmed within the block height armory had synced. It should be noted armory still didn't sync blocks newer than I had downloaded with core. I reverted back to 0.96.3 and it immediately worked, so it was not really a problem. Let me know if/what logs you would like to look at, and I can PM them.

To complete the test, I then created a transaction online, copied it to a usb, and imported to my offline signer. Everything looked ok, so I signed and it automatically saved it back on the USB. The transaction block became about twice as before signing. Importing it to the online computer, it claimed the transaction was unsigned. It could still read the details of the transaction. I tried again, and this time manually saving a text file of the signed transaction as well, but neither worked.

I tried a third time saving the signed transaction data as a hex text file, and electrum recognized it as signed and offered to broadcast (obviously, it didn't recognize armorys transaction format). I did not broadcast in order to check further. I then tried armory again, but it still would not accept the transaction as signed, nor did it recognize the raw tx data in "Offline Transaction". I then went tools -> broadcast raw transaction, prompting* the following error message:

"Not Online
Bitcoin Core is not available, so Armory will not be able to broadcast any transactions for you."

*This happened before I got to paste the tx data

At this point armory says it is connected and online, and has synced all new blocks on its own.

Although I haven't done it yet, it seems I can still broadcast the transaction using another service, so its more of an inconvenience than a big issue for me personally. Any ideas to what the issue is? I can also pm you the signed and unsigned armory data if you want it, but it seems like the problem lies with the online computer.


Title: Re: 0.96.4 RC3
Post by: droark on January 25, 2018, 08:48:13 AM
Just curious, when you started up RC3, was ArmoryDB still running in the task manager? That can cause problems. If it wasn't, I'm not sure offhand what could be going on.


Title: Re: 0.96.4 RC3
Post by: bwhm on January 25, 2018, 10:30:52 AM
I can't remember if it did or not, but I did check task manager and closed it manually if it did. This has solved some issues before, so I 'm aware of it.

Anyway, I just tried again and this time I was able to open the "broadcast raw transaction" option, paste the raw data, and get it parsed. As the outputs looked correct, I tried broadcasting, but nothing happened. I checked the parsed tx data again, and noticed that the sender address was not the one I had specified. Instead of the one with spendable UTXOs, it was one that shows up empty on blockchain.info. When I copy in the "signed" transaction data again to the online system, it still provides the correct transaction details, except for the fact that it comes in unsigned.

I really don't understand this...

***I don't think it should matter, but the offline signing wallet was made from a secure printed fragmentet backup in order to test it. The online watch-only wallet was created before I deleted and regenerated my wallet.


Title: Re: 0.96.4 RC3
Post by: bwhm on January 25, 2018, 11:15:30 AM
So, I just pasted the transaction details into blockchain.info/decode-tx and it came out correct. I also realized that armory had the correct PrevTxHash as input, but the sender address was still wrong. FYI: blockchains tool doesn't list the sender address, just the previous tx hash. I then broadcasted it, and it immediately showed up correctly in armory.

So I know the setup works, and I have my private keys, but it would be nice to know whether the sending issues were mine or the software. I did use RBF if that matters.


*Edit.
To keep from spamming too much, I'll just edit this post. I tried again with the same result. Online machine running 0.96.3 on windows didn't accept the transaction file as signed.

When I upgraded the online computer back to 0.96.3.992 and loaded the transaction it recognizes it as valid. I initially had the same problem with syncing, and it didn't work starting bitcond manually either. What did work was running bitcoin-qt before starting armory. It synced, recognized the transaction, and broadcast it successfully.

Hopefully this will help someone else someday. Thanks for help and patience.


Title: Re: 0.96.4 RC3
Post by: alomar on January 26, 2018, 04:34:46 PM
Sorting is a PITA to implement in GUI so don't hold your breath for that one.

how about search?


Title: Re: 0.96.4 RC3
Post by: goatpig on January 26, 2018, 06:01:58 PM
Sorting is a PITA to implement in GUI so don't hold your breath for that one.

how about search?

I have plans for some advanced search/sorting but not in a 0.96 iteration.


Title: Re: 0.96.4 RC3
Post by: johnlu on January 28, 2018, 12:04:08 PM
Getting this error in ArmoryDB:
Code:
-ERROR - 11:54:59: (BlockchainScanner.cpp:445) Missing file map for output scan, this is unexpected
-ERROR - 11:54:59: (BlockchainScanner.cpp:447) Has the following block files:
-ERROR - 11:54:59: (BlockchainScanner.cpp:449)  --- #1146
-ERROR - 11:54:59: (BlockchainScanner.cpp:451) Was looking for id #1147
terminate called after throwing an instance of 'std::runtime_error'
  what():  missing file map


Title: Re: 0.96.4 RC3
Post by: goatpig on January 28, 2018, 03:35:58 PM
Consistently?


Title: Re: 0.96.4 RC3
Post by: johnlu on January 28, 2018, 06:52:57 PM
Almost once a day.


Title: Re: 0.96.4 RC3
Post by: goatpig on January 28, 2018, 08:17:36 PM
What OS you on? Also, at the moment it happens, does the missing blk file reside on disk? Is restarting the DB fixing it?


Title: Re: 0.96.4 RC3
Post by: johnlu on January 28, 2018, 08:58:53 PM
What OS you on?
Linux

Also, at the moment it happens, does the missing blk file reside on disk?
It seems it does:
Code:
$ ls .bitcoin/blocks/blk01147.dat -lh
-rw------- 1 user user 96M ene 28 21:55 .bitcoin/blocks/blk01147.dat

Is restarting the DB fixing it?
Yup.
ArmoryDB aborts and when I start it again, it seems to run fine.


Title: Re: 0.96.4 RC3
Post by: goatpig on January 28, 2018, 09:46:46 PM
It seems it does:

Compare the file creation timestamp to the log message error timestamp. What kind of hardware does your blockchain data reside on? How long do you let the DB run?


Title: Re: 0.96.4 RC3
Post by: johnlu on January 28, 2018, 09:51:56 PM
Compare the file creation timestamp to the log message error timestamp.
I'll see next time.

What kind of hardware does your blockchain data reside on? How long do you let the DB run?

HDD and SSD, I cannot know exactly because I use lvm, so it can reside anywhere...

I let it run between 1 hour and 8 hours usually.


Title: Re: 0.96.4 RC3
Post by: goatpig on January 28, 2018, 10:03:14 PM
HDD and SSD, I cannot know exactly because I use lvm, so it can reside anywhere...

Most likely the issue is that the node write operation committing the new file to disk (which happens once or twice a day) is not flushed by the time Armory goes looking for it, courtesy of cached disks (which is after processing the new block notification over P2P from the node).

Looking at the code, it doesn't seem that throw is crawling all the way back to the main execution thread, so it's unexpected that it would kill the entire process. On the other hand, that also means it could be caught and handled. If you can build from source and are willing to tinker with that stuff, I can tell you what code to add to try and fix this.


Title: Re: 0.96.4 RC3
Post by: johnlu on January 29, 2018, 08:27:36 PM
Code:
-INFO  - 20:25:41: (BlockchainScanner.cpp:857) scanned block #506662
-INFO  - 20:25:41: (lmdb_wrapper.cpp:388) Opening databases...
-INFO  - 20:25:41: (DatabaseBuilder.cpp:186) scanned new blocks in 0s
-INFO  - 20:25:41: (DatabaseBuilder.cpp:190) init db in 18s
-INFO  - 20:25:41: (BDM_supportClasses.cpp:1891) Enabling zero-conf tracking
-INFO  - 20:26:28: (SocketObject.cpp:355) POLLIN recv return 0
-ERROR - 20:26:28: (BitcoinP2P.cpp:1037) caught StopBlockingLoop in processDataStackThread


Title: Re: 0.96.4 RC3
Post by: goatpig on January 29, 2018, 10:56:31 PM
Did the db crash after this? Hang? Ignored the Node entirely? Client crashed maybe?


Title: Re: 0.96.4 RC3
Post by: alomar on January 30, 2018, 02:55:17 AM
ok, 0.96.3.992 started acting up, stuck on Scanning Tx History @1sec:

https://i.imgur.com/H6JG7oZ.png


Title: Re: 0.96.4 RC3
Post by: alturigo on January 30, 2018, 11:56:27 AM
Using Bisq's option "Open your external wallet for funding" gives first an error (Invalid spend value) and if clicked a second time crashes Armory.

Not sure if it is Bisq's fault only but Armory shouldn't crash.

Code:
-INFO  - @: (SocketObject.cpp:355) POLLIN recv return 0
(ERROR) Traceback (most recent call last):
  File "/usr/bin/../lib/armory/ArmoryQt.py", line 1759, in triggerProcessMutexNotification
    self.uriLinkClicked(uriLink)
  File "/usr/bin/../lib/armory/ArmoryQt.py", line 2055, in uriLinkClicked
    return self.uriSendBitcoins(uriDict)
  File "/usr/bin/../lib/armory/ArmoryQt.py", line 3518, in uriSendBitcoins
    dlg.frame.prefillFromURI(uriDict)
  File "/usr/lib/armory/ui/TxFrames.py", line 1463, in prefillFromURI
    self.addOneRecipient(addr160, amount, message, label)
  File "/usr/lib/armory/ui/TxFrames.py", line 336, in addOneRecipient
    self.resolveCoinSelection()
  File "/usr/lib/armory/ui/TxFrames.py", line 537, in resolveCoinSelection
    raise e
RuntimeError: Invalid spend value

Traceback (most recent call last):
  File "/usr/bin/../lib/armory/ArmoryQt.py", line 1759, in triggerProcessMutexNotification
    self.uriLinkClicked(uriLink)
  File "/usr/bin/../lib/armory/ArmoryQt.py", line 2055, in uriLinkClicked
    return self.uriSendBitcoins(uriDict)
  File "/usr/bin/../lib/armory/ArmoryQt.py", line 3518, in uriSendBitcoins
    dlg.frame.prefillFromURI(uriDict)
  File "/usr/lib/armory/ui/TxFrames.py", line 1463, in prefillFromURI
    self.addOneRecipient(addr160, amount, message, label)
  File "/usr/lib/armory/ui/TxFrames.py", line 336, in addOneRecipient
    self.resolveCoinSelection()
  File "/usr/lib/armory/ui/TxFrames.py", line 537, in resolveCoinSelection
    raise e
RuntimeError: Invalid spend value
terminate called without an active exception
Aborted


Title: Re: 0.96.4 RC3
Post by: goatpig on January 30, 2018, 02:06:44 PM
ok, 0.96.3.992 started acting up, stuck on Scanning Tx History @1sec:

https://i.imgur.com/H6JG7oZ.png

That's just Qt4 benign spam.


Title: Re: 0.96.4 RC3
Post by: goatpig on January 30, 2018, 02:07:59 PM
Using Bisq's option "Open your external wallet for funding" gives first an error (Invalid spend value) and if clicked a second time crashes Armory.

Not sure if it is Bisq's fault only but Armory shouldn't crash.

Code:
-INFO  - @: (SocketObject.cpp:355) POLLIN recv return 0
(ERROR) Traceback (most recent call last):
  File "/usr/bin/../lib/armory/ArmoryQt.py", line 1759, in triggerProcessMutexNotification
    self.uriLinkClicked(uriLink)
  File "/usr/bin/../lib/armory/ArmoryQt.py", line 2055, in uriLinkClicked
    return self.uriSendBitcoins(uriDict)
  File "/usr/bin/../lib/armory/ArmoryQt.py", line 3518, in uriSendBitcoins
    dlg.frame.prefillFromURI(uriDict)
  File "/usr/lib/armory/ui/TxFrames.py", line 1463, in prefillFromURI
    self.addOneRecipient(addr160, amount, message, label)
  File "/usr/lib/armory/ui/TxFrames.py", line 336, in addOneRecipient
    self.resolveCoinSelection()
  File "/usr/lib/armory/ui/TxFrames.py", line 537, in resolveCoinSelection
    raise e
RuntimeError: Invalid spend value

Traceback (most recent call last):
  File "/usr/bin/../lib/armory/ArmoryQt.py", line 1759, in triggerProcessMutexNotification
    self.uriLinkClicked(uriLink)
  File "/usr/bin/../lib/armory/ArmoryQt.py", line 2055, in uriLinkClicked
    return self.uriSendBitcoins(uriDict)
  File "/usr/bin/../lib/armory/ArmoryQt.py", line 3518, in uriSendBitcoins
    dlg.frame.prefillFromURI(uriDict)
  File "/usr/lib/armory/ui/TxFrames.py", line 1463, in prefillFromURI
    self.addOneRecipient(addr160, amount, message, label)
  File "/usr/lib/armory/ui/TxFrames.py", line 336, in addOneRecipient
    self.resolveCoinSelection()
  File "/usr/lib/armory/ui/TxFrames.py", line 537, in resolveCoinSelection
    raise e
RuntimeError: Invalid spend value
terminate called without an active exception
Aborted


Will look into it. For now, open a Send dialog and set the bitcoin: url link manually.


Title: Re: 0.96.4 RC3
Post by: alomar on January 30, 2018, 03:47:18 PM
ok, 0.96.3.992 started acting up, stuck on Scanning Tx History @1sec:

https://i.imgur.com/H6JG7oZ.png

That's just Qt4 benign spam.

how do i fix it?


Title: Re: 0.96.4 RC3
Post by: johnlu on January 30, 2018, 04:14:30 PM
Did the db crash after this? Hang? Ignored the Node entirely? Client crashed maybe?
hang


Title: Re: 0.96.4 RC3
Post by: goatpig on January 30, 2018, 07:49:33 PM
ok, 0.96.3.992 started acting up, stuck on Scanning Tx History @1sec:

https://i.imgur.com/H6JG7oZ.png

That's just Qt4 benign spam.

how do i fix it?

You learn some Python.

It's benign, ignore it. Put another, what you presented is not related to what you experienced. Either figure it out yourself or present logs.


Title: Re: 0.96.4 RC3
Post by: naska21 on March 04, 2018, 10:22:54 AM
Hi. I wonder if v. 0.96.4 supports Bech32 addresses providing Bitcoin Core 0.16 installed?  And, how stable is it on the top of 0.16 Core?


Title: Re: 0.96.4 RC3
Post by: goatpig on March 04, 2018, 11:00:30 AM
Hi. I wonder if v. 0.96.4 supports Bech32 addresses providing Bitcoin Core 0.16 installed? 

That's unrelated.

Quote
And, how stable is it on the top of 0.16 Core?

There was no significant node changes in 0.16, should be fine.


Title: Re: 0.96.4 RC3
Post by: naska21 on March 06, 2018, 02:52:36 PM
Hi. I wonder if v. 0.96.4 supports Bech32 addresses providing Bitcoin Core 0.16 installed? 

That's unrelated.




OK, will wait for next Armory release and then install Bitcoin Core 0.16 to generate Bech32 address and try SegWit.


Title: Re: 0.96.4 RC3
Post by: goatpig on March 11, 2018, 01:00:26 PM
Read this guide:

https://btcarmory.com/docs/pathing


Title: Re: 0.96.4 RC3
Post by: alomar on March 16, 2018, 08:56:22 PM
is there anywhere in the GUI where private keys are scannable via QR code?


Title: Re: 0.96.4 RC3
Post by: goatpig on March 16, 2018, 09:13:04 PM
I don't think so.


Title: Re: 0.96.4 RC3
Post by: alomar on March 17, 2018, 08:53:22 PM
when Exporting Key Lists, clicking Save File saves them where?  i don't see a dialog box allowing me to choose name or destination.


Title: Re: 0.96.4 RC3
Post by: goatpig on March 18, 2018, 10:56:23 AM
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.


Title: Re: 0.96.4 RC3 - Any ETA for 0.96.4 to be released?
Post by: OtisG on April 06, 2018, 01:09:46 AM
I'm curious if there's an ETA for a release date for 0.96.4?
Armory is my primary BTC wallet, and I'd like to continue using it.

OtisG


Title: Re: 0.96.4 RC3
Post by: goatpig on April 06, 2018, 03:12:46 AM
tagged 0.96.4 earlier this week, have to come up with builds.


Title: HELP! Armory keeps crashing. Unable to gain access to my BTC.
Post by: conchita on April 14, 2018, 02:31:37 AM
I run armory on an external 2TB hard drive.

I transferred some BTC from gdax to armory, and I'm unable to access/see the funds as armory keeps crashing at loading.

Here is the message from ArmoryQT.exe:

(ERROR) ArmoryUtils.pyc:3747 - Unsupported language  specified. Defaulting to English (en)
(WARNING) SDM.pyc:396 - Spawning DB with command:./ArmoryDB.exe --db-type="DB_FULL" --cookie --satoshi-datadir="A:\_Data\_bitcoin-core\blocks" --datadir="C:\Users\lac\AppData\Roaming\Armory\" --dbdir="C:\Users\lac\AppData\Roaming\Armory\databases"
(ERROR) ArmoryQt.py:1188 - 3 attempts to load blockchain failed.  Remove mempool.bin.
(ERROR) ArmoryQt.py:1193 - File mempool.bin does not exist. Nothing deleted.

Would post a screenshot of the error, but don't know how...

Let me know if there's anything else you may need.

Many thanks,


Title: Re: 0.96.4 RC3
Post by: skyhawk on April 15, 2018, 06:04:45 AM
I run armory on an external 2TB hard drive.

....

(WARNING) SDM.pyc:396 - Spawning DB with command:./ArmoryDB.exe --db-type="DB_FULL" --cookie --satoshi-datadir="A:\_Data\_bitcoin-core\blocks" --datadir="C:\Users\lac\AppData\Roaming\Armory\" --dbdir="C:\Users\lac\AppData\Roaming\Armory\databases"
(ERROR) ArmoryQt.py:1188 - 3 attempts to load blockchain failed.  Remove mempool.bin.
(ERROR) ArmoryQt.py:1193 - File mempool.bin does not exist. Nothing deleted.

....

I think your pathing is screwed up, unless A:\ and C:\ refer to your external drive.

See https://btcarmory.com/docs/pathing