35
Essentially, a hardened child key is is computed with hash(parent private key + index), whereas a non-hardened child key is computed with hash(parent public key + index).
So what practical consequences does this have?
With an extended public key, you can derive non-hardened child public keys. This is useful in situations where you want to accept payments ...
30
There's a lot of confusion here, mostly bits and pieces of the whole scheme that is Hierarchical Deterministic derivation, and finally two questions that seem to indicate missing some point about it.
The answer to the first question is No. The second question is more interesting :
Let's start from extended keys, specifically BIP32 keys.
Like private keys ...
19
Private and public key correspond to a point on the secp256k1 curve. They have a one-to-one relationship.
The address is derived from the public key by performing a ripemd160 hash after a sha256 hash on the public key. Multiple public keys hash to the same address, as the address space is only 160 bit, while the public key space is 256 bit.
Since both ...
18
What is the wallet "word seed" that is commonly used in popular wallets clients and what does it do?
With HD wallets, a single key can be used to generate an entire tree of key pairs. This single key serves as the "root" of the tree. The word seed is simply a more human-readable way of expressing the key used as the root, as it can be algorithmically converted into the root private key. Those words, in that order, will always generate the exact same key.
...
15
First we must understand how BIP 32 derives non-hardened private and public keys.
From BIP 32, deriving a child private key from an extended parent private key:
let I = HMAC-SHA512(Key = cpar, Data = serP(point(kpar))) || ser32(i)).
Split I into two 32-byte sequences, IL and IR.
The returned child key Ki is parse256(IL) + kpar (mod n).
The private key is ...
11
It uses m/0/<n> for receiving addresses, and m/1/<n> for change addresses.
Here's some example bitcoinj code to generate receiving addresses from an extended public key.
String serialized_xpub = "xpub.....";
unsigned int address_num = 4;
NetworkParameters params = MainNetParams.get();
DeterministicKey root_xpub = DeterministicKey.deserializeB58(...
11
With "Master public key" you probably refer to deterministic key derivation after bip32.
The correct term is "Master extended private key" (acronym xpriv) and "Master extended public key" (acronym xpub).
The acronyms are "xpriv" and "xpub" because the base58 check prefix results in those 4 characters for a mainnet extended pub/priv key.
The difference ...
10
to answer the first part;
generally speaking people will want to backup their whole wallet, not specific PKs.
so using a HD wallet and making a backup of the seed (either the seed or a BIP39 mnemonic doesn't matter) matches what people using 'normal' wallets do, you backup your whole wallet in 1 place (most wallets have a backup/export file for the whole ...
10
when you are doing
BitcoinAddress address1 = **pubKey**.Derive([some client data]).PubKey.GetAddress(Network.Main);
You are getting the bitcoin address, but not the master public key. (ExtPubKey)
A HD pub key have more information than just the pubkey.
The correct code is
string wifStr = **pubkey**.Derive([some client data]).ToString(Network.Main)
Then ...
10
The simple (and I believe correct) answer is: use hardened keys everywhere except where a need for watching-only wallets is perceived, e.g. below the "account" level. A watching only-wallet in this scenario will be able to both create new addresses, and monitor the balance of an account.
Hence BIP-44's path is:
m/44'/0'/account'/change/index
The clear ...
10
With Bitcoin, a single private key will have associated compressed and uncompressed private/public key pairs. Uncompressed public key addresses are larger in size than newer compressed public addresses. (Contrast 1b and 2b below.) Uncompressed and compressed public keys shall have different associated Bitcoin addresses. Private keys encoded in wallet input ...
10
There are different "backup-standards".
Some use BIP39 (mnemonic) which lacks a flexible wordlist and versioning. It's used by Ledger, Trezor, Bitpay/Copay, etc.
Electrum uses a different – more flexible – mnemonic backup concept which is incompatible with BIP39.
There is also the BIP32 keypath which can be different among wallets. Example: you can ...
9
It is possible for a custom implementation use hardened keys for all the leaf keys to enhance security in case of a single private key leak. This scheme will be incompatible with the standard compliant wallets.
The BIP32 and BIP44 standards, use hardened keys up until the "account" level:
m/44'/0'/account'
but use non-hardened keys for the receive (a.k.a. ...
9
Whenever you are attempting to explain Bitcoin to anyone, it makes a lot of sense to simply state that the derivation private key > public key > address is deterministic. However, if you are interested in writing your own code or studying the existing code base from various libraries, you may wish to know that a private key can actually lead to two ...
8
Bitcoin Core (since 0.13) uses HD after BIP32 with only hardened private key derivation. Exporting the xpub would be useless, because other apps could not derive public keys (hardened derivation requires the xpriv).
Though, you can export the xpriv with dumpwallet <filename> (RPC or Debug Console). But be careful with that.
8
There is a so-called gap limit. In Electrum, it's 20 by default but can be changed. But if you changed it up, remember that! Preferably write it next to your wallet's seed.
This means that the HD wallet determines the first 20 addresses and checks on a server whether any of them have every been involved in a transaction. Let's say these addresses are ...
7
How do I view my extended public key?
Go to Wallet > Master Public Keys, and copy the text that starts with xpub
What are the consequences of giving my extended public key to someone?
They can view all of the transactions and addresses in your wallet. They can generate as many of your addresses as they want.
Can they steal my Bitcoins if I give this ...
7
Response to clarified first part
You're pretty close, I suspect you want something simpler like this (and then typing in the xprv you extracted from an Electrum 2.x (unencrypted) wallet file):
bx hd-private --index 2 --hard | qrencode -o - | feh -
In particular, don't include the bx hd-to-wif step, that's probably what's tripping you up.
When you do the ...
7
Yes, you can, assuming that the child key isn't hardened, and you know the chain code of the parent public key and the index of the child. (Also known as the extended public key.)
Just compute
CKDpub((Kpar, cpar), i) → (Ki, ci)
Kpar is the parent public key, cpar is the chain code, i is the index, and Ki is the child public key
as defined here and compare ...
7
Full disclosure: I'm BlockCypher's Developer Advocate.
We have a series of HD Wallet Endpoints that we recently released that might suit your needs; you can read more about it here:
http://dev.blockcypher.com/#hierarchical-deterministic-hd-wallets
You can use it in tandem with our WebHooks API for notifications whenever an address associated with an HD ...
7
No.
All addresses generated by HD derivation are indistinguishable to someone who does not know the parent's master key (the private one for hardened derivation, the public one for normal derivation).
7
To get the extended private masterkey itself (not a seed), you can use the dumpwallet command and provide it with a filename to dump your keys to. The extended master key will be at the top of the file, and then it will list all addresses along with their keypaths underneath that, line by line.
Note that the dumped file is not encrypted, so be careful with ...
7
The reasons for the 3 numbers:
Bitcoin uses 256-bit ECDSA signatures. These require in the order of 2128 steps to find a private key from the public key is known. This is Bitcoin's security level: we aim to always require an attacker to perform 2128 steps. If the seed has less than 128 bits of entropy, this inevitably leads to a faster algorithm, where an ...
6
Yes, it's called HDM (Hierarchical-Deterministic-Multisig).
There's no standard, per se, and the main proponent (to the best of my knowledge) is/has been Vitalik Buterin, of Ethereum/Bitcoin Magazine fame.
There's code in the Python pybitcointools library which allows one to implement this on a low level. The functions are called:
bip32_hdm_script and
...
6
(The language used in this post is Python)
Breadwallet uses BIP39 to generate the 128-bit master seed from the 12-word mnemonic. The master seed is then used to generate a set of wallets/accounts containing chains of addresses, using BIP32.
First off, import hashlib and binascii, we're going to need them later.
import hashlib
from binascii import hexlify, ...
6
Electrum uses BIP45.
m / purpose' / cosigner_index / change / address_index
Example for non-change of the first cosigner and first address: m / 45' / 0 / 0 / 0
See: https://bitcointalk.org/index.php?topic=1634517.15
and
https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki
6
Unfortunately, Bitcoin Core itself does not provide methods to generate private keys from master key. However, there are libraries that can produce correct keys from xprv string (chain m/iH/0/k with hardened keys according to BIP0032) - I used https://github.com/prusnak/bip32utils for Python.
6
With just the private key, no.
However, if the attacker knows both a child private key and the xpub of the chain it is derived from, yes.
From BIP32:
One weakness that may not be immediately obvious, is that knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private ...
6
The bunch of input addresses (usually) come from a single HD wallet.
That's one possibility. It could also be that they come from a non-HD wallet, so that they correspond to a bunch of independently generated private keys that happen to belong to the same person. Or they could all belong to different people, who have agreed to combine their coins and send ...
6
1) ...How's my total UTXO calculated?...
Each node calculates it's own UTXO set, there is no single 'global UTOX set'. You may own some subset of the UTXOs, but there is no pooling. If you receive payments to the same address more than once, each one will be it's own UTXO.
2) ...If all public addresses have their own UTXO, then the wallet has to choose a ...
Only top voted, non community-wiki answers of a minimum length are eligible