Bitcoin Forum

.

Original seed is 256bits. If you know some Python it's rather easy:

https://github.com/etotheipi/BitcoinArmory/blob/master/armoryengine/ArmoryUtils.py#L1914

You can use that call to convert 128bits of entropy to an Armory backup string. Do it twice and you have created you own root key that you can then plug in the restore wallet function to create a wallet file out of it.

You're on the right track so far.

There isn't a public seed per say. Address N+1 public and private components are derived from address N and a scalar which is created by hashing address N's public key and the chaincode.

The chaincode is an HMAC of the root key:

https://github.com/etotheipi/BitcoinArmory/blob/master/armoryengine/ArmoryUtils.py#L2941

You can read the derivation code here:

https://github.com/etotheipi/BitcoinArmory/blob/master/cppForSwig/EncryptionUtils.cpp#L681
https://github.com/etotheipi/BitcoinArmory/blob/master/cppForSwig/EncryptionUtils.cpp#L757

My recommendation is to use a deck of cards.  Shuffle it to your heart's content, then type in the order of the cards into a string, such as "Ah9d3s3h...".  Hash that and use the resulting 32 bytes as your seed.  You can use armoryengine to do the conversions:  hash256() to hash the string, and "makeSixteenBytesEasy()" to convert each half of the string to a line that can be entered into the wallet restore window.

The order of a deck of cards has 225 bits of entropy, which is plenty big enough.  I tried the dice thing before, but it's a lot of dice rolls and it makes a lot of noise.  The deck of cards is much more pleasant :)

(highly scientific statement here ;)) Sometimes when I shuffle a deck, the cards are too similar to the original.
Dice sounds like a better method to me if you want a great real-world entropy source (and you have the time to spare), especially if you're not experienced at shuffling cards well.

You don't have to be good at shuffling:  just play 52-card pickup (http://en.wikipedia.org/wiki/52_Pickup) with yourself :)  Or less chaotic, just put all the cards on the floor or table and swirl them around for 60 seconds then put them back together.  The ordering of a deck of cards has 225 bits of entropy which is technically overkill anyway:  128 bits is generally accepted as forever-secure.  You'd have to be trying hard to "cheat" to end up with less.

Alternatively, you can roll a 6-sided die 50 times to get approximately 128 bits of entropy.  I'd recommend doing 160 to be safe, but 128 really is sufficient (technically a 256-bit private key has about 128 bits of entropy, anyway).

I flip burgers for real life entropy. If the burger falls out of the pan, it counts as a 0, otherwise it's a 1. Each burger can only be flipped once. It maybe long and noisy, but it's delicious!

It's (almost definitely) your imagination. Humans are great at seeing patterns in random data, even when it's just that: random. Compare your data to a true-randomness-generated list at http://www.random.org/dice/?num=50 (this site has high quality true random numbers, not pseudo-random, but it's not a secure thing, so don't try to use it for your crypto/private key)
To the best of my knowledge, the only weak keys are ones whose addresses happen to correspond to ones with easily-guessed private keys. (e.g. because the private key is 0x000...0002, or comes from a brainwallet passphrase "duck", or from a poor PRNG) The probability of you hitting one of these accidentally is so small it's not practical to worry about it.

True random numbers often look off. Additionally, cheap dice typically aren't evenly distributed because the actual dimples cut out will create a weight imbalance which biases higher numbers. You can measure this by doing a few hundred rolls and drawing a histogram.

Since we're on the topic of using dice for generating encryption keys, you may find this interesting reading: http://world.std.com/~reinhold/diceware.html (http://world.std.com/~reinhold/diceware.html)

What percentage of Armory users use dice/cards versus trusting the developer?

Armory has a backup tester specifically for this.  Technically, it does exactly what Armory would do when restoring a wallet from backup, but some people won't trust it unless they actually restore the wallet.  So either use the backup tester, or create the wallet you plan to use, create your single/fragmented backup and then wipe everything and restore it on a fresh version of Armory.  For the watch-only wallet, you can generate the first X addresses on the offline/full wallet, and then import the watch-only wallet to the online computer and verify it generates the same X addresses.  Technically, you only need 2 addresses since the equation is the same for generating subsequent addresses, but again people won't trust it unless they see it work a dozen times.  Compare 1,000 addresses if you have the patience to do so.

The logic is in EncryptionUtils::ComputeChainedPrivateKey (https://github.com/etotheipi/BitcoinArmory/blob/master/cppForSwig/EncryptionUtils.cpp#L681) and EncryptionUtils::ComputeChainedPublicKey (https://github.com/etotheipi/BitcoinArmory/blob/master/cppForSwig/EncryptionUtils.cpp#L757).

Simply put, publicKey(i+1) is computed from publicKey(i) using:

You're walking down the math-heavy path of elliptic curve calculations.   It is described dozens of times elsewhere throughout the forum.  Look up "Type 2 deterministic wallets" originally conceived by gmaxwell. The watch-only wallet is an exact copy of the regular wallet without any private key data.  If you are uncomfortable, you can manually inspect the binary file and confirm that the private key fields are all 0x00 bytes.  

I forgot to mention above that the private keys are computed the same way.  I should've had.


Yes, you can derive the same chain of public keys using only the root public key, as the private keys derived the same way from the root private key.  This is the basic math behind "Type 2 deterministic" wallets and the basis for HD Wallets/BIP32 which is in-process of being adopted by all major wallets.  Armory and Electrum both demonstrated the power of type2 det wallets and have used them for years.  Now everyone else will be, too (however, Armory's deterministic wallets use a different type2 algorithm that I created before BIP32 existed, but it still has all the same security and privacy properties)

Has it been considered to use a bunch of human mouse movements as seed, like TrueCrypt did?

Armory already collects real world entropy, including mouse movements, clicks, key presses, and hashes of system files, when creating the wallet.  It bundles in that extra entropy with the Crypto++ RNG.  That extra entropy alone should be well in excess of 256 bits.

Oh, my bad. And then I fail to see how could that not be enough in any conceivable case.

As i understand if anybody knows my "i+1" public address and "i" address he can easy calculate chaincode?
Yes?
And same chaincode used in for generation of next private key?
So if anybody will define (i don't how it's gypotetical question) private key i+100, and he knows "i+1" and "i" public keys (for example i am shop and one customer bought 2 orders: one order -> two order and after he knows my chaincode?) he will know next private key and so on?
May be here is some vulnarabilities?

Sorry, my mistake may be
I see now that multiplier is EC function.
I don't know how it works but now i think if anybody knows publicAddress(i+1) and publicAddress(i) he cannot find chaincode?

One question please: data are collected in moment only when i press button "Create" or before?
I don't see any messages like "To move mouse, to press some keys" and don't understand where start and end time for real world  entropy?

It's collected in the background as you go through the create-wallet process.  Only 32-bytes of entropy is needed, and the whole process collects far more than that, so there's no need to explicitly request the user do stuff.  Though, from a marketing perspective, it's probably better to make the user aware that it's happening.

I'll be trying this device soon:

http://ubld.it/products/truerng-hardware-random-number-generator/

I don't know much about that device or company behind it, but I will say that a true HWRNG is overkill if you are creating a couple wallets and don't mind doing dice or cards yourself.  Why?  Because you need like 100 bytes of entropy per year to create a few wallets.  Most HWRNGs produce X kB per sec (the quantum RNGs produce 10 MB/s).  I'm sure this device is good, but the random numbers Armory uses for the online computer are not only cryptographically secure, we throw in a bunch of other entropy from mouse clicks, system files, etc, to ensure even better entropy.  

If grandma was going to use Armory, we'd say just use the built-in RNG -- we use it and we trust it.  If you're going to do some custom thing, use dice or cards.  If you need to create millions of independent private keys, the HWRNG is probably the best choice.

Well...I bought this because I did use dice.  Dice worked, but I am sort of impatient.  Rolling 99 die seemed tedious, and for $50.00 I thought this would be cost effective.  I imagine that hardware wallets, good ones, will have this type of hardware RNG built in, in the future.  My only wish was that there was some way Armory could query this device directly as a source of entropy.