Think of entropy as search space:

1) By using brain wallets you will most likely reduce your search space per byte from 2^8 to 2^6 (A-Z a-z 0-9 and some punctuation signs). On a 32 bytes/characters passphrase that's significant, and that's assuming people use passphrases that long.

2) To support such long passphrases people will probably resort to mnemonics. This will crush the search space to brute force your key, opening up the way for dictionary attacks and rainbow tables.

3) People who would rather not resort to mnemonics will reduce their passphrase length and expose themselves that way instead.

4) 2 sha iterations for a password derivation function is terribly weak. It's not unusual to see forum passwords hashes at 10k+ iterations. At least use something like scrypt to involve some RAM in the derivation function (like it's done in Armory as an example)

Overall you are taking these comments as attacks directed at you, when they state a couple simple truths: not everyone understands entropy and it's consequences, and less informed/involved users will usually turn towards the simplest solution.

Also you fail to see our standpoint. We can't support a tool that will have users do stupid things and lose coins, because we'll end up being liable in some way. We are an open source company. We don't have the resources to support customers who won't follow the proper security guidelines, so we simply won't promote bad practices.

Make a ticket, attach your log files

https://bitcoinarmory.com/support

Not necessarily. There are 4 steps to integrating a hardware wallet:

1) Implement the standard. That's a one time cost, but there's no knowing which BIPs future hardware wallets will require.
2) Communication layer. With Trezor that part is overly simple (for us, we use Python on the front end), but again, no guarantee other wallets will go down that path.
3) UI integration. A portion of the Trezor code can be recycled for new wallets, but maybe not as large as we hope.
4) Unit tests. Depending on how many features the hardware wallet supports and its API, this can take its sweet time.

The good side is that we will most likely release support for these devices in the form of plugins, so it won't have to wait for a major release.

Trezor support at best in the next release, that's late October/early November if everything goes according to plan.

I think there is a confusion here. When I say the blockchain, I am NOT referring to Blockchain.info, only to the actual blockchain.

Generally, the only risk you expose yourself to by exporting public keys from Armory to an web wallet is de-anonymisation. You are trusting a 3rd party with informations about coins you may be controlling, but it isn't enough data to reproduce any other addresses on your public chain. However I'm unsure this is the scenario you are referring to and what you mean by "transferring coins".

Also I wonder if you are trying to mean more than just the ripemd(sha(sha(pubKey))) + checksum when you use the word address.

For the sake of the discussion: privKey -> pubKey -> bitcoin address. These are all distinct values with different purposes, and you can't perform any of these operations backwards.

Your public addresses lay unencrypted on an online machine so anyone with access to that file has your entire WO. However, someone that identifies any amount of your addresses on the blockchain cannot compute any other address without the chaincode. Even if they identify 2 consecutive addresses, since the multiplier (pubKey N XOR chaincode) is hashed before the modulo multiplication, they can't retrieve your chaincode from that.

The chaincode is never used on anything that hits the blockchain, so any amount of blockchain only data cannot be used to compute any keys on your chain. The chaincode is an Armory only thing and completely alien to the Bitcoin protocol. So someone trying to reveal your public chain has to go after your wallet file.

The consistency check at start up runs in its dedicated thread. If you don't see a progress bar in the bottom left corner then it isn't running at all. The consistency check should be disabled by default on ARM archs (i.e. RPi) I'm asking partly to make sure this is in place.

As for the signing, this may be a first time thing only. I presume you initiated the offline transaction from a WO with some history already. It is possible it picked a change address that wasn't on the restored (RPi) full wallet chain (yet), or that it was on the chain but deep enough that it triggered a chain extention (which comes in batches of 100 addresses at a time).

Did you try signing another transaction with that wallet?

Was the wallet consistency check running by any chance?

TLDR: if you expose a private key from your wallet's chain, the wallet is fully compromised, period.

The extention code uses a modulo multiplication to get privKey N+1 from privKey N. The multiplier is pubKey N XOR chaincode.

So if:

a = privKey N
A = privKey N+1
M = pubKey N XOR chaincode
G = secp256k1's order

We have:

A = a * M (mod G)

This is also true:

A * M^-1 (mod G) = a * M * M^-1 (mod G) = a

Sure you can't get pubKey N from pubKey N+1, but that's irrelevant in our case. A single private key N and your chaincode will reveal all private keys past N. Any private key N + chaincode + all your public addresses from 0 to N-1 will reveal your entire wallet.

Since the chaincode always comes with the precomputed public keys, it is safe to assume that if an attacker can get your chaincode, he can also get your public keys. If he gets access to a single private key, you are kebab. So just don't do it. Private keys are meant to remain private.

The encryption code uses scrypt's precursor to derive the encryption key from your password (that's to reduce the brute force attack vector). When the wallet is encrypted for the first time, Armory defaults to a flat derivation processing time (I think ~2sec).

That time is obviously based on the performance of the machine encrypting the wallet. Take that back to a RPi, and what was expected to be 2 sec will become much longer. You can manually set the kdf size for your wallet in order to reduce that time. Or restore the wallet through your backup on the Pi and encrypt from it instead.

There is also another case. If your wallet has address entries without the private keys (if you extended the chain without decrypting the wallet first), it will have to compute the missing keys up until the highest one needed in for the transaction to be signed, which is outrageously long on a RPi. This will only happen once per missing key however.

This can all be part of a plugin for sure.


As long as your wallet is either encrypted or offline it can't spend coins for you. It could however prepare a transaction for you to sign at the due date.


There are plans to add a price ticker plugin.

Make a ticket, add your logs:

https://bitcoinarmory.com/support

The only DB mode available in current Armory releases is DB_BARE. For supernode, try it out in the charles_refactor_blockchain. It may not be stable just yet. I have to finish paging UTXOs and I'll give supernode its finishing touch.

Etotheipi started with Python for the following reasons:

1) He loves Python
2) Cheaper to develop the frontend with Python than with C++
3) SWIG is really easy to use
4) Can leverage a lot of existing Python libraries for alternate stuff that don't need to be in the backend (networking, system calls)
5) Ask him directly =P

To get PrivKey key X+1 from PrivKey X (and thus any X+n), you need, besides the private key, the chaincode, which is XOR'ed with PubKey X to produce the final multiplier. Thus you can compute forward if you have both, but not backwards (need PubKey X-1 to get the previous multiplier). Obviously I'm not considering a factorization breakthrough that weakens secp256k1.

If what you got from my post was that private keys were derived off of themselves without an outside multiplier (the chaincode), then I apologize for the poor wording. Obviously you need the chaincode. As a matter of fact, in older paper wallets, the chaincode was randomly generated (it's derived from the root key now), and thus the backups came with 2 values: the root key and the chaincode. Losing the chaincode then was as bad as losing the root key.

You should still consider your wallet compromised if you reveal a private key from its chain. The chaincode is considered public data. It lays unencrypted in all wallets (WO included), to extend the public key chain. Armory picks a new public key from the top of the chain every transaction as its change address. With enough transactions, your change will hit keys beyond the private key you revealed and your coins will be as good as gone.

As opposed to the original specification for BIP32, revealing an Armory chained private key doesn't give up your entire wallet so you still have time to move all 'em coins out.

All of the calls from testswig.py that you've reported failing have been deprecated long ago. If you want up to date Python tests, look at the pytest folder in dev. You can look at the blockutils tests in the C++ unit tests for C++ examples on how to get the BDM started and querying data.

Don't expect testswig.py to get up to date until the new backend is merged in dev. CircusPeanut and Doug are away until some time after September 3rd. They've been maintaining the Python unit tests so you'll have to wait until they're back to ask them questions about those or report snafus. I've been spending 95% of my time on the new backend for the last couple months, so you can ask me about that instead.

That won't do either. You're gonna have to do it the sneaky way. You may want to backup your entire bitcoin folder if you don't want to possibly have to redownload the blockchain.

Then delete the chainstate folder, and the rev files in your blockchain folder. Rename your block files so that they start at 00000: if you start at blk00001.dat, make it 00000, then rename blk00002.dat to blk00001.dat and so on. The files have to start at 0 and named consecutively. Then start BitcoinQt. It will notice the missing DB and reindex the blockchain. This isn't the same as downloading it, it won't be grabbing the data, just rebuild its DB. It should take 1-3 hours based on your system.

Then go to your Armory datadir and delete the databases folder. Start Armory and let it do its thing.

Which branch did you pull? You should pull dev, it has up to date Python unit tests. Some of those in master have been neglected or totally replaced in dev.


It isn't "that" simple. If you use Armory bare mode, you have to create a wallet, add the scrAddr, register the wallet and let Armory scan it (20~40min). If you want instant returns you need supernode, which is still being worked on in charles-refactor-blockchain. Careful as this branch gets some large code changes on a regular basis. It has also diverges a lot from other branches (overhauled back end and stuff), but it will eventually be merged into dev.


Include the source directly in your project or build a static lib and include the headers in your own project. You can look at the C++ unit test for an example of a SWIG-less build.

The satoshi client doesn't really care, it relies a lot on its DB instead of the raw files. It wouldn't know unless asked to fetch this data in particular. You could add an empty blk00000.dat and see if it works, but I'm pretty sure Armory will want to see the header magic bytes before moving on to the next file. Worth a shot regardless.

Did you check this folder: C:\Users\Chris\AppData\Roaming\Bitcoin\blocks\
Does it have a blk00000.dat?

Is there a privilege snafu?

Make a ticket please, and attach your log files:

https://bitcoinarmory.com/support/