09-13-2021, 07:17 PM
The paper wallet has a 6P address. My test wallet also has a 6P too. I believe it was BIP-38 encrypted, but with a non-standard password other than the present dictionary lists that have been used in more recent wallets.
It's quite fast, but I haven't been able to decrypt my test wallet, even though I emailed the developer that made the utility, I have yet to hear back on how he converted the example wallet public address hex string.
When I attempt to convert it into an address string from hex I am not able to produce a good bitcoin address, which is where the knowledge gap is at the moment.
It is indeed way faster than the present methods using btcrecover, I'm not sure how one would implement a similar method in hashcat, but it would be worth it, if the results and method can be verified, tested and reproduced.
It seems thousands of times faster than Python. (Using the libwally backend)
It's quite fast, but I haven't been able to decrypt my test wallet, even though I emailed the developer that made the utility, I have yet to hear back on how he converted the example wallet public address hex string.
When I attempt to convert it into an address string from hex I am not able to produce a good bitcoin address, which is where the knowledge gap is at the moment.
It is indeed way faster than the present methods using btcrecover, I'm not sure how one would implement a similar method in hashcat, but it would be worth it, if the results and method can be verified, tested and reproduced.
It seems thousands of times faster than Python. (Using the libwally backend)
(09-13-2021, 01:52 PM)monyanus Wrote: Interesting, are you sure the paper-wallet uses the same derivation? E.g. what is the address type, what does the address of the paper wallet start with?
If I look at your code, I think you derive a legacy wallet type, meaning one address directly derived from the public key, which is indeed fast.
Your paper wallet probably uses a more elaborate derivation using BIP44 and possibly segwit (address starting with bc1).
The challenge is to build in these derivation shema's and address types, then let the user chose at which dept they want to search. I would love to see this in hashcat, but this is non-trivial to implement.
For example a BIP4 wallet has a different derivation process to derive a tree of privatrkeys-publickeys-address from a master key and generating new child keys by hashing the master key with an index:
http://aaronjaramillo.org/bip-44-hierarc...ic-wallets
Additionally there are other derivation types, BIP49, BIP84, BIP141
See iancolman tool for deriving privatekey-publickey-address pairs:
https://iancoleman.io/bip39/
I have some code that allows testing and derivation for any type of derivation paths, even custom, but it is build in Python and it is not very fast.