Topic: 0.96.4 RC3 (Read 1003 times)

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

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

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,

tagged 0.96.4 earlier this week, have to come up with builds.

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

That's botched, fixing it.

when Exporting Key Lists, clicking Save File saves them where?  i don't see a dialog box allowing me to choose name or destination.

I don't think so.

is there anywhere in the GUI where private keys are scannable via QR code?

Read this guide:

https://btcarmory.com/docs/pathing

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

That's unrelated.


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

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?

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.

hang

how do i fix it?

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

That's just Qt4 benign spam.

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.

ok, 0.96.3.992 started acting up, stuck on Scanning Tx History @1sec:

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

Did the db crash after this? Hang? Ignored the Node entirely? Client crashed maybe?

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.

I'll see next time.


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.

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?

Linux

It seems it does:

Yup.
ArmoryDB aborts and when I start it again, it seems to run fine.

What OS you on? Also, at the moment it happens, does the missing blk file reside on disk? Is restarting the DB fixing it?

Almost once a day.

Consistently?

Getting this error in ArmoryDB:

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

how about search?

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.

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.

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.

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.

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 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.

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.

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, I guess I would stop at the same point as rothbart in the 0.96.2 release thread.

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!

Sorting is a PITA to implement in GUI so don't hold your breath for that one.

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

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.

No to the first paragraph, yes to the second:

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

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?

"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.

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

compile or install?

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

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?

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.

satoshi-datadir does need to be D:\Bitcoin\blocks, but anyway, please post your full logs using this particular flag. Thanks.

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:

Is that the full path where the blockchain resides? It's not in D:\Bitcoin\blocks or something similar?

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:
Let me know if I should provide full logs or do something different.

awesome, been waiting for this one, grabbing now

Verified: the problem with splashscreen freeze that was present in RC2 ('Start in' field in shortcut) is solved in RC3. THANKS!

No problems so far. Thanks, goatpig!

Binaries: https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.3.992

Test away.