For what it's worth, I've been using a trello board recently to plan out Armory development. Obviously it's open, nothing to hide in an open source project =D. Feel free to check it, though don't expect it to progress daily! Also, this is an opportunity to take the development discussions into its own topic, instead of having it scattered across many unrelated topics. Therefor, feel free to ask your questions here, even old, recurrent ones.

https://trello.com/b/wJOsu12D/dev

You can spend to bc1 addresses in 0.96.5.

0.97 can generate them (my current spend wallet uses bech32). It's not very user friendly yet however.

I'm considering a scheme for blocks over P2P that could work with pruned nodes too. It's meant to work with full nodes but it "could" be used with pruned nodes too. The idea is to create a sort of reverse bloom filter of all addresses in the chain and hint block scanning from these hits. Would probably reduce the average wallet scan to ~1k blocks instead of some 800k. You'd be able to build this filter map from your own block data but you could also download it from somewhere else, and unlike block files, the data wouldn't vary. This was an idea originally emitted by Olaoluwa Osuntokun from Lightning Labs to build some sort UTXO map side data per block  (a wet dream for lightning devs). It applies quite well to addresses.

In this mode, ArmoryDB could grab the few blocks it needs to scan over P2P, and a node could be bootstrapped by downloading the filter map. It could also scan any address relatively quickly, and work against any Core node. The drawbacks are that it would require more disk space (up to 5% of the chain I assume), and it would leak privacy to the Core node you're getting the blocks from (assuming you're lazy and didn't download the chain/are using a pruned node).

It doesn't fix the issue in Core however. Core tracks blocks by offset as well, mess with its blocks file and it will ask to re-verify the whole thing.


You could also sustain that data some other way. The point is that it would be available to export and import.


To sign the data means you're carrying a private key. This is a fair assumption for signing a tx in a multisig setup, but not for sharing meta data across time for a simple online WO + offline signer.


You can't assume if you generated the data or not in this setup, the only valid assumption is that you and whoever wrote the message know of its content. Encryption without authentication isn't useful all that often. This scheme needs some identification layer as well to work.


VFIO passthrough works pretty well with kvm over qemu, but CPU performance is pretty muted I find. For the most part, cache and RAM timings are quite eroded, I remember messing a lot with cgroups to recoupe some performance. It kinda turned me off the whole thing.

You should be using pastebin for logs this big. Feel free to clear the Armory logs too so as to post fresh ones. From the looks of it you're at file 36XX, so another ~25GB worth of data needs parsed. There's no evidence it's stalled in the logs atm.

Worst case scenario, delete your database folder: "C:\Users\Rob\AppData\Roaming\Armory\databases". Then restart Armory, see how that goes. Moving the core files around is a good way to break Armory's DB, as it doesn't copy the block data, but rather tracks offsets for each block in the Core data.

Current block file count is near 3600. Yours stop around 3080? Your blockchain may be missing some data. Can you start Core and check if it's up to date?

Headers first, which are handled across multiple threads. Each valid header (where the PoW checks out) is queued to be written by whatever thread checked it, so blocks often end up out of order on disk past the last height milestone (process is single threaded up until then), which was around 420k? Core discontinued that milestone ever since, AFAIK.


Transaction keys are 6 bytes long. For a tx, the 4 first bytes identify the block, the next 2 are the txid. For ZC, the first 2 bytes are a marker (0xFFFF), last 4 are the zcid (internal counter, no relation the on-chain data). On disk, each key is prefixed with a byte to signify the data type. This avoids mixing keys when traversing a dataset. LMDB is a plain <key, value> store, unlike SQL databases it doesn't have a concept of tables and records, so it's preferable to split the keys via some prefix scheme. Therefor all keys end up with an extra prefix byte at the I/O layer.


2 hexits per byte. Each hexit encodes a 16 bit value: 0-9, A-F (I use hexit cause I've seen that once a long time ago and found the naming elegant, I don't think anybody else does =D)


Comments live in the wallet. Address comments are keyed by address, tx comments are keyed by tx hash. Tx comments are resolved at each ArmoryQt load, by checking for tx hashes in the ledger. As long as your DB works, the wallet will find its comments. Where you could lose comments is if you were to create a fresh WO from the offline machine and copy that file over on the online machine. However, if you try to restore the wallet via the "Wallet" menu (be it a file or a backup string), it will detect the existing wallet and offer you to merge the meta data.

I've added a feature to export/import meta data in the new wallet format. It carries out address chain length and comments among other things. Thinking of adding a checkbox in the "Send" dialog to carry the structure along an unsigned tx blob to backup the meta data in the offline wallet. This would persist all that stuff in a saner fashion, though none of that data will be covered by paper backups.

Alan was thinking of a system to share meta data. It was to be an online store where you key your data by some hash that is only known to you. The idea here was to synchronize multiple signers over multisig (something like passing the unsigned tx around between a phone and a PC). Maybe something like that could work to persist wallet meta data, by encrypting it to some private key in the wallet. However there's an issue of authenticity: anyone can encrypt data to your private key. The scheme would need some more thinking to keep the data private. Something to mull over.


The whole Qubes thing still eludes me tbh. I don't know how you put up with it. VFIO over kvm is all I can stomach in terms of virtualization, though I've got some chops with docker now and I plan to make ArmoryDB fully dockerizable at some point.

Can you post dbLog.txt? It lives in your Armory datadir (along with the databases folder).

These symptoms on top of your explaination with db state swaps are making the picture a bit clearer. Armory, like Core, points to block data on disk using offsets. If the underlying block data structure was to change past a certain block, swapping in an old clean DB state would eventually lead to an error where the offsets on record mismatch the blocks on disk.

The DB failure at setup you're experiencing looks like a symptom of that: it is looking for a transaction that it expects exists. It tries to find the relevant block, fails (because of offset mismatch or something else) and falls back to checking the mempool for the tx, where it fails again and finally gives up. You can confirm this behavior by looking at the tx key logged at failure. Unless it starts with 0xFFFF, it's not a zero conf. I'm referring the data logged here:


At any rate, you're likely in for a rebuild & rescan.


It carries the 0 conf transactions you emitted. It doesn't cleanup after itself, but a tx that has been confirmed won't be fetched from there anymore. Deleting this file will wipe out that data. If you have no outgoing ZC at the time, it won't affect you. If you have a ZC going out, it will dissappear from the ledger until it gets confirmed. Basically, it's safe to delete. The regenerated file is empty, it's just LMDB pre-assigning some space for later.


It's hard to tell without a log. I've fixed a few of these bugs on the way to 0.97. Those were not minor changes, I don't think it's reasonable to try and cherry-pick them back into 0.96 for a cheap fix.

It looks like it is trying to grab a zeroconf tx that does not exist in armory db's mempool. It's hard to think of a situation where this would happen (how would it know of a ZC if it's not in its mempool?). One way of getting there is chain 2 ZC and somehow the parent disappears from the mempool. I assume you're left hanging with no transactions showing in the lobby? Try deleting "zeroconf" in your db folder, that will wipe the mempool.

If you used Armory 0.96.5 to create the transaction, the RBF (Replace By Fee) flag would be on by default, meaning you can "respend" your inputs as long as the original transaction has not been included in a block. The transaction would show in a teal line in the lobby's tx ledger, and you would be able to right click it and pick the RBF option, which will let you update the fee.

If you still have coins in the wallet, you can also choose to CPFP (Child Pays For Parent). This is a situation where you create a follow up transaction that spends from the unconfirmed tx (typically your change within that tx) and pays a high fee. This incentivizes the miners to confirm the parent tx (low fee) to get the fees on the child (high fee follow up). In essence, it "pulls" the first transaction along.

To CPFP in Armory, you need to set the user mode to expert, then in the "Send" dialog, the "Coin Control" button will appear. In there you can pick those outputs that are eligible for CPFP (they're listed in their own subtree) and create a transaction that "pulls" them in.

To summarize, you can:
- "respend" the inputs if RBF was enabled at tx creation
- "pull" the tx with a high fee child if it has a change output

You would have to post your log file. You can extract it from the Files menu.

You need the whole blockchain to get Armory online indeed. If you cannot afford this, you can extract the relevant private key from Armory and import into a lite wallet like Electrum.

It should mine eventually. If you're willing to pay more in fees, you could CPFP the output.

If you restored the wallet paper backup, it will look up 1000 addresses ahead in the key chain. This is because in order to find all the coins on a wallet, you have to guess how deep in the address chain to check. Armory overshoots to 1k addresses on wallet restore to be a safe the side.

As an example, imagine you had a wallet with 100 unused addresses (you gave these addresses to people to pay you but never got anything). On the 101st address, there are coins. If the software only checked the first 10 or 20 addresses, it wouldn't be aware of these coins. You as the user would see the wallet seemingly has no funds and you would may get rid of it.

Maybe they just forgot about it until LUKS itself receive a major update. Tends to happen in these large projects, you just don't go around turning stones on stuff that appear to work.


If someone finds a wallet on your system with private keys in it, I think they can reasonably assume the coins are yours. The fact that they have access to the public keys would allow them to trace the movement of the coins too. To improve protection, the new wallet format allows you to encrypt all data in the wallet (not just private keys) with a second passphrase.

This still means the attacker can see your public keys in your local blockchain database. Encrypting that data is a lot more complicated than the wallet, I haven't got around it yet. You'd have to use a supernode to avoid that data leak for now.

In general you shouldn't trust on disk encryption schemes for data at rest as it uses a new IV per block, and the IVs have to be deterministic, when the AES candidates expect randomized IVs (iirc). In this case the "vulnerability" was PBKDF2, which does not actually enforce a hash function nor a number of iteration. I don't expect the first instance of LUKS is using SHA512 nor 512k passes, which is the more common use of PBKDF2 you encounter these days.

Still, even with those parameters, I believe PBKDF2 can be brute forced by a state actor nowadays. It is a bit unsettling Ubuntu would use such a weak KDF when you need to unlock your key only at system start (meaning it's ok if it takes a few seconds, it won't degrade user experience).


The recommendation is to set the KDF manually, which likely can be changed after that fact. Disk encryption schemes do not typically encrypt the all the data on disk with your password. Rather, they encrypt a master key entry, and that master key is used to encrypt the actual data. This allows you to change the encryption key (or parameters in this case) on the cheap. If you really want to be sure of your encryption strength, this is what you need to do. Just updating your OS does no guarantee the default LUKS settings offered by the GUI installer (what most people use unless your an Arch nut) will fit your security needs.


The dev branch does, but it's not user friendly yet. If you want to run 96.5 on Ubuntu 22.04, you'll need to install both py2 and qt4, or setup a 18.04 VM.


Funny you ask, I looked at the KDF code last week. Armory uses Scrypt, which is a memory intensive KDF. The current parameters allow up to 32MB per pass and target a between 0,25 to 2 seconds long unlock based (this is something you can set to its upper bound at wallet creation/password change). I was considering removing the hardcoded limits.

Of the top of my head, to crack a 20 characters password, you would need something like 10^20 attempts per seconds to be able get a solution within a lifetime. If it takes anywhere near 0.1s to perform a single attempt, I don't think there's enough hardware on the planet to handle that.

The tx signing message format was extended in 0.96 to support nested segwit scripts. This means, if you are trying to spend coins from a nested segwit script, Armory versions prior to 0.96 will not be able to sign the transaction. My recommendation is for you to update anyways, seeing your online version is already of the 0.96 family.


You are letting ArmoryQt automate your DB process, so it randomizes the port used. As you can see in your logs, this time around it was:

10038 is a Windows socket error code. It happens in either of 2 cases: the client is trying to connect to this port but there is no service running behind it (meaning the server never started or crashed), or the server is trying to listen on this port, but some other process already bound it.

You're using an old version of Armory, go get 0.96.5 (https://github.com/goatpig/BitcoinArmory/releases)

As for the specific error, likely something is using the port ArmoryDB is trying to listen on.

I'm not familiar with gh-pages, Andy Chow contributed that part, I'll try to look into it too.

I'm abroad to be the best man at my brother's wedding, I'm nowhere near my work setup. You'd have to wait until Im back in late March to deliver that.