/blocks: 278 GB
/chainstate: 4.15 GB


Core saves the chain in datadir. Assuming your system is in C: and your user name is RAM103, it would default to:


Armory saves its db in dbdir/databases. If you do not specify a custom dbdir, dbdir will be datadir. datadir carries the wallets and settings. It would default to:

Block files aren't necessarely 128MB, some earlier files can be as large as 1-2GB.

When you let ArmoryQt spawn the DB, it randomizes the port for the DB and passes it to a cookie file that the DB reads from.

This is telling you there's a zombie instance of ArmoryDB, you need to shut that down.

Are you sure the DB is actually running?

C:\Users\Christian\AppData\Roaming\Armory\databases


https://btcarmory.com/

Delete the databases folder and update to 0.96.5

1) Delete your log files

2) Start Bitcoin-Qt manually, let it sync

3) Start Armory, see how that goes.

4) If that fails, nuke your databases folder (C:\Users\Udeshs\AppData\Roaming\Armory\databases) and try again

No


No

You need the private keys in your wallet to recover your coins. Make sure you have a wallet backup. If you don't, go an make one. Do not delete the wallets/armory datadir unless you are 100% sure you have a backup.

Next step is to start Core and let sync 100%. Then update Armory, delete the databases folder (defaults to ~/AppData/Roaming/Armory on Windows) and start Armory while Core is already running. This should sync and let you spend your coins.

I use a RPi for signing myself, though the carrier is a USB stick (the RPi is never directly connected to my online machine, and it never was connected to internet in the first place).

There has been proposals to either add an audio modem or an animated QR code codec as extra transfer channels. In general smart cards are better than USB keys because the USB protocol and handshaking is significantly richer than that of smart cards, which are only ever storage devices. There's arguable minor benefits to be had from DMA access to the storage device vs going through the driver.

For the more paranoid, you could write the data back and forth by hand, or burn CDs.

armoryd talks to ArmoryDB, not bitcoind. ArmoryDB needs a local bitcoind. Clients such as ArmoryQt and armoryd connect to ArmoryDB only, through a socket. That socket is however not encrypted, so it's on you to secure that stuff.

Most likely the state is lost when the address objects on the cpp side are updated to reflect the new entries.


They are both watching only wallets, but "offline" ones are flagged as yours. The assumption here is that since you have gone out of your way to flag this WO wallet as yours, you have access to the private keys on an offline machine.

Unfortunately there is nothing of note in the log. What you are experiencing is a bug, the tx counts shouldn't be reset after generating an address. There is little point in chasing down this bug, I'm in the process of rewriting this section of code for the next version.

You can export Armory public roots. You'd have to implement the address chain derivation code in php most likely. Your best bet is to setup your stack to talk to an instance of armoryd, which will handle the wallet stuff, spit out new addresses, and monitor the blockchain for you. It works over JSON-RPC.

https://github.com/goatpig/armoryd

Can you post the logs for the online instance of Armory?

Ah I see my mistake now. I didn't think etotheipi's home baked HMAC was still in use. My code relied on cryptopp and now libbtc, which have correct hmac implementations. etotheipi one's botches the pad xoring indeed.


My code uses a proper HMAC implementation (cryptopp/libbtc). I've never ran into this issue because my code rips the chaincode along with the root key from the python wallets in order to convert them to the new format. I went ahead and assumed it generated the chaincode from the root instead, which is why I mistakenly concluded the old python code was using a proper HMAC.

Turns out the new code only generates chaincodes at wallet creation (wouldn't affect preexisting wallets) and when restoring from the root. I have yet to restore python wallets with the new code (they're converted on the fly atm), at which point I'll face this bug directly.

I'm not too sure what's going on here, this was prior to me era of involvement. Armory went through a change in its chaincode generation from v1.35 to v1.35c. Prior to 1.35c, the chaincode was generated as its own PRNG value, with no relation to the root value. As a result, paper backups had to carry 4 strings (64 bytes worth of data).

In 1.35c, etotheipi figured he could generate the chaincode from a HMAC of the root, which led to the current 2 strings backups (32 bytes of data). I have no recollection of ever using wallets with a chaincode generated from the bad HMAC (I've been actively contributing the Armory since September 2014). I'm guessing there is a narrow window during which users have generated wallets with the bad HMAC?

Armory in my dev branch is running off of libbtc instead of cryptopp, and it manages to recover older wallets with the expected data, so I wouldn't be too worried about implementing support for the botched HMAC. I'd just leave that as an unsupported edge case and deal with it when I'd actually run into it, if ever. Keep in mind that the current state of master most likely can't deal with these "bad" chaincodes.

Armory is set to never grab the same address twice. Generating a change address means to increment the use counter and grab the underlying address. You'd need user action to break this behavior, like using the wallet across several processes or restoring the wallet from a backup.

Grab the next unused address in the chain


Scan all 1k addresses in the lookup.

Those are pointing to the dev branch, which is in constant flux. You can look at the code in the master branch:

https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/EncryptionUtils.cpp#L749


Private key N with the chaincode will let you compute all private keys beyond N. To compute private keys prior to N, you need all public keys preceding N as well. Both chaincode and public keys are considered known data (as they lay on online computers), hence the generalization that revealing a private key within the chain is as good as revealing all private keys in the wallet.

Keep in mind that you shouldn't treat soft derived BIP32 private keys with any less care, as the same property applies:


It is good practice to not reveal your wallet's private keys, regardless of the derivation scheme. Consider the wallet compromised if you did, and move the funds out.