You can receive coins with offline Armory, but you can't spend unless you get Armory online. So get Armory online before you fund your wallet. Common sense. Also, you have to read the tutorials and get familiar with Bitcoin and Armory to get it online. After all, Armory requires a full node.

On the other hand, starting offline Armory is cake and any Bitcoin inept can go as far as creating a wallet and funding it. Then comes the day you want to spend these coins and you realize you don't even have an adequate machine, or have never downloaded the blockchain, and best case scenario, you have to wait a couple days to spend your coins.

So do yourself a favor and make sure you can go online first.

Please make sure you can get Armory online first.

1) I didn't read the tutorial, hence idk

2) For offline signing, 12.04 or 14.04 LTS are your better choices. We have offline bundles targeted specifically at those. For the online counterpart, frankly anything can fly as long as you have the necessary hardware resources, granted OSX is the least stable of all due to its love/hate relationship with Qt4.

3) https://bitcoinarmory.com/download/building-armory-from-source/

4) I got no idea, but I suspect you can somehow find equivalent command line calls in OSX's terminal. Either that or run a Ubuntu/Debian VM on your OSX and do it from there.

5) Afaik, if none of the files in the USB have the exe bit set, they can't run, so maybe a chmod -R 600 ./* would make you feel better. Generally, if the attack medium is something as trivial as an autorun file, you'll catch it with a little scrutiny. If it's something like the Stuxnet USB rootkit, you're kebab anyways.

Reassigned you to CircusPeanut, he should fix that for you.

Coin control gives you control over addresses but not UTXOs. An address can have several UTXOs and in that sense coin control doesn't give you the necessary control to spend that one. Make a ticket (https://bitcoinarmory.com/support), link to this thread and one of us will craft you a custom unsigned transaction to spend the left overs minus the dust.

Toy around with the wallet filter, that should help.

If you use auto managed bitcoind, it will be ran monitor the bitcoind instance spawned by Armory. If Armory was to crash, it will kill that bitcoind instance and exit.

Address chain extension:

https://github.com/etotheipi/BitcoinArmory/blob/master/armoryengine/PyBtcWallet.py#L1047

Deriving the first key:

https://github.com/etotheipi/BitcoinArmory/blob/master/armoryengine/PyBtcWallet.py#L912

We use a precursor to scrypt and a target derivation time on the extend wallet passphrases, that are used to encrypt the entries in your wallet if you choose to encrypt the wallet, on disk.

Wallet passphrases are completely different from root keys. Root keys come from a CSPRNG. Passphrases are created by users, so they are extended properly for added security.

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.