6

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 ...


4

If you are comfortable with using the command line then libbitcoin-explorer is a great utility for converting your bitcoin HD keys. It even works completely offline. Once you have bx installed, you can run the hd-to-public command like so: $ bx hd-to-public ...


4

Why was the fingerprint chosen for psbt instead of the full hash? Collisions aren't that rare for just 4 bytes of data and adding mitigations in the psbt transaction parsing for such a case seems unnecessarily complicated. Fingerprint collisions would still require thousands of signers in a single PSBT to actually be a problem. Collisions aren't all that ...


4

What exactly is the "point at infinity"? It's a point that is added to the points on the curve. Together they form a group. It has the following properties: (x,y) + (x,-y) = infinity (x,y) + infinity = (x,y) infinity + (x,y) = (x y) In other words, the point at infinity is the identity element of the addition in the group. Therefore some people write the ...


3

One of the privacy properties of BIP32 is that given two public keys (or even private keys), you cannot even tell whether they were generated from the same xpub or two distinct xpubs. This implies you certainly can't tell their index.


3

Mnemonics are the private key separated in 12 words which joined together in the very same order produces the private key That is incorrect. A mnemonic represents an entropy that is passed to a PBKDF2 key-stretching function with 2048 rounds of hashing to generate a 512 bits seed. This seed then acts like a keychain that is used to generate different keys. ...


3

The host running a virtual machine has complete, unfettered access to its guest, there's no breaching or compromising necessary. It provides absolutely no additional security in your described situation. It is likely trivial to access ECDSA private key material even between two unrelated virtual machines on a single host due to sidechannel attacks.


3

You give each customer a different address. That is the only reasonable approach.


2

You are correct in thinking that there is only one private key for one public key (or rather that is one of the assumptions that ECDSA relies on). While technically it is possible for a Bitcoin address to have multiple public keys and therefore multiple private keys, this is extremely unlikely to occur as it requires a hash collision. Of course there are ...


2

You simply cannot. The HD seed is used to derive the master private key, not the other way around. This derivation uses a hash function so it only works in one direction: HD seed to master private key. Given the master private key, you cannot get the HD seed used to produce it. BIP 39 mnemonics are used to create a HD seed which is then used to create the ...


2

Yes. Each input has its own signature with which to sign, so as long as you possess the private keys (or a master private key above the account level), you can add those inputs into any transaction you want.


2

BIP 32 does not derive addresses but derives a series of private keys from which corresponding addresses are then calculated. So there are multiple layers of obfuscations here that would make the index recalculation impossible. First, Bitcoin addresses do not reveal anything about the associated private key (ECC and hash protected) and second, the private ...


2

Trying to enumerate all private keys using Bitcoin Core's wallet is extremely inefficient. Furthermore, any address that you generate in Bitcoin Core will inherently come from a HD seed because Bitcoin Core is a HD wallet and uses a HD seed. You also aren't going to get any information for a HD address that is not part of your wallet. However, I am not ...


2

No, Bitcoin Core uses the BIP32 derivation path m/0'/0', and you are unable to change the derivation path of the wallet in Bitcoin Core. There is however the Hardware Wallet Interface (HWI) that might be what you are looking for. https://github.com/bitcoin-core/HWI https://github.com/bitcoin-core/HWI/blob/master/docs/bitcoin-core-usage.md


2

Prior to segwit doing this securely required carrying around enormous prior transactions. Prior to PBST there wasn't a standard serialization that covered all the interesting use-cases. It's been possible to offline sign for years using the CLI and many people have been doing so. More recently this PR adds a GUI for doing this using PSBT: https://github....


2

I want to know why the two tools are giving different results Bitcoin Core uses hardened derivation to derive child private keys from the master private key. You can check the embedded link for more details, but in summary it means that the software uses parent private keys within the hash function to generate child private keys. This compares to non-...


2

Conversion from a HD seed to a master private key is specified by BIP 32. It is done by computing a HMAC-SHA512 where the key is the text Bitcoin seed and the data is the HD seed itself. The first 32 bytes (256 bits) is the master private key. The last 32 byte is the chaincode for the master key.


2

The fingerprint could be used as a unique identifier for a key (it is based on the longer hash160 of the key which is frequently used as a unique identifier). However because it is only 4 bytes long, it is not hard to find two different xpubs which have the same fingerprint. We would say that the fingerprint for these two xpubs collide with each other. ...


2

You can do this with 1 transaction, it will get more expensive, but it has nothing to do with whether you use separate addresses or not (or with whether or not you're using BIP32 in any way or form, for that matter). Bitcoin uses a UTXO model: every transaction has 1 or more inputs, and one or more outputs. Every output creates a UTXO (which you can think ...


2

does it mean HD wallets support multi networks? No. A Bitcoin wallet can implement BIP-0044 without supporting any cryptocurrency other than Bitcoin.


2

if I take a private/public key pair, use CKDPub on the public and CKDPriv on the private, do they yield the same public keys? For unhardened childs, yes.


1

Non-hardened parents effectively use the public key to derive their children, where hardened parents derive their children from the private key. The derivation of a child private key from a non-hardened parent private key k uses the following hash function: HMAC-SHA512(chainCode, point(k) || i) We know that K = point(k), where K is the parent public key. ...


1

The fingerprint of a public key is defined in BIP 32 as the first 4 bytes of the RIPEMD160 hash of the SHA256 hash of the public key. The fingerprint of a particular xpub can be gotten from that xpub, but this is not useful information. What the Coldcard wants is the fingerprint of the master xpub. It wants the fingerprint of the key at derivation path m. ...


1

An address is not a wallet, and a HD wallet is only locally relevant to your storage and is not reflected at all in the public ledger. Bitcoin works on a UTXO model where funds are paid to an output which can be spent by the owner of the private key for a given address. There is no direct links between any addresses and no hierarchical structure in the ...


1

You seem to have confused a couple of things. Firstly, HD wallets is specified by BIP 32, not BIPs 39 or 44. Secondly, being able to set your own seed is completely unrelated to setting a custom derivation path. They are two different things that have no effect on each other. Note that BIP 39 specifies a menmonic scheme, not a seed. When I say mnemonic, I ...


1

You have interpreted that correctly. If your child extended private key belonging to path m/44'/60'/4'/0 is leaked, the attacker cannot figure out the child extended private key from path m/44'/60'/4'/1. The non-hardened derivation for child private key is kchild = kpar + hash(Kpar, cpar, i). Here k represents private key, K is the public key, c is the ...


1

If the above two keys are leaked, then your master private key at the account level (m/44'/60'/4') can be back-calculated. That means, any private key (both receiving and change) that you derive from that account is compromised. To elaborate, BIP 44 uses non-hardened derivation to derive private keys after the account level. The child private key derivation ...


1

Is it safe to use HD Key Derivation with bip-schnorr? Yes, it is designed to be. The bip mentions that you should not throw away the first byte of a generated key. Perhaps this is worded confusingly. It means that you can't use a variant of the signature scheme, which uses full public keys, but then throws away one byte of the public key at ...


1

The mnemonic words that is given to you by the wallets is a representation of entropy. This entropy is then passed through PBKDF2 hashing function to generate seed. The industry standard for this conversion of mnemonic to seed is documented in BIP 39 and most wallets follow that method. The seed is then passed to HMAC-SHA512 to get a master extended private ...


1

There is a list of BIPs at https://github.com/bitcoin/bips I don't see anything that specifies a wallet format. To be honest I'd be surprised to see one. This is something that each implementation ought to determine for itself, Some wallets might use an embedded SQL DBMS, some a Berkely DB format, some a JSON store of some sort and so on. Similarly, the ...


Only top voted, non community-wiki answers of a minimum length are eligible