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 ...
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 ...
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.
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 ...
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 ...
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 ...
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 ...
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 ...
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:
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 ...
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 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 ...
You won't ever lose funds due to the gap limit; they don't become lost forever. You can still retrieve them.
The gap limit is really only an issue for restoring backups. When restoring a backup, the gap limit is used by the wallet to know how many addresses to lookahead in order to ensure that all funds are seen. If the gap limit is too small, then a long ...
Wallets created by Electrum 1.x have seeds containing 12 words (24 words is also possible for custom-created seeds). Given a zero-based array of seed_words of that length, this pseudocode calculates the master_private_key:
i = 0
while i < length(seed_words):
# convert each word into an int in the range [0,1625]
# based on the word's position in ...
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.
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 ...
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 ...
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 ...
It does not have one.
Bitcoin Core uses hardened derivation, so there is no way to compute the addresses it will use externally.
Support for that will likely be added in upcoming versions, but likely won't be the default (there are security risks when using non-hardened derivation).
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.)
No wallet currently supports creating replaceable transactions conveniently. To work around this, you can manually create raw transactions from scratch.
The following are suggested instructions for use with bitcoin-cli.
To create a replaceable transaction. You can use "createrawtransaction" to manually add inputs and mark the "nsequence" field to a value ...
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 ...
It is not sensitive at all.
In particular, it does not allow people to derive addresses, does not allow them to recognize addresses that are yours, and cannot be used to infer anything about your private keys.
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 ...
The answer you linked isn't wrong; you just stopped reading too soon.
Transactions aren't signed by the master private key itself; they are signed by the child private keys. But those child private keys were generated from the master private key. So it's true that all you really need to store is the master private key.
If you have the master private key, ...
The author of this paper seem to have put some thought into the problem you describe and has proposed a solution that seems relevant to your question:
A new HD wallet that tolerates key leakage
Master key generation. Instead of one master private key, our HD wallet uses
m master private keys ˆd1, . . . ,ˆdm for some reasonably-sized m to be determinedby the ...