python-hd-wallet-scanner - scan for HD Wallet master private key and addresses

[AuorFedelmid]

Hello,

My first Python project.

Source: https://github.com/AFedelmid/python-hd-wallet-scanner

A HD Wallet scanner that searches hash160 addresses from the top 100000 bitcoin addresses in a bloom filter with a positive balance looking for a collision, when a collision is found the script will provide you with xprv, xpub, wif and address.

dotenv file to add details so that you can receive alerts in a discord webhook or on pushover when collision is found

https://imgur.com/a/iUK6OqN

- Any criticism is welcome.

[1714869404]

1714869404

[1714869404]

1714869404

[1714869404]

1714869404

[AuorFedelmid]

Today I have started to add GPU support with CUDA. Any other ideas would be most welcome but the product is finding private keys with a balance, Only found one so far with a change address so not much.

[NotATether]

The btc_top_100000.bin file appears to be a binary file that is input to the BloomFilter class. In that case, I think that it would be useful if you modify your program to have another script that reads a file full of addresses, and writes a bloom filter containing them so it can be used with arbitrary addresses.

[AuorFedelmid]

The btc_top_100000.bin file appears to be a binary file that is input to the BloomFilter class. In that case, I think that it would be useful if you modify your program to have another script that reads a file full of addresses, and writes a bloom filter containing them so it can be used with arbitrary addresses.

I have that already I just did not provide. I will upload now.

Uploaded and have described how to use every known BTC address with a balance from downloading from https://bitkeys.work/download.php

[seoincorporation]

Nice script but to be honest this would work only on a supercomputer because what you are searching is for 100000 addresses where the total of possible addresses is 2^160...

Is like trying to brute force a sha, it could take you lots of years, and without luck, it will be impossible.

The only problem with this kind of script is what happens if the Chinese decide to run it with the Jiuzhang... They have a real chance to find an address with balance with that quantum computer... as a reference I will leave the link.

https://www.sciencenews.org/article/new-light-based-quantum-computer-jiuzhang-supremacy

[relayd]

Your build doesn't work for windows7 btw, not properly built I am guessing for older OS support.

[relayd]

I was able to run the code on debian with a custom compiled python3.9 version & your pip requirements.

Did you find the change address using the included top 100000 bitcoin addresses & how long did it take?

[pooya87]

You are already searching an impossible to find needle in a haystack so why are you making your own job harder by doing the search using the HD key derivation function? Why not just search for private keys and avoid all the extra overhead of the key derivation?!
If you were able to find a private key to steal other people's money (which you would never be able to) it doesn't matter if that key was derived from a master key or was found at random.

It is like wanting to find z from x+y=z but instead of first adding x and y you go ahead and compute pow, sqr, sqrt, cos, sin, sin^-1,... of both x and y then finally add x and y to find z.

[AuorFedelmid]

You are already searching an impossible to find needle in a haystack so why are you making your own job harder by doing the search using the HD key derivation function? Why not just search for private keys and avoid all the extra overhead of the key derivation?!
If you were able to find a private key to steal other people's money (which you would never be able to) it doesn't matter if that key was derived from a master key or was found at random.

It is like wanting to find z from x+y=z but instead of first adding x and y you go ahead and compute pow, sqr, sqrt, cos, sin, sin^-1,... of both x and y then finally add x and y to find z.

True but I was trying to get the HD derivation xprv and xpub also. It is all pretty new to me so correct me if I am wrong but with the xpriv I can find other keys derived from that wallet?

[pooya87]

True but I was trying to get the HD derivation xprv and xpub also. It is all pretty new to me so correct me if I am wrong but with the xpriv I can find other keys derived from that wallet?

Yes assuming there are other keys derived from that master key and assuming that the derived key that was found by "super luck" was not the result of a collision.

[NotATether]

Your build doesn't work for windows7 btw, not properly built I am guessing for older OS support.

Microsoft made a universal C runtime library which was bundled with Windows 10 and is linked to in Visual Studio so it's libraries must be missing from your system.

Installing the following update should fix this problem: https://support.microsoft.com/en-us/topic/update-for-universal-c-runtime-in-windows-c0514201-7fe6-95a3-b0a5-287930f3560c

True but I was trying to get the HD derivation xprv and xpub also. It is all pretty new to me so correct me if I am wrong but with the xpriv I can find other keys derived from that wallet?

Yes assuming there are other keys derived from that master key and assuming that the derived key that was found by "super luck" was not the result of a collision.

I'm starting to wonder if there's any relation between derived private keys and their parent that can be exploited to eg. avoid searching for nearby keys and speed up the search. Something like trying to find random private keys by deriving all the paths but slower because of all the extra ECC math.

[pooya87]

I'm starting to wonder if there's any relation between derived private keys and their parent that can be exploited to eg. avoid searching for nearby keys and speed up the search.

Since the keys are derived using a hash function and there is no relationship between the input of the hash function and the output of it, there is also no relationship between the master key and each child key that is derived from it that could be "exploited".

Something like trying to find random private keys by deriving all the paths but slower because of all the extra ECC math.

Each depth can have an index from 0 to 0xFFFFFFFF which is 4.2 billion. Even the most common paths used by wallets is still a huge list. It is not possible "to derive all paths".

[AuorFedelmid]

Your build doesn't work for windows7 btw, not properly built I am guessing for older OS support.

https://i.imgur.com/Nco8v9e.png

Microsoft made a universal C runtime library which was bundled with Windows 10 and is linked to in Visual Studio so it's libraries must be missing from your system.

Installing the following update should fix this problem: https://support.microsoft.com/en-us/topic/update-for-universal-c-runtime-in-windows-c0514201-7fe6-95a3-b0a5-287930f3560c

True but I was trying to get the HD derivation xprv and xpub also. It is all pretty new to me so correct me if I am wrong but with the xpriv I can find other keys derived from that wallet?

Yes assuming there are other keys derived from that master key and assuming that the derived key that was found by "super luck" was not the result of a collision.

I'm starting to wonder if there's any relation between derived private keys and their parent that can be exploited to eg. avoid searching for nearby keys and speed up the search. Something like trying to find random private keys by deriving all the paths but slower because of all the extra ECC math.

I found this which you may find interesting

https://bitcoin.stackexchange.com/questions/51724/is-it-feasible-to-derive-the-root-key-of-an-hd-wallet-from-a-large-sample-of-chi

[AuorFedelmid]

You are already searching an impossible to find needle in a haystack so why are you making your own job harder by doing the search using the HD key derivation function? Why not just search for private keys and avoid all the extra overhead of the key derivation?!
If you were able to find a private key to steal other people's money (which you would never be able to) it doesn't matter if that key was derived from a master key or was found at random.

It is like wanting to find z from x+y=z but instead of first adding x and y you go ahead and compute pow, sqr, sqrt, cos, sin, sin^-1,... of both x and y then finally add x and y to find z.

Hi Pooya87,

Just so I can steal some knowledge from you. Does this mean that even if I find a HD key (xprv) it might not be the master xprv of a wallet but the xprv of an address that could be way down the hierarchy of addresses in a particular wallet? My initial concept was to try and find Wallets rather than just addresses.

[pooya87]

Hi Pooya87,

Just so I can steal some knowledge from you. Does this mean that even if I find a HD key (xprv) it might not be the master xprv of a wallet but the xprv of an address that could be way down the hierarchy of addresses in a particular wallet? My initial concept was to try and find Wallets rather than just addresses.

Yes. It's the same collision principle as with keys <> addresses.
Bitcoin private keys are 256 bits while the addresses (most of them) are 160 bits that means there is more than one private key corresponding to each address. The reason why we will never actually find such a collision is because 2¹⁶⁰ is huge.
Similarly BIP32 key derivation uses a 256-bit key + a 256-bit chain code in HMACSHA512 so there is even more master keys that correspond to a single child address. In simple terms we could say that theoretically there exists xprv1 and xprv2 that generate completely different addresses except one.