At its heart, the coldcard issue is bad entropy, which is the worst kind of vulnerability in cryptography. This is because so long as it is known you've used weak entropy, anyone can attack you. Attackers do not need to breach your system first. The issue didn't exist at first in coldcard at first, it was introduced by successive rewrites of the codebase, where the primary purpose to migrate software license. There is no known entropy issue at the time in Armory.


Think of AI as throwing a million security experts at a piece of software. The general expectation should be that if there are vulnerabilities, they will be found. In the long term this is a good thing, as it reduces the surface for 0-day attacks. This is where only the attacker is privy to the vulnerability, so he has plenty of time to exploit it.

In the now, I would be lying if I told you I know for a fact there are no vulnerabilities in Armory.
I believe the wallet, signing and underlying cryptography code are free of vulnerabilities, with a high degree of confidence, but I don't know.
I am always looking for new steps to increase that degree of confidence, and I stake my own coins on it, but all I can honestly offer you is a degree of confidence.
If you cannot read code or will not do your own audit of the code, all you get to rely on is mine and others' degree of confidence.

This is why institutional custodians use key ceremonies and multisig setups, where each set of keys is generated with a different piece of software/hardware. At the extreme tip of secure setups, no one trusts a single piece of software/hardware to secure coins. It's always a mix of them, to reduce the impact of unknown vulnerabilities.

I'm just slow T_T

It has db trouble, no known issues with the wallet code. If you have a blockxor copy of the chain, the db won't sync properly. The rc1 build is for windows. If you are on linux, consider building from the 0.97_rc2 branch to get the outstanding fixes.

I have to leave tomorrow for another 2 weeks. I wanted to push RC2 before that but I'm unhappy with the state of the code still, in no small part due to the behavior on Windows. It's unfortunate but RC2 will have to wait until late July. I'll be pushing code in between, but won't have access to my offline signing setup to formalize a release. I may yet manage to wrap up all I want for the RC before I'm back, so people who build from source may get to try it out early.

I don't take donations atm. Happy to hear it worked. If you want to help, try RC2 when it comes out =)

I've fixed the logging issue locally along with the connection timing, but the bug you found needs dealt with too. I'm pushing my own stuff to the core_tab branch while dealing with a PR from another contributor. It will all be merged down into the RC2 branch eventually, then onto fixing the Windows build and pushing out binaries.

I think I figured out the autodb issue. The client tries to connect to the DB before it starts listening to the port. I'm improving the flow there while I add Core automation. It should be fine for RC2.

Core downloads blocks, checks the content then commits it to disk. The commit part is what failed. There are various causes for this, from a freak accident at write time (very unlikely), to your drive have dead/damaged sectors (possible), to some OS event messing with the write (like the system going into sleep/suspend as the data is being pushed to the drive).

Reindexing is a long process, but it will fix the symptom. It's worth checking your drive's health prior to that. If it is in fact a bad drive issue and not just bad luck, you'll want to fix the drive or copy the data to another one before reindexing.

Not much to see unfortunately. DB suppresses most logging in automated mode. Since you're building from source, go ahead and disable that then try again (make it LogLvlDebug" in all cases):

https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/main.cpp#L63

First log you posted shows ArmoryDB failing to read up new blocks from the chain data on disk. Is there maybe some permission snafu at play?

If you go for a fresh sync of the blockchain on whatever machine, make sure pruning is turned off.

Nah it's me who's causing trouble by not pushing out updates fast enough. Don't worry, we'll get you out of this bind eventually (TM).


This is not related to your wallet. Orphan chain in the ArmoryDB context means it found a bunch of headers that don't connect to the main branch. This either means your copy of the blockchain is missing the one header that connects this chunk to the main chain, or ArmoryDB is failing to pick up that header. Seeing as I'm experiencing the same issue and the parser code was just updated, it's very likely it's a bug on my end. Hang in there, I should fix it soon.

I have to rework the thread scheduler to get it to control RAM usage. That won't be until .1 unfortunately


That means the connection is established (since you are presented the DB key on the client side), but it chokes past that point. I would need to see full logs for the DB to figure this out.

You will have to wait about a week. I have managed to get the orphan chain issue on my laptop, I'll start debugging it soon, at which point I'll push a new RC with a set of fixes. That should get your further along hopefully.

It's managed to spawn ArmoryDB succeffully, but it failed to connect to it.


You are getting this because the migration process of this wallet was halted halfway through.
You can nuke key files safely, they're used for adhoc key handshakes between client and db during the automation process.


Try this again. Run it with "--public", give it an empty password when it prompts for it and let it run. Try to connect to it via the "connect to ip"  option in the "connect to remote" option. DB should reachable on port 9001 over 127.0.0.1

You do not need to unlock your original wallets. Do you see balances yet? So long as you see balances, you can create an offline transaction to sweep out the coins.

Make sure to cleanup your armory databases folder before switching to the new version

Something looks very wrong with your blockchain data. Organizing chain should take ~60sec at most, even on old hardware. Your top block is over 100k behind current top.

Whether you resync the chain or not (SSD is preferable at any rate), try the release candidate for the new version first: https://github.com/goatpig/BitcoinArmory/releases

The imported address issue handling is now fixed in the RC2 branch. I have to update the build instructions and write a changelog but I keep on procrastinating.

Thanks for the testing, much appreciated.


Ah yes, I ran into this recently as well. Only the release tags build without pain. I need to update the build instructions.


Can you give me the output of "gcc --version" and "cmake --version"?


Reading the man-page for open and it says indeed that the mode bits need set when using O_CREAT. Good catch.


I guess the build instructions aren't clear. On linux, you either use your system python, for which packages are installed via your package manager (for version matching, license compatibility and what not). These are your apt, yum, pacman. Or you create a virtual python environment, known as venv. In a python venv, you install packages via pip. Pip will warn you if you try to install packages for the system python.

I test using a venv, and recommend venv over system install. From what you're describing, specifically the system package arg, I'm assuming you're trying to use pip outside a venv. I'll do a pass on the linux build instructions to make things clearer.


I'm implementing thesetting manager's Core tab for RC2, it should make that stuff smoother.


I'm surprised I never ran into this on my own. This happened when it tried to open the backup wizard?


SNAFU on my behalf, will fix.