They try to support it. None of our devs are involved though.


What version of Armory are you using?

Armory doesn't support BIP44 atm, that's in for the next version. So you'd have to input the public keys manually, Armory won't be able to generate these for you from your seed. If you want so sign those coins out of multisig script with Armory, you will have to import the underlying private keys too.

After that, you have to pick your MS script type. I suggest you pick the P2WPSH.

At any rate, addresses in your case are not useful, you need the straight up public keys. You cannot create a multisig script from addresses, as you cannot yield public keys from addresses.

In /home/jacob/.armory/, create a file named armorydb.conf. In there add this one line and save:


Try again and let me know.

Doesn't look like you told Armory where to look for your custom Bitcoin data folder.

In Files > Settings, second second section from the top, set your custom folder and try again. Make sure there are no zombie instances of ArmoryDB first.

Changes are taking place in the dev branch. A lot has changed and there's still a lot I want to add in there. The work is split with helping another project. Most of the progess with that project is shared with Armory and the code ends up in the Armory repo eventually.

The main bottleneck atm is moving from SWIG to another C++ to Python framework to allow for a shift to Py3 & Qt5. Also need to go over GUI for the new wallets. Mostly, the GUI needs to represent BIP32 wallet branches.

I dont know what that is =/

Definitely try the noasm builds.

It gets reported in the log files.

1) Delete the content of this folder:


2) Make sure no instance of ArmoryDB is running.

3) Start Armory.

Core is failing to start in the first place. Please run Bitcoin-Qt manually and report.

BIP32 is in there. My main concern atm is migrating away from SWIG to cppyy (for py3 and eventually qt5 support). Then I need to get the new features in the GUI, and only then can I look at HW wallet integration. However I'm not doing that stuff alone, there are people offering to help and/or currently helping with the process. I have given up on ETAs a long time ago, I never hold them. I'm really hopeful to deliver a lot of stuff this year, the universe willing.

There are no unspendable address types in the context of SegWit, quite the opposite actually: SegWit scripts are anyone-can-spend prior to fork activation. This is irrelevant on the Bitcoin chain, but on BCH (and whatever fork that does not have SW), mistakenly sending coins to a SegWit script will lose you the money (to a miner most likely).

The most realistic way to blackhole coins is to send them to a script hash that has no known preimage. You could also construct scripts that can't be spent from at all (always interpret to false), but in both cases this is not related to SegWit and is rather an issue of bad wallet implementation.

I guess there could be a semi easy way for a wallet dev to bork SegWit script generation in code, but he'd catch it right away on the testnet.

Another potential way to mess up is to swap script types around. A buggy wallet could grab the public key hash from a P2WPKH payment address and construct a P2PKH output script instead, which may result in the receiving wallet to never see the payment. The coins are still redeemable, but in this case the recipient will most likely fail to see it on chain, since he isn't looking for that script type in the first place.

None of these potential snafus are stuff you can achieve through a wallet GUI. Basically, the only way to mess up this bad is to craft your own tx manually.

Try the noasm .deb

Download your distro installer ISO from the online machine. On the offline machine, set the iso as a file:: source in your sources.list. Then you can apt-get update and apt-get install.

Start ArmoryDB from the command line


What happens?

It's XOR'ed with the rest of the entropy gathered for wallet seed creation.

Oh right, forgot about that mod.

Updating the lib on your system won't do anything. As I mentioned previously, the CryptoPP source is copied as is in the armory repo, and statically linked to boot. It literally ignores what your system is carrying. You would need to pull the source from CryptoPP's repo, copy it over that source in the Armory repo (/cppForSwig/cryptopp) and build that to effectively update the lib.

This may not be relevant however, since your discovery suggests the issue has more to do with Qt4's interaction with the X server (or PyQt4 for that matter).

This may have to do with CryptoPP optimizations then. Try updating the lib (it's just copied in the Armory repo).

Unless you can get the code to spit some sort of log info, I can't fix this without looking at the issue in a debugger. I guess one idea would be to try and reproduce the issue in an Android VM, if that's even a thing.

Another idea would be to try to get an x86_64 docker container to run on your phone and run the regular linux release binaries.