Probably not the best place to post this but I didn't want to post a thread because other people have more important problems. I'm with the translations once again, I want to know what the percentages refers to? like 'Wallet: %1' or something similar, they shouldn't be deleted in any case?
Those are format specifiers. There will be strings that go in the place of those percentages that won't be translated. These strings are usually IDs and such, e.g. "Wallet: %1" may become "Wallet: xFjsjKSn" 
Topic: Armory 0.96.1 is out! (Read 6764 times)
Probably not the best place to post this but I didn't want to post a thread because other people have more important problems. I'm with the translations once again, I want to know what the percentages refers to? like 'Wallet: %1' or something similar, they shouldn't be deleted in any case?
What are nested addresses? What is the difference? Sorry, but I couldn't find anything about this on a quick search. Every day you learn something new about bitcoin 
Segwit defines two new output script types, Pay-to-witness-pubkey-hash (P2WPKH) and Pay-to-Witness-Script-Hash (P2WSH). When used as a normal output, those outputs are known as native segwit outputs. However those output scripts could be used as the redeemScript of a P2SH output. When that happens, they are known as P2SH nested segwit outputs. 
I thought that I will send a SegWit transaction to an address that starts with 3.
Those addresses are P2SH nested addresses. Armory will make those in the next version which will have those enabled.What are nested addresses? What is the difference? Sorry, but I couldn't find anything about this on a quick search. Every day you learn something new about bitcoin
I thought that I will send a SegWit transaction to an address that starts with 3.
Those addresses are P2SH nested addresses. Armory will make those in the next version which will have those enabled. How do I generate P2WPKH address?
You can't. Such addresses don't exist yet.I thought that I will send a SegWit transaction to an address that starts with 3.
How do I generate P2WPKH address?
You can't. Such addresses don't exist yet.I assume that the lack of an address makes the option P2SH-P2WPKH to be disabled when trying to send to a self address.
No, that is disabled because segwit is hardcoded to be disabled on mainnet for now. We will be releasing another version with segwit enabled soon.What is P2SH-P2K? Pay to public key?
Yes. That uses compressed keys and that is pretty much the only reason you would want to use it.
How do I generate P2WPKH address? I assume that the lack of an address makes the option P2SH-P2WPKH to be disabled when trying to send to a self address.
What is P2SH-P2K? Pay to public key?
What is P2SH-P2K? Pay to public key?
Yes, you need to have Bitcoin Core installed and fully synced to properly use Armory.
Without Core, Armory has no block or transaction data to work with and no way to broadcast transactions to the network.
Without Core, Armory has no block or transaction data to work with and no way to broadcast transactions to the network.
I downloaded this and I regret it now 
Didn't realize that it had to run a full BTC node in order to be online. So does the wallet actually have a BTC core running in the background. I DID NOT download separately, but the way the dashboard represents itself makes it seem like it is syncing up. It says offline but there is a notice saying "preparing database". In the settings the directory for BTC is blank but again the program is vague in saying that Armory is 'managing' it if blank. There is no indication that Armory cannot find the database.
Can someone tell me whether or not i have to separately download BTC? thx
poorly designed UX imho
Didn't realize that it had to run a full BTC node in order to be online. So does the wallet actually have a BTC core running in the background. I DID NOT download separately, but the way the dashboard represents itself makes it seem like it is syncing up. It says offline but there is a notice saying "preparing database". In the settings the directory for BTC is blank but again the program is vague in saying that Armory is 'managing' it if blank. There is no indication that Armory cannot find the database.Can someone tell me whether or not i have to separately download BTC? thx
poorly designed UX imho
what do i need to do to remedy this. never seen it before:
https://i.imgur.com/bD3SRiT.png
i'd just got done sending a different tx w/o any issues. using 0.96.1 expert mode in Debian VM.
edit:
the tx was marked as Sent. i tried to copy raw tx and broadcast via the Broadcast Raw Tx tool w/o success. blocks are up to date and a Armory/bitcoind restart didn't fix it. so i redid the entire tx again, rebooted the entire VM and finally was able to broadcast the new tx. i hope the old one doesn't show up later :0
https://i.imgur.com/bD3SRiT.png
i'd just got done sending a different tx w/o any issues. using 0.96.1 expert mode in Debian VM.
edit:
the tx was marked as Sent. i tried to copy raw tx and broadcast via the Broadcast Raw Tx tool w/o success. blocks are up to date and a Armory/bitcoind restart didn't fix it. so i redid the entire tx again, rebooted the entire VM and finally was able to broadcast the new tx. i hope the old one doesn't show up later :0
this happened for the second time now.
both times i was trying to send two total offline tx's, one after the other. first works fine but second gets the RPC error.
i assume that once this failure occurs and the second tx was labelled as "Sent", it's no longer possible to broadcast that tx? i tried unsuccessfully to broadcast it with the Broadcast Raw Transaction tool.
what's the easiest way to re-enable the RPC interface?
The second point for which I'll provide a pastebin link, is I can't use the Bump Fee function.
It would appear there's not enough funds left on your output to support a fee bump. You'll have to do this manually.
Hey goatpig, thanks for all your efforts. 0.96.1 has fixed many of the problems I had to get Armory running.
Now, there's two potential bugs I've found using the new version. The forst time I ran 0.96.1, all the addresses I've been using on an old wallet appeared on the "Unused Addresses", even though many of them had been used already. After sending a few txs, this seemed to be corrected.
The second point for which I'll provide a pastebin link, is I can't use the Bump Fee function.
Here's the armorylog pastebin link: https://pastebin.com/hxCKzedr
Again, thank you for all your work.
Now, there's two potential bugs I've found using the new version. The forst time I ran 0.96.1, all the addresses I've been using on an old wallet appeared on the "Unused Addresses", even though many of them had been used already. After sending a few txs, this seemed to be corrected.
The second point for which I'll provide a pastebin link, is I can't use the Bump Fee function.
Here's the armorylog pastebin link: https://pastebin.com/hxCKzedr
Again, thank you for all your work.
Enable your node RPC and restart the whole stack.
what do i need to do to remedy this. never seen it before:
https://i.imgur.com/bD3SRiT.png
i'd just got done sending a different tx w/o any issues. using 0.96.1 expert mode in Debian VM.
edit:
the tx was marked as Sent. i tried to copy raw tx and broadcast via the Broadcast Raw Tx tool w/o success. blocks are up to date and a Armory/bitcoind restart didn't fix it. so i redid the entire tx again, rebooted the entire VM and finally was able to broadcast the new tx. i hope the old one doesn't show up later :0
https://i.imgur.com/bD3SRiT.png
i'd just got done sending a different tx w/o any issues. using 0.96.1 expert mode in Debian VM.
edit:
the tx was marked as Sent. i tried to copy raw tx and broadcast via the Broadcast Raw Tx tool w/o success. blocks are up to date and a Armory/bitcoind restart didn't fix it. so i redid the entire tx again, rebooted the entire VM and finally was able to broadcast the new tx. i hope the old one doesn't show up later :0
Thanks and good to see that Armory is still being updated.
Is there an offline install bundle available for 0.96.1 on Ubuntu and if so where can it be found?
Thanks
Is there an offline install bundle available for 0.96.1 on Ubuntu and if so where can it be found?
Thanks
Hello,
i have a problem to login into my wallet. I have printed all Login Information, Wallet Name, ID Root Key and Chain Code, but I can’t find the paper with the Login Information.
Please help me to login in my Account.
Jeff
i have a problem to login into my wallet. I have printed all Login Information, Wallet Name, ID Root Key and Chain Code, but I can’t find the paper with the Login Information.
Please help me to login in my Account.
Jeff
is Coin Control enabled? GUI freezes whenever i click it.
It is, and it shouldn't trigger a freeze. Post your logs for investigation.
I too have been having this issue with 0.96.1 and 0.96.1.2 RC2. I have some further information regarding the problem, and my armory log, as well. First, I start with a new install of 0.96.1.2 RC2 with an empty ~/.armory directory. I import my online watching only wallet from a digital backup. Armory builds it's database, scans it, scans my wallet, etc. After all this, Armory starts up fine and everything works. Before I do anything, I shut Armory down and back up the entire ~/.armory directory. I start Armory back up, the coin control button/gui works and I use it to create an unsigned transaction. After I have finished creating the unsigned transaction is when the problem starts. Now, if I open the main "Send Bitcoins" menu, and then click the button for "Coin Control", armory becomes unresponsive. I can still move the "Send Bitcoins" window, and the main armory window, but nothing inside the windows will respond to anything, and they will not close/quit, so I have to kill armory-qt and ArmoryDB from the system monitor. After I kill them, if I start up Armory again, the main window and "Send Bitcoins" menu will work but it again freezes when clicking "Coin Control". At this point, however, I can broadcast my transaction after signing it offline, and it will broadcast and confirm. In order to use my wallet again, I shutdown Armory, delete the ~/.armory folder, and restore it from my backup I made before creating the transaction. Now if I start armory up again, it will pick up my new transaction after scanning for a few seconds, and display it with the rest of my transactions. I can now successfully open the coin control menu again. I have included a link to my log file which I uploaded to my github account. My log file contained some information about my transaction, so these parts, and any other parts I thought might be sensitive information, I replaced with X's.
Log file as shown in github interface: https://github.com/UncleHunto/logs/blob/master/armory.frozen.gui.log.txt
Log file as raw text: https://raw.githubusercontent.com/UncleHunto/logs/master/armory.frozen.gui.log.txt
How do I build from python?
You don't. You're on Linux, right? You just do the standard autogen.sh/configure/make procedure, which is for the C/C++ code.
How do I build from python?
Your CPU is old, you'll have to build from source.
Installed 0.96.1.
Logos not appearing Applications.
When I try armory or ArmoryDB in the command line (in the /usr/bin directory) it keeps saying 'Illegal instruction (core dumped)'
Also tried 'sudo apt autoremove' which didn't make any difference.
Logos not appearing Applications.
When I try armory or ArmoryDB in the command line (in the /usr/bin directory) it keeps saying 'Illegal instruction (core dumped)'
Also tried 'sudo apt autoremove' which didn't make any difference.
is Coin Control enabled? GUI freezes whenever i click it.
It is, and it shouldn't trigger a freeze. Post your logs for investigation.
is Coin Control enabled? GUI freezes whenever i click it.
Updating armorydb to 0.96.1.2 fixed this.
Cheers,
Ente
Cheers,
Ente
..a bit late to the show here:
I upgraded armoryqt to 0.96.1.2, armorydb (another machine) is still on 0.96 or 0.96.1 though.
Installing runs fine.
Executing armoryqt gives
Didn't look around more yet. I should upgrade armorydb and/or checkout 0.96.2 tomorrow I guess?
Thanks and cheers,
Ente
I upgraded armoryqt to 0.96.1.2, armorydb (another machine) is still on 0.96 or 0.96.1 though.
Installing runs fine.
Executing armoryqt gives
Quote
-ERROR - ���B: (BinaryData.h:1360) buffer overflow!
-ERROR - ���B: (BinaryData.h:1361) grabbing 4294967295 out of 4325 bytes
in the terminal. And I see no tx entries in the tx history window.-ERROR - ���B: (BinaryData.h:1361) grabbing 4294967295 out of 4325 bytes
Didn't look around more yet. I should upgrade armorydb and/or checkout 0.96.2 tomorrow I guess?
Thanks and cheers,
Ente
The Transaction info dialog [GUI, bottom panel, Transactions tab, context menu, View Details] shows "not in the blockchain yet" for all incoming transactions that arrived during the current session (even after 20+ confirmations). Confirmations and balance are all updated in real time, as expected. Restarting the GUI helps, then it gives me a block and tx #. Probably just the UI not updating.
(No anomalies for outgoing transactions, AFAICT.)
(No anomalies for outgoing transactions, AFAICT.)
I used the word complain in the sense that no one raised an issue with the build dependency, therefor I never gave it much attention. I simply grand fathered it from the legacy Makefile when I reworked the build process in autotools. I seriously have no idea why it was preferred over more common calls to copy files around, but when you've battled autohell for 2 weeks in a row, your bar for acceptable code has long moved from "ideal" to "if it works I'll take it". I'm guessing this is the state of mind etotheipi was in when he wrote his Makefile.
Yeah, I seem to recall Alan stating at one point or another that, at a certain point, he just went with whatever worked, especially for user-donated code to get things like Armory on Macs running. There's quite a bit of leftover technical debt. (Not knocking Alan, just stating facts.)
I certainly didn't mean to complain, sorry if it sounded that way. FWIW, I'm really happy with the direction Armory is going and the pace it's going there is incredible, especially for a one-man show.
I used the word complain in the sense that no one raised an issue with the build dependency, therefor I never gave it much attention. I simply grand fathered it from the legacy Makefile when I reworked the build process in autotools. I seriously have no idea why it was preferred over more common calls to copy files around, but when you've battled autohell for 2 weeks in a row, your bar for acceptable code has long moved from "ideal" to "if it works I'll take it". I'm guessing this is the state of mind etotheipi was in when he wrote his Makefile.
As for the updated build dep instructions, that was PR'ed in, and that's more symptomatic of my build setup than anything else: My machines have had all the stuff I need to build for years now, therefor are dark areas of the build system in the sense that I just have no idea if the dependency is common to most distros or if it's something I'm shoe horning by negligence.
Quote
* 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?
* 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.
For whatever reason, the images in for the deck of cards are being read from the file system instead of the pyqt image resource. It's an easy fix, but again a symptom of stuff I overlook cause my build system is set in such a manner I just don't get to see this bugs. That and the small test coverage I get for GUI.
I certainly didn't mean to complain, sorry if it sounded that way. FWIW, I'm really happy with the direction Armory is going and the pace it's going there is incredible, especially for a one-man show.
Quote
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.
Quote
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.
Quote
* 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?
* 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.
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?
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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://bitcointalksearch.org/topic/m.20477795 if you run into compile error on "non standard" hardware.
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://bitcointalksearch.org/topic/m.20477795 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.
i'm getting this in Debian Jessie:
how do i upgrade to ">= 5.2"? is that GCC?
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?
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
P. S Found how to do it. All you need is to click backup and then export private keys
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://bitcointalksearch.org/topic/m.20477795 if you run into compile error on "non standard" hardware.
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://bitcointalksearch.org/topic/m.20477795 if you run into compile error on "non standard" hardware.
pull out my offline signer
You get some major hip points for that right there!
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
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
i'm getting this in Debian Jessie:
how do i upgrade to ">= 5.2"? is that GCC?
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.
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.
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.
i'm getting this in Debian Jessie:
how do i upgrade to ">= 5.2"? is that GCC?
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?
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.
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?
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):
Note:
0.96.2 is in tow with lots of DB fixes and improvements and offline builds.
https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.1
Changelog (https://github.com/goatpig/BitcoinArmory/blob/v0.96.1/changelog.txt):
Quote
== 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
- 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.
Jump to: