0.96.4 RC3

[bwhm]

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.

[1714975051]

1714975051

[1714975051]

1714975051

[bwhm]

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.

[droark]

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.

[bwhm]

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.

[bwhm]

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.

[alomar]

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

how about search?

[goatpig]

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.

[johnlu]

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

[goatpig]

Consistently?

[johnlu]

Almost once a day.

[goatpig]

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

[johnlu]

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.

[goatpig]

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?

[johnlu]

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.

[goatpig]

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.

[johnlu]

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

[goatpig]

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

[alomar]

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

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

[alturigo]

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

[goatpig]

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.