Armory 0.96.1 is out!

[goatpig]

Builds available on the Github release page, as usual:

https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.1

Changelog (https://github.com/goatpig/BitcoinArmory/blob/v0.96.1/changelog.txt):

== Added ==
   - Raised default fee to 200 satoshi/Bytes. This fee will apply when using defaults and the node RPC is down.
     Any applied fee lower than that rate will trigger a warning message box. Users have to actively choose to
     bypass the warning.
   - Split unit tests building from default autotools setup. To build tests, use:
      ./configure --enable-tests.
   - You can now disable GUI in the autotools build system. Use:
      ./configure --without-gui
   - When spawned with a cookie file, the DB now randomizes its listen port to (49150 + [0-15000]) and reports it in the cookie file.
   - Added --fcgi-port command line argument to the DB
   - Address comments are now visible again in the Coin Control GUI
   - DB messages now have checksums; this improves error and version mismatch detection
   - Transactions that failed to broadcast throug the P2P layer will now be pushed to the RPC afterwards, if it's enabled
   - Refresh address view in Wallet Properties dialog on several user interactions.
   - RPC status is now signaled in the bottom right corner status bar. Disabled RPC will result in bold purple text.
   - Highly improved DB corruption self diagnosis and automated fixing.
   - Zero confirmation parser pool now is now capped at 100 threads.
     You can modify this value with the --zcthread-pool command line argument.

== Fixed ==
   - ZC parsing will no longer occur while the BDM is initializing
   - Wait on cookie file creation before connecting to auto managed DB
   - Fixed registration/callback premature garbage collection
   - Translation patch issues
   - Fixed "Fund from wallet" lockbox GUI
   - Fixed TxIn/Out pretty printing
   - Tied init phase spinning icon rotation to progress notifications. The icon will not spin when no progress data is received, correctly
     indicating the DB is hanging.   
   - Fixed cryptopp build against older CPUs (no AES or PCLMUL archs).
   - Fixed RBF bumping with no change.
   - Improved timestamps granularity in logs.
   - Improved transaction broadcast consistency.
   - Improved error message verbose of timed out transaction broadcasts.
   - ./configure --prefix now propagates correctly to Makefiles.
   - Fixed several memleaks in the database code.
   - Fixed false positive throws over bad packet detection in socketing layer.
   - Fixed coin selection edge cases.
   - Fixed the displaying of address comments in the lobby ledger.

== Removed ==
   - Python-twisted dependency. This should remove the underlying openSSL dependency as well.
   - Database command prompt will no longer appear when auto managing the DB on Windows

Note:

0.96.2 is in tow with lots of DB fixes and improvements and offline builds.

[pf]

How was the OSX build actually built? Was it actually built on the v0.96.1 tag or not? I ask because one commit after the v0.96.1 tag on the master branch, there is a "Fix OSX build" commit. Was the OSX build actually done on that separate commit?

[droark]

How was the OSX build actually built? Was it actually built on the v0.96.1 tag or not? I ask because one commit after the v0.96.1 tag on the master branch, there is a "Fix OSX build" commit. Was the OSX build actually done on that separate commit?

Yes. It wouldn't build with the 0.96.1 tag (oversight by goatpig), so the fix from testing was copied over. That fixed everything, although the build process is broken again due to the libpng library version in the script being unavailable now. (Sourceforge just deleted that version.) I'll PR a new script in a bit.

[alomar]

i'm getting this in Debian Jessie:

Code:

  debian@debian:~/Downloads$ sudo dpkg -i armory_0.96.1_amd64.deb
(Reading database ... 129820 files and directories currently installed.)
Preparing to unpack armory_0.96.1_amd64.deb ...
Unpacking armory (0.96.1-1) over (0.96.1-1) ...
dpkg: dependency problems prevent configuration of armory:
 armory depends on libstdc++6 (>= 5.2); however:
  Version of libstdc++6:amd64 on system is 4.9.2-10.

dpkg: error processing package armory (--install):
 dependency problems - leaving unconfigured
Processing triggers for libc-bin (2.19-18+deb8u10) ...
Processing triggers for desktop-file-utils (0.22-1) ...
Processing triggers for mime-support (3.58) ...
Errors were encountered while processing:
 armory
debian@debian:~/Downloads$   

how do i upgrade to ">= 5.2"?  is that GCC?

[knahrvorn]

Updating 0.96 to 0.96.1 on Ubuntu 16.04 (by installing provided .deb package) made the graphical icons for Armory disappear. Still able to start Armory by command line, though.

[pf]

How was the OSX build actually built? Was it actually built on the v0.96.1 tag or not? I ask because one commit after the v0.96.1 tag on the master branch, there is a "Fix OSX build" commit. Was the OSX build actually done on that separate commit?

Yes. It wouldn't build with the 0.96.1 tag (oversight by goatpig), so the fix from testing was copied over. That fixed everything, although the build process is broken again due to the libpng library version in the script being unavailable now. (Sourceforge just deleted that version.) I'll PR a new script in a bit.

I can confirm that with your libpng commit https://github.com/goatpig/BitcoinArmory/pull/273/commits/1f4d8d365ad5d91032e57a84d14bbb2e123483d8 fix, things build successfully on macOS! Feel free to merge this into master, goatpig.

[goatpig]

i'm getting this in Debian Jessie:

Code:

  debian@debian:~/Downloads$ sudo dpkg -i armory_0.96.1_amd64.deb
(Reading database ... 129820 files and directories currently installed.)
Preparing to unpack armory_0.96.1_amd64.deb ...
Unpacking armory (0.96.1-1) over (0.96.1-1) ...
dpkg: dependency problems prevent configuration of armory:
 armory depends on libstdc++6 (>= 5.2); however:
  Version of libstdc++6:amd64 on system is 4.9.2-10.

dpkg: error processing package armory (--install):
 dependency problems - leaving unconfigured
Processing triggers for libc-bin (2.19-18+deb8u10) ...
Processing triggers for desktop-file-utils (0.22-1) ...
Processing triggers for mime-support (3.58) ...
Errors were encountered while processing:
 armory
debian@debian:~/Downloads$   

how do i upgrade to ">= 5.2"?  is that GCC?

Jessie is GCC 4.9, I build on Ubuntu 16.04, which is GCC 5.4.

You would need a build with an earlier version of GCC, which I'll add with the offline builds for 0.96.2. For now, you'll have to build from source, which is fairly easy on Jessie.

Updating 0.96 to 0.96.1 on Ubuntu 16.04 (by installing provided .deb package) made the graphical icons for Armory disappear. Still able to start Armory by command line, though.

Will look into it

I can confirm that with your libpng commit https://github.com/goatpig/BitcoinArmory/pull/273/commits/1f4d8d365ad5d91032e57a84d14bbb2e123483d8 fix, things build successfully on macOS! Feel free to merge this into master, goatpig.

Done, will be part of 0.96.2. And yes, I had to cherry pick a commit from testing back into master after I tagged cause I forgot to grab OS build fix PR like an idiot. I wasn't gonna retag cause it's a hassle to pull out my offline signer, and I'm doing a .2 in a couple weeks anyways.

[bobnoho]

noob here,

can somebody here help me? or steer me to a forum that can? I upgraded to bitcoincore 0.14.2 and armory 0.96 on a WIN7x64 pc (acts as a file server so its never off)..
before I upgraded I received a couple payments to my armory wallet no problem, but after i upgraded and 3 days for armory to finaly load I have received several payments,
but all payments I have received are unconfirmed - NOT spendable..

I have not tried the "-rescan" yet as it took so long for armory to load in the first place

[pf]

pull out my offline signer

You get some major hip points for that right there!

[dellech]

I thought it would be a good idea to upgrade my offline signer to a current version. But I had to build from source because I need a 32bit executable (old Pentium M)

Compilation on 32bit x86 showed an error which was already reported for 0.95 - but the OP failed to respond to Goatpig's question about the build environment.
Check my response in that thread https://bitcointalk.org/index.php?topic=1657365.msg20477795#msg20477795 if you run into compile error on "non standard" hardware.

[naska21]

How to export the private key of the certain address from the cold (offline) ARMORY 0.96.1 ? Address Book does not show any addresses/ Under P2PKH is just one word - NONE, nothing else/ The watching only wallet shows list of addresses but is not capable to extract private keys , only public

P. S Found how to do it. All you need is to click backup and then export private keys

[alomar]

i'm getting this in Debian Jessie:

Code:

  debian@debian:~/Downloads$ sudo dpkg -i armory_0.96.1_amd64.deb
(Reading database ... 129820 files and directories currently installed.)
Preparing to unpack armory_0.96.1_amd64.deb ...
Unpacking armory (0.96.1-1) over (0.96.1-1) ...
dpkg: dependency problems prevent configuration of armory:
 armory depends on libstdc++6 (>= 5.2); however:
  Version of libstdc++6:amd64 on system is 4.9.2-10.

dpkg: error processing package armory (--install):
 dependency problems - leaving unconfigured
Processing triggers for libc-bin (2.19-18+deb8u10) ...
Processing triggers for desktop-file-utils (0.22-1) ...
Processing triggers for mime-support (3.58) ...
Errors were encountered while processing:
 armory
debian@debian:~/Downloads$   

how do i upgrade to ">= 5.2"?  is that GCC?

Jessie is GCC 4.9, I build on Ubuntu 16.04, which is GCC 5.4.

You would need a build with an earlier version of GCC, which I'll add with the offline builds for 0.96.2. For now, you'll have to build from source, which is fairly easy on Jessie.

thanks for the quick response and all the great work goatpig.

i'm sure building GCC from source is easy but as you know, Debian is notoriously lacking in backportability (sp?)  Do you think simply upgrading GCC will be enough or are there further dependencies or issues i should anticipate?

[goatpig]

I'm not telling you to build GCC from source but Armory. If you insist on upgrading GCC, that's actually a complicated task on Debian. You'll want to look at the debian-backport repo instead, but I doubt they have a GCC recent enough in there.

I thought it would be a good idea to upgrade my offline signer to a current version. But I had to build from source because I need a 32bit executable (old Pentium M)

Compilation on 32bit x86 showed an error which was already reported for 0.95 - but the OP failed to respond to Goatpig's question about the build environment.
Check my response in that thread https://bitcointalk.org/index.php?topic=1657365.msg20477795#msg20477795 if you run into compile error on "non standard" hardware.

Armory cannot build in 32bit on Windows atm, and I do not intent to do anything about it. The last native 32bit Windows is XP, and Microsoft themselves have dropped support for that OS some years ago.

[pinballdude]

I downloaded armory and started it. It never went online.

Then i dowloaded Bitcoin core and had it resync the blockchain. Core is working fine.

Then i started armory again.

Armory does not go online at all even after hours. Also no indication in the user interface or popups that anything is ongoing or wrong.


got this in the log

2017-07-30 23:51:09 (INFO) -- SDM.pyc:169 - Found bitcoind in the following places:
2017-07-30 23:51:09 (INFO) -- SDM.pyc:171 -    C:\Program Files\Bitcoin\daemon\bitcoind.exe
2017-07-30 23:51:09 (INFO) -- SDM.pyc:173 - Using: C:\Program Files\Bitcoin\daemon\bitcoind.exe
2017-07-30 23:51:09 (INFO) -- SDM.pyc:337 - Called startBitcoind
2017-07-30 23:51:09 (INFO) -- ArmoryUtils.pyc:667 - Executing popen: ['C:\\Program Files\\Bitcoin\\daemon\\bitcoind.exe', u'-datadir=C:\\Users\\denni\\AppData\\Roaming\\Bitcoin\\']
2017-07-30 23:51:09 (INFO) -- SDM.pyc:450 - PID of bitcoind: 6192
2017-07-30 23:51:09 (INFO) -- SDM.pyc:451 - PID of armory:   13616
2017-07-30 23:51:09 (INFO) -- ArmoryUtils.pyc:667 - Executing popen: ['.\\guardian.exe', '13616', '6192']
2017-07-30 23:51:09 (INFO) -- ArmoryQt.py:1913 - Setting netmode: 1
2017-07-30 23:51:09 (ERROR) -- BDM.pyc:200 - DB error: C:\Users\denni\AppData\Roaming/Bitcoin/blocks is not a valid path
2017-07-30 23:51:09 (INFO) -- ArmoryQt.py:1913 - Setting netmode: 0
2017-07-30 23:51:09 (INFO) -- ArmoryQt.py:1895 - loadBlockchainIfNecessary
2017-07-30 23:51:09 (INFO) -- ArmoryQt.py:4644 - Dashboard switched to "Scanning" mode
2017-07-30 23:51:09 (INFO) -- ArmoryQt.py:4644 - Dashboard switched to "Scanning" mode


You need to do path arithmetic with OS specific calls :  2017-07-30 23:51:09 (ERROR) -- BDM.pyc:200 - DB error: C:\Users\denni\AppData\Roaming/Bitcoin/blocks is not a valid path

also, i had thought armory was tested before launch.  i'll get me another wallet.

[goatpig]

I downloaded armory and started it. It never went online.

Then i dowloaded Bitcoin core and had it resync the blockchain. Core is working fine.

Then i started armory again.

Armory does not go online at all even after hours. Also no indication in the user interface or popups that anything is ongoing or wrong.


got this in the log

2017-07-30 23:51:09 (INFO) -- SDM.pyc:169 - Found bitcoind in the following places:
2017-07-30 23:51:09 (INFO) -- SDM.pyc:171 -    C:\Program Files\Bitcoin\daemon\bitcoind.exe
2017-07-30 23:51:09 (INFO) -- SDM.pyc:173 - Using: C:\Program Files\Bitcoin\daemon\bitcoind.exe
2017-07-30 23:51:09 (INFO) -- SDM.pyc:337 - Called startBitcoind
2017-07-30 23:51:09 (INFO) -- ArmoryUtils.pyc:667 - Executing popen: ['C:\\Program Files\\Bitcoin\\daemon\\bitcoind.exe', u'-datadir=C:\\Users\\denni\\AppData\\Roaming\\Bitcoin\\']
2017-07-30 23:51:09 (INFO) -- SDM.pyc:450 - PID of bitcoind: 6192
2017-07-30 23:51:09 (INFO) -- SDM.pyc:451 - PID of armory:   13616
2017-07-30 23:51:09 (INFO) -- ArmoryUtils.pyc:667 - Executing popen: ['.\\guardian.exe', '13616', '6192']
2017-07-30 23:51:09 (INFO) -- ArmoryQt.py:1913 - Setting netmode: 1
2017-07-30 23:51:09 (ERROR) -- BDM.pyc:200 - DB error: C:\Users\denni\AppData\Roaming/Bitcoin/blocks is not a valid path
2017-07-30 23:51:09 (INFO) -- ArmoryQt.py:1913 - Setting netmode: 0
2017-07-30 23:51:09 (INFO) -- ArmoryQt.py:1895 - loadBlockchainIfNecessary
2017-07-30 23:51:09 (INFO) -- ArmoryQt.py:4644 - Dashboard switched to "Scanning" mode
2017-07-30 23:51:09 (INFO) -- ArmoryQt.py:4644 - Dashboard switched to "Scanning" mode


You need to do path arithmetic with OS specific calls :  2017-07-30 23:51:09 (ERROR) -- BDM.pyc:200 - DB error: C:\Users\denni\AppData\Roaming/Bitcoin/blocks is not a valid path

also, i had thought armory was tested before launch.  i'll get me another wallet.

Make your own thread, post all your logs as well.

[Casimir1904]

also, i had thought armory was tested before launch.  i'll get me another wallet.

Its impossible to test a software on every system.
There are testing branches what you could build and report bugs or other issues.
Or you just wait before installing newer releases till others reported bugs/issues.


I'll test this version once the BitcoinABC split is done, lot work atm because of that.

[shogoo9U]

Thank you for --without-gui! That gets rid of all the QT and Python deps in one fell swoop.
And since you're already fiddling with the build system, how about --without-online to build just the GUI part, for offline systems? ^^ That'd probably also make it easier to keep supporting older systems for offline-only use.

Oh, and why do you maintain your own version of libfcgi? Is it just build fixes or is there more? Since libfcgi is pulled in as a submodule after the fact it presumably isn't covered by the main repos signature checks, so if it works I'd rather install libfcgi-dev and be done with it.

[goatpig]

Thank you for --without-gui! That gets rid of all the QT and Python deps in one fell swoop.
And since you're already fiddling with the build system, how about --without-online to build just the GUI part, for offline systems? ^^ That'd probably also make it easier to keep supporting older systems for offline-only use.

Oh, and why do you maintain your own version of libfcgi? Is it just build fixes or is there more? Since libfcgi is pulled in as a submodule after the fact it presumably isn't covered by the main repos signature checks, so if it works I'd rather install libfcgi-dev and be done with it.

libfcgi is statically linked in, and I've modified some of it. I'm looking to do web sockets at some point and get rid of fcgi eventually, so I don't want to struggle through dynamic linking it and all the build process mods.

As for the --without-online part, that's kinda tricky with autotools. It would make the DB compilation part optional as well, and you need a constant baseline to do that optional compilation switching without large headaches.

On the other hand, the DB is pure C++ and shares a few code files with the GUI, so if you can build the GUI, you can build the DB. Therefor, in terms of build process, the DB does not introduce more dependencies so it's the natural baseline.

For offline systems, you'd want to remove the client with --offline anyways, therefor the effort required to allow this at the configure script level is not justified to begin with.

[shogoo9U]

I suppose the same rationale goes for the local copy of crypto++? I'm a bit weary of whole projects of source copied in verbatim in general -- it tends to either remain in the initial imported state forever or drain resources from the importing project (which has just one man, as it stands). Case in point, even Debian stable looks to have a newer version.

A couple of observations / buglets:
* build docs: add pkg-config and rsync, remove python-twisted as build-deps
The build process is a bit byzantine, why does it need rsync at all and why is there so much code being built during make install ...
* pathing 1: apparently, ArmoryDB is expected to be in $PATH (it's called just by name) -- maybe use the absolute path (from configure)?
* pathing 2: the screen that shows the deck of cards seems to be very sensitive. It works, when launched in $PREFIX/share/armory (i.e., directly above img), otherwise I just get blank buttons, like under Windows -- some base path for resources not initialised correctly?

[goatpig]

I suppose the same rationale goes for the local copy of crypto++? I'm a bit weary of whole projects of source copied in verbatim in general -- it tends to either remain in the initial imported state forever or drain resources from the importing project (which has just one man, as it stands). Case in point, even Debian stable looks to have a newer version.

That's something I inherited from the previous maintainer. I want to move to libbtc.

The build process is a bit byzantine, why does it need rsync at all and why is there so much code being built during make install ...

Inherited that too, no one has complained about it either. As for the stuff being built by make install, blame SWIG, or Python in general.

* pathing 1: apparently, ArmoryDB is expected to be in $PATH (it's called just by name) -- maybe use the absolute path (from configure)?
* pathing 2: the screen that shows the deck of cards seems to be very sensitive. It works, when launched in $PREFIX/share/armory (i.e., directly above img), otherwise I just get blank buttons, like under Windows -- some base path for resources not initialised correctly?

Will have to look into it.