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 ...
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 ...
You've hit upon an important issue, and one that there isn't a perfect solution to.
Your thin client (most clients that use deterministic wallets are thin clients, but not all) goes through the following process:
Generate an address.
Look at the blockchain, and see if it has a balance.
Repeat with next address, unless the addresses we've checked have had a ...
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 ...
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 ...
Is there a kind of homomorphism between the set of private keys and public keys?
Yes. You can think of f: G -> H being the function that derives a public key (i.e. something from the set of H) from a private key (something from the set of G).
More to the point, f(a + b modulo n) = f(a) # f(b)
(I'm using the # symbol above to mean 'secp256k1 elliptic ...
TL;DR: The network is not made aware of address ownership, nor can anyone check if an address is owned unless it has been used previously (or is owned by himself). Anyone can send transactions to any valid (as in correctly shaped) address¹, the recipient doesn't have to be online for a transaction to take place.
Let me elaborate a little bit in order to ...
Clients that use an HD wallet generate a fairly large number of the keys in advance (e.g. Armory does 100 by default). When it scans the blockchain for relevant transactions, it checks for transactions to all of the keys that it's generated so far.
Typically, you do transactions off the next address in the list (there's a certain order to it, and it's ...
Yes, this is possible. However, since Bob (actually, in cryptography, usually Eve, the attacker) has, apparently, got access to Alice's computer, he/she could also replace the Bitcoin application with one that does the same thing.
The purpose of this procedure is to protect Alice's existing bitcoin. It does not do other things.
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 ...
mnemonics are the seed. you use that to get your private key.
the rest of the story as you have pointed out, is about deriving child key pairs. The process is deterministic (as the letter D in HD), meaning that you can get the same tree of child keys from the root seed whenever you do that. This could go "indefinitely", so how would you know when to stop? ...
Other than just deriving a ton of potential keys and checking whether they correspond to the address, no. There is no mathematical relation between keys in a HD keychain that allows you to determine whether they are in that keychain.
how does the system associate the balance from several transactions (allocated to different derived public keys) to the same bitcoin "account" or master public key?
The system must known the XPUB (often the master public key) for it to generate all of the addresses to 'watch'.
While we're on the subject of master public keys and privacy, there are ...
Well, it's a deterministic wallet. There is a function f which for every n∈ℕ returns the nth address that will be produced.
An address is basically a hash of a public key (we can neglect the rest it's comprised of but it's deterministic as well).
You can get a public key from a private key deterministically.
Every 256 bit number is a private key.
So your ...
Short answer: It doesn't. All the network knows is that someone sent funds to this address. It doesn't know and doesn't care if anyone has a private key matching a public key matching this address - that is the problem of the user who sent the funds, and the user who requested funds to be sent to this address.
Of course, if user B ever spends these coins (...
Hierarchy allows interesting use-cases.
You could have a master company key m/0' and give out m/0'/0/0 to company-branch A and m/0'/0/1 to company branch B, etc.
You could then allow audits by handing out the extended public keys (xpub) of m/0'/0 to some trust organization (or just hand out m/0'/0/0 if you want someone to audit branch A only).
Private key ...
Electrum uses a gap limit to stop looking for addresses in the deterministic wallet. The default gap limit is set to 20, so the client get all addresses until 20 unused addresses are found.
Change addresses have a gap limit of 3 and this is not modifiable by the user.
addrgen author here!
Addrgen was created before Electrum was BIP-0032 compatible and thus it used different master public keys and derivation method.
Please check the following PHP implementation which supports BIP-0032:
For python there are couple of implementations available, e.g.
The apostrophes show whether or not that particular derivation is hardened.
The difference been hardened and non-hardened keys is described in BIP32.
See the wiki for some further detail. https://bitcoin.org/en/glossary/hardened-extended-key
Here's a web tool for BIP32 key derivation.
The only problem is the hardcoded 50k rounds of HMAC-SHA256. You do need to know how your wallet software exactly derived the master private key from the mnemonic or you'll get totally different keys. Unfortunately there's no standard convention for the HD wallet backup/restore process and I'm afraid this ranks ...
The gap limit is the maximum number of consecutive unused addresses in your deterministic sequence of addresses. Electrum uses a gap limit to stop looking for addresses, it is set to 5 by default, so the client get all addresses until 5 unused addresses are found.
If you used a different gap limit when creating the ...
Here is a KISS answer.
The Ledger uses BIP 32, 39, 44 technology as do many other similar harware wallet devices, e.g. Trezor, Keepkey. You should be free to use your hardware wallet across multiple genetically independent software implementations on the same computer or across multiple computers with USB interfaces.
It works simply because each wallet ...
It is secure.
128-bit seed is at this time very secure. It is lower than a regular bitcoin address which is actually RIPMED-160(SHA-256), giving it 160 bits of entropy.
Brute forcing a 128 bits of entropy at this time would take around 1,440,000,000 years if every computer ever made was working on this single problem.
Like most of these algorithms brute ...
The xpubkey (your master public key) is not something you need to export.
What you need to store is your seed value for the Electrum wallet. With this it can regenerate you the xpubkey.
The xpubkey is not really useful unless you are providing it to someone who intends to make multiple payments to you. If this is the case then make sure only that ...
How many keys can be generated by a deterministic wallet?
Effectively infinitely many. The same as a non-deterministic wallet which just keeps generating random private keys. There is a limit, 2^256, but you are never going to reach that. It is effectively infinite.
Is it possible to list all keys (public keys, to avoid leaking critical information) in ...
It appears that the wallet moved my funds to a new address in my wallet.
That is normal and desirable behavior. See How does change work in a bitcoin transaction?
Should a wallet always move the left over from m/49'/0'/0'/0/x to m/49'/0'/0'/x/0?
This wallet is using BIP 49, which extends the hierarchical wallet organization described in BIP 44. ...