Thanks a lot, will get to it sometimes tomorrow, busy with another PR atm.

First remark, this may seem silly but it is what it is:

The Armory code uses 3 spaces per tabs instead of the usual 4. Your editor is set to use 4 so it auto rearranged a bunch of files (all the new files, as well as completely re-indenting MultisigDialogs.py and Wizard.py). Could you please stick to 3 spaces?

Thanks for the patch! I made a branch with it, named attic_qtdialogs. Ill review the files and ask for changes as I go (if they're too big for a quick fix here and there). You can then contribute updates as stand alone patches. Once I'm happy with it, I'll merge the branch into dev. It may take me the whole week to review the change set, it's pretty big and I'm busy with a few other tasks atm.

Go ahead. It's gonna be pretty hard to back and forth on it though. Please wait till the end of the day however, so that I can push some changes I have locally, so that you can rebase on top of what I'm working against.

EDIT: new code is up.

CppBlockUtils.py was auto generated by SWIG to expose the C++ code. I don't use this anymore so all calls to CppBlockUtils in Python are now invalid and need to be replaced equivalents in CppBridge. They won't look quite the same since with the previous model, the py code would call cryptographic routines directly, whereas I've elected to isolate all of that in cpp binary now.

Most of this you're running into needs to be reworked to fit the new design, and in some cases the entire routine needs migrated to the cpp side still. I suggest you focus on those parts of the codebase that can work without that kind of heavy intervention and list those that require that. I'll get to them eventually.

It looks like the DB is sane, you should start ArmoryQt now while ArmoryDB is running.

This was a C++ library wrapped around with SWIG. I got rid of that. Now there's a stand alone C++ process (CppBridge, I'll probably renamed it to ArmoryBridge in the near future) that handles all things crypto, manages wallets and talks to the blockchain service (ArmoryDB), and talks to the GUI via a 2 way encrypted socket.

All those Cpp.somefunction() calls are dead now. They have to be replaced with TheBridge.somefunction(), assuming the function name is transparent. They probably aren't, I'm trying to migrate all wallet handling and cryptopgraphic operations out of the python GUI and into the C++ bridge. The bridge is essentially a protobuf API service over an encrypted socket, and ArmoryQt is a "dumb" GUI in py3/qt5 (using pyside2).


qtdialogs and qtdefines are waaaay too big. I'm trying to refactor all these dialogs into independant files and fix the circular import issues that is plaguing qtdialogs. I do it as I go: try some feature in the GUI, fix it and refactor its code into a dedicate file. Ideally, I want to isolate all of the legacy GUI this way. Then I can start adding new GUI in its own files using QtQuick (.qml).


This is old crypto code copied into the repo. It was used to sign and verify Bitcoin messages. It used python's own random library to generator the R value (instead of the C++ PRNG), so we stopped using it for signing circa 2014. It was kept around for verifying the signed Bitcoin messages however (since that needs no rng).

You can still find this file in the master branch: https://github.com/goatpig/BitcoinArmory/blob/master/jasvet.py


I removed the module cause it was getting in the way when I started migrating to py3. I haven't gotten around to fixing this part of the GUI yet. It should be replaced by routines from BridgeSigner (https://github.com/goatpig/BitcoinArmory/blob/dev/armoryengine/CppBridge.py#L1128). The code exists in C++ but needs exposed via protobuf, so this one requires some C++ work as well.


Yes. Feel free to PR your stuff, I'll gladly review and merge.

It looks like it updated the chain but has had time to do much more. How long did you let it run?

Back in 2005 I believe, the NSA started a program with the purpose of enrolling US IT companies to spy on their users. Only Yahoo resisted (a bit), everybody else played along. The public got to learn about this thanks to Snowden's revelations, years later. It is a lot harder to corrupt a FOSS project cause the code is out there. It's even harder with Bitcoin cause even if you manage to force trash in the node's implementation, you can't force users to run that code. I think Bitcoin correctly deals with this issue, and while governments can pressure devs, it will only lead to a generation of devs that will protect their identity thoroughly.

I expect it's too late to do this now. The only thing the US will achieve by harassing Bitcoin devs at this point is to drive them out of the US.

Bitcoin attracted a lot of people with a well established background in academic and/or Silicon Valley. These guys are used to building resumes, not hiding their identity. There is also this culture of transparency in the FOSS space, which extends to using your real name. And unless you are as careful as Satoshi, it's unlikely you could effectively hide your identity being active in this space for a decade.

From the the terminal, run ArmoryDB. Post the output from the terminal. You don't need bitcoind running for that.

Can you please make it all text files. ODT I can't read in browser =/. I don't really want to have to download users' log files locally.

This line? Initializer list should build. I'm guessing your version of gcc is older than mine (11.1). Try this maybe:


This is tested here:

https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/gtest/UtilsTests.cpp#L6545

You may want to reduce the search space, this test can be cpu hungry. ("./configure --enable-tests" to build tests)

1. Submodules aren't obvious. Subtrees are a bit better. Submodules need to be setup and updated manually. There is very little indicating that a submodule even exists in a project, let alone that you have to update it. I used submodules before, I've had veterans trip up on it. I have tripped up on it myself. No amount of git pull or git reset in the root folder will checkout the right submodule revision.

2. If you submodule a repo, you have to integrate its build process to yours. This quickly becomes a nightmare if you are using divergent build tools across the project and submodules (autohell vs cmake vs ninja vs whatever else).

3. If you need to amend the code in the helper lib, submodules are straight up useless. You'll need to fork the repo and commit your changes. Then you'll need to keep your fork up to date with upstream, and submodule your fork.

4. If you dont need to modify the helper code, you essentially have no reason to keep a local copy. Linux is designed around system libs, so there is very little extra effort there to use helper libs. On Windows the submodules provide low value, since the lib you're using on *nix may simply not exist for Windows (case in point, GMP vs MPIR).

5. To build against a helper lib, you need the headers and the binary. This means you can inject that at build time and manage the helpers whichever way you want. Copying the code locally removes that option entirely. This will more often than not degrade portability on obscure Linux distros.

Oh sorry, forgot about that one. Don't modify any code, you simply need to build the python module. In the c20p1305_cffi folder, run


This will build the module. The code will find it on its own after that. This is a one time thing, you won't need to rerun that step unless I update that code.

Ah, that won't work. This arg has the configure script expand the custom path with /libs for ld (to find the binaries) and /include for gcc (to find the headers). It fully expects a cloned repo structure, not a system install (where headers and libs are in completely different folders).


It shouldn't diverge that much.


Until recently, Ubuntu didn't package LWS 3+. I started using LWS when Ubuntu packaged LWS1, and LWS2 just had come out with a new model for the main callback. The 2 versions were not compatible but I wasn't going to wait for Ubuntu to catch up. LWS itself kept pushing major releases in quick succession, with minor backwards compatibility breakage (hence the update to LWS3-4, which don't work with LWS2, but work with one another), and now modern distros carry at least LWS3, so it makes sense to finally allow building vs system installs.


There may be some confusion here. When I started working on Armory, the major open source dependencies were copied as is in the armory source repo (besides python). I guess that's what you're referring to when you say "in tree". I'm trying to get rid that practice. At the moment, gtest, libbtc and chacha20poly1305 still exist as copies in repo. LWS, LMDB and protobuf are out. There is no python dependency anymore. My intent is to evict as much foreign code as possible from the repo before the next release. As a result, at least libbtc and gtest will go too, soon.

Libs were copied in the armory source primarily as a way to ease the building across environments. System libs may vary across distros, Mac has mostly been a blackbox and you can't really install system libs on Windows.

The new approach is to get rid of all the copied code, let the default config look for system libs and allow users to feed it adhoc paths to their own builds of the dependencies. This is how LWS is treated and how all libs will be treated eventually. In this scenario, there's no burden to keep updating the dependencies code, while it's flexible enough to eventually build on any system.

I can later add a helper script that will download the source from the relevant repos, build the dependencies and feed the paths to the cmake project to ease as the "easy to build" DIY solution that should work across all OS. I'll keep on using autohell and manual setups on my own system.


Cleaned the warnings and got rid of SWIG, that should have speed things up. Also, computers did get faster since =D.

You can try the cmake project in the cmake_build branch. It runs on system libs only atm. It doesn't have the stuff to build CppBridge yet however, but you can check if armorydb will build correctly at least. To setup the build system, do the following from the source dir:


Then you can call make from the build folder. The binary will show up in there too.

Simplest way around this is as follows:

Clone lws locally. Setup using cmake: you can pick between libevent and libuv at setup time, also I suggest disabling openssl usage if you don't plan on using it. Build it and you're done.
When configuring armory, use the following:

Use this custom arg to point to the root folder where you cloned lws, it should just work. This is what I use when I don't want to battle the system lib. There is also a cmake project in a PR which seems to build just fine with system libs (but doesn't have the custom args to inject lib paths at setup time). I could just fast track that too.


There's no Qt4/py2 left in that branch anymore.

You have to start bitcoind and let it sync. 100k blocks short means you're missing some 25% of the chain? The later blocks are a lot heavier then the earlier ones. This would mean a few extra hours worth of bitcoind syncing to catch up.


I checked the github page your linked in the previous thread, can't find any netstat output.


Type ArmoryDB or ArmoryQt in the terminal to start them. You are "introducing something new" in that approach in that you're not letting ArmoryQt control ArmoryDB, which reduces the degrees of freedom in the stack.

1. Preferable
2. Preferable
3. Fuck up on my part, unlikely you can do something on your end without messing with the python code
4. Yes you can, will increase the complexity of your setup.