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 ...
I started implementing BIP32 for the reference client myself, but as there were more urgent matters to deal with, I have temporarily stopped working on it. I certainly plan to complete this, but I can't give any target date or version right now.
As far as I know from Alan Reiner (Armory's developer), he plans to switch to BIP32 as soon as the reference ...
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 ...
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(...
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:
The clear ...
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)
There are different "backup-standards".
Some use BIP39 (mnemonic) which lacks of a flexible wordlist and versioning. Its used by Leger, Trezor, Bitpay/Copay, etc.
Electrum uses a different – more flexible – mnemonic backup concept. Though, it's incompatible with BIP39.
But then, there is also the BIP32 keypath which can be different among wallets. Example:...
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:
but use non-hardened keys for the receive (a.k.a. ...
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:
You can use it in tandem with our WebHooks API for notifications whenever an address associated with an HD ...
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 ...
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 ...
(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.
from binascii import hexlify, ...
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.
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
Why does BIP44 use non-hardened paths at all?
Imagine you have a website where you want to sell things. You need the website to be able to generate addresses, but you don't want it to be able to spend from them.
Well, you can give the website an account-level extended public key, and it can generate the non-hardened addresses you need from that. You wouldn'...
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.)
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 ...
Just like in regular bitcoin addresses (or anything base 58 encoded), the version bytes don't get encoded by themselves. As described in the Serialization format section, there is 78 byte payload that gets versioned and checksumed before then being encoded into base 58:
4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: ...
After a lot of struggle, I found out that Electrum uses following root derivation for normal and multisig wallets. For example:
root/0/0 for each cosigner. Example:
m/44'/0'/0' ==> shared root key (x)
x/0/0 ==> address for first receiving multisig (derive in all cosigners shared keys. all 3 keys must be lexicographically ordered).
some semi-compatible ...
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.
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 ...
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 ...
In general, HD Wallets use the following logic for how many addresses to query, and when to stop:
Start with account 0, generate gap limit number of addresses (usually 20)
Check for any transactions in those addresses
If there are no transactions, stop searching for new addresses and accounts
If there are transactions, generator gap limit more from the ...
Mycelium HD is BIP 44 compliant. As specified by BIP 44, the address gap limit is 20. This means that after 20 indexes of unused addresses, the wallet expects that no more addresses are used beyond that point. Therefore if you send funds to an address with a gap of more than 20 indexes between the last used address, the wallet software will not check if that ...
Bip-32 allows me to dereive keys based off a root key pair, and all these keys will be on the secp256k1 curve.
This is actually not true. The BIP32 proposal simply states that (emphasis mine):
In the rest of this text we will assume the public key cryptography used in Bitcoin, namely elliptic curve cryptography using the field and curve parameters ...
As mentioned, I don't believe HD Wallets are relevant to this problem. Even with simple wallets combining inputs from multiple addresses proves that a single person owned all the addresses included. I'm not sure if this would meet your specific privacy needs, but it is at least a straightforward way of avoiding that problem:
Assume you have 4 addresses, A, ...
I can not tell you really how you generate them, but to partially answer your question, here is a list of known Bitcoin and Altcoin prefixes, including Litecoin and Darkcoin:
EXT_SECRET_KEY, EXT_PUBLIC_KEY # Network : Prefixes
0x0488ADE4, 0x0488B21E # BTC Bitcoin ...
BIP32 support is planned for Electrum version 2.0. The code is already there, but disabled.
You can find some features that were first planned for 2.0, but were included in a 1.9.8 release as the servers were being updated to a new important version so it was needed to apply some changes already to the client to put all in place for 2.0 https://bitcointalk....
This is accounted for within the BIP32 specification, they are called 'hardened' keys. Hardened child private keys are derived from the parents' private keys, and revealing the hardened child private keys does not reveal the parents' private key.
Child indices 0...2^31-1 are reserved for regular keys (that have the problem you describe), and child indices ...
I ended up writing my own command-line tool to perform wallet discovery and print out a report.
It supports single xpub derivation as well as multisig m-of-n wallets, specifically CoPay wallets.
It determines if each address has been used or not by querying blockchain.info or also toshi or insight servers (the latter two can be run locally.)
This recommendation comes directly from one of security considerations from the same document:
Note however that the following properties does not exist:
(...) Given a parent extended public key (Kpar,cpar) and a non-hardened child private key (ki), it is hard to find kpar.
The reason for this recommendation is the fact all the non-hardened key ...