This issue should be fixed and the code in a better place atm. It's still wonky in places since I'm in the midst of refactoring the giant hardcoded qt gui files, but at least most of what's left over is limited to Qt5 migration and/or refactoring those files. Give it a spin and let me know.

Sounds like whatever you are running this on lacks some amd64 registries. Try the noasm build instead: https://github.com/goatpig/BitcoinArmory/releases/download/v0.96.5/armory_0.96.5_amd64_gcc4.9_noasm.deb

Disable auto-bitcoind in the Files menu in ArmoryQt.


You need to run ArmoryDB there and remotely connect the client to that. ArmoryDB needs access to the blockchain files on disk. It's simpler to run it along Core and SSH tunnel the port the client connects to.

Caught up in a code review at my job, kinda have to ignore Armory for a week or 2, sorry =(

KDF difficulty is targeted for the machine the wallet is creating, aiming for a 0.5sec unlock time. You can manually set it too. This isn't a version thing, it has operated like this across all Armory versions.


As long as it won't cost you more than what's on the wallet. Ignoring this for a few years and trying again in a few years is a viable strategy too.


You may still have access to the drive the password manager was running on or you can be a little more liberal about your search space if you know that pattern the password was using. The more degrees of freedom you know you can restrict in the search, the more you can broaden the other areas. It's a more efficient way to use your energy.


https://github.com/goatpig/BitcoinArmory/releases/tag/v0.88-beta

And I'm guessing no paper backup?


This stuff supports Armory? Have you tested it? (i.e. create a wallet, give it to btcrecover with 1-2 characters off of the password and see if it can figure it out)


Same test applies.


The fragmented backup vulnerability doesn't erode the security that much. It messes up the SSS setup but there is no real world attack against that. This is all theoretical. The recommendation I stickied here was for people using SSS to proactively redo their backups with the fixed implementation.

At any rate, to even begin exploring this angle, it would mean you have a set of fragmented paper backups. If that's the case, you don't have to crack anything in the first place.


Once you've established that the bruteforce software you're using actually works on these specific Armory wallets, you can start building a strategy to brute force whatever you remember. If you use a typical pattern across all your passwords or use a password manager, that can be useful too. First ensure you aren't wasting energy getting false negatives.

You could setup Core and ArmoryDB on 20.xx and run ArmoryQt in a Ubuntu 18.xx VM.

In this case your only option is to rescan Armory's database. Delete the content of C:\Users\Rob\AppData\Roaming\Armory\databases, start Armory and let it rebuild. Once it's ready, try again and let me know.

Wait so you're not signing a transaction but a message? That algo is different and doesn't use the same code as tx signing.

It's all in jasvet.py (https://github.com/goatpig/BitcoinArmory/blob/master/jasvet.py)

This is some old code that neither etotheipi nor I had anything to do with, it was taken from another dev, we only replaced the RNG with CryptoPP's instead of Python's shitty one. It signs using some python routines and we didn't modify it to support deterministic k generation when that was done for tx sigs.

https://github.com/goatpig/BitcoinArmory/blob/master/jasvet.py#L45

You need to elaborate on this.

What user mode are you in (Advanced? Expert?). Is a wallet selected in the list before you click send? In the bottom left, what's the wallet filter set at? Showing your wallets only? Have you set any wallet as yours?

It's on by default in 0.96.5. You can turn it on with a command line argument in the versions that support it:

https://github.com/goatpig/BitcoinArmory/blob/master/armoryengine/ArmoryUtils.py#L125


For the same transaction? A RFC6979 will only yield the same (R, S) when signing for the same message. When generating a "legacy" ECC signature, you have to make sure you never reuse the same R (regardless of the message).


You already trust it to generate your wallets.


If you present someone with 2 validly signed messages, both of which have the same R but a different S, he can reveal your private key. That aside, I remember some talk ages ago where the claim was made that you can leak bits of the private key when analyzing several signatures, but we're talking hundreds or thousands of sigs to leak a single bit. You'd have to dig that one up on your own, can't remember much more.

To generally answer your question: no.

Make a thread dedicated to your specific issues please. This isn't really the place.

I need to see the whole log file.

Can you post the terminal output for this?

How dare you! :gretaface:

You can create wallets and sign transactions with offline Armory.

To go online you need Bitcoin Core. This is an integral feature of Armory. There has been some work to smooth out the connection between clients and remote dbs in the upcoming release but in general you are expected to run your own instance of Core. If you don't see the value in that, then Armory isn't for you.

Sorry, I'm still in the middle of a few major changes.

Connectivity between ArmoryDB and CppBridge should work. You should see a "Registered bdv xxxxxxxxx" in the db logs/command line prompt on successful connection. You should run both cppbridge and armorydb with --public at first, easier to setup this way.

The testnet flag is for the db to parse the Bitcoin testnet. If you start the db with --testnet, you need both ArmoryQt and CppBridge to run with --testnet.

For now CppBridge automation is a bit off. I suggest you comment out this line to prevent automation and spawn CppBridge yourself with the relevant command directly.

https://github.com/goatpig/BitcoinArmory/blob/dev/armoryengine/CppBridge.py#L88

As for BIP151.py, you have to build it manually atm, after building the rest of the code. You need to run the command from within the c20p1305_cffi folder to generate the python lib:


The import for this library a custom path atm. I haven't really dealt with the whole build/deploy/automation part yet, as you can tell. I suggest you change the import path to something more generic (seen here https://github.com/goatpig/BitcoinArmory/blob/dev/armoryengine/BIP15x.py#L19), such as:


to:


It should work at this point, although I ran into a circular import issue while converting some more GUI to qt5 and decided it was time to refactor the GUI files (qtdialogs.py has some 13k lines of code implementing most of the GUI, and it gets imported everywhere). Then I had to deal with an issue with the mempool code (it starts choking around 100k tx) so I had to drop progress on the GUI for a few weeks unfortunately.

2. There is no such feature in Armory. Unless you went out of your way to do it manually, I don't expect that to be the case.
3. You need to elaborate on how it fails. Are you getting an unexpected wallet id? Is nothing happening instead?
4. Logs would give me a clue as to what the failure is. Again, idk how you'd end up with encrypted SP pass unless you did that manually using some 3rd party software.