Program for searching addresses bitcoin and ethereum based on files with a list

[Geka041]

Hello everyone.
On this forum, I found a lot of programs for brute-force bitcoin wallets.
But they are all designed only for random
But the problem is that it all depends on luck (because you need a lot of time to find at least something)))) Basically, the software shows thousands of years)
The fastest program I've found is this VanitySearch https://bitcointalk.org/index.php?topic=5112311.0
Let's say I (purely hypothetically) have the most probable seed phrases in different text files (filename1,filename2,filename3 ... etc).
Is there someone who can modify or write software that can load seed phrases from text files. Next, it will make calculations based on these seed phrases exactly as here ( https://iancoleman.io/bip39/ )
Calculations to do for bitcoin for addresses 1, 3, bc1
Also in the software indicate the depth of calculations (For example 1000 addresses for one seed) from m / 44 '/ 0' / 0 '/ 0/0 to m / 44 '/ 0' / 0 '/ 0/999
And compare with a list of addresses where there is a balance
If it finds a match, it writes the address and private key and seed to a separate file.
All this is desirable to work on a graphics video card (because the speed of calculations on the processor is much lower)
And that each seed is checked for the presence of wallets with a balance for Bitcoin and Ethereum
Are there programmers out there who can make such software?)

[BlackHatCoiner]

I'll skip the fact that it's highly unlikely to find a private key that was generated before. Have you considered that this is theft? You aren't brute forcing sha256 hashes to improve the network's security; you're trying to find someone else's funds and steal them.

Anyway, I'm not going to change your personal character, if you just want to brute force “may the luck be with you”. Our whole fortunes rely on that very small possibility!

What you're searching is btcrecover.

[Geka041]

I'll skip the fact that it's highly unlikely to find a private key that was generated before. Have you considered that this is theft? You aren't brute forcing sha256 hashes to improve the network's security; you're trying to find someone else's funds and steal them.

Anyway, I'm not going to change your personal character, if you just want to brute force “may the luck be with you”. Our whole fortunes rely on that very small possibility!

What you're searching is btcrecover.

Not. You do not understand the main purpose of this software.
The point is to test my theory (seed selection theory)
If I can prove its efficiency, then it will be necessary to change (or strengthen) the method of protection.
And then what would be the point for me to steal other people's wallets, because it will simply destroy the price of the cryptocurrency

[BlackHatCoiner]

The point is to test my theory (seed selection theory)

What is the seed selection theory?

If I can prove its efficiency, then it will be necessary to change (or strengthen) the method of protection.

What exactly do you want to achieve, I don't get it. In the original post, you say that you want to brute force Bitcoin addresses same like VanityGen does. Then you ask if there's someone who can modify iancoleman's page to import a list of seed phrases and check their balances. Please guide me to the background of your theory.

[Geka041]

The point is to test my theory (seed selection theory)

What is the seed selection theory?

If I can prove its efficiency, then it will be necessary to change (or strengthen) the method of protection.

What exactly do you want to achieve, I don't get it. In the original post, you say that you want to brute force Bitcoin addresses same like VanityGen does. Then you ask if there's someone who can modify iancoleman's page to import a list of seed phrases and check their balances. Please guide me to the background of your theory.

I showed the software for brute-force as an example, because I will run into its calculation speed (a lot of keys per second)

I can tell about the theory only if I am sure that it is workable. And only when I figure out how to fix it.

[Geka041]

"Then you ask if there's someone who can modify iancoleman's page"
Do not change this page. I indicated it as an example.
To show on what principle there should be calculations in the program of addresses bitcoin and ethereum from a seed phrase.
Because I tried to find a programmer who would make such software, but his qualifications are low.
I was able to verify this by specifying a specific seed phrase to the program and indicated the exact same seed phrase on the page, and the list of addresses was completely different

[NotATether]

What exactly do you want to achieve, I don't get it. In the original post, you say that you want to brute force Bitcoin addresses same like VanityGen does.

Vanitygen and clones are not brute-forcers. They look for a private key that corresponds to a custom address prefix. Some people (ab)use them to feed an entire address as the prefix in attempt to find its private key.

[TheArchaeologist]

Closest thing to what you are looking for is https://github.com/ryancdotorg/brainflayer which searches for known addresses (by using a bloomfilter) and providing a list of words/passphrases to use for generating private keys. That could be a good starting point. But keep in mind you still have to do the confirmation (since bloomfilters can provide false positives) and the lookup for balances yourself.

At least the above approach is what I used to build the list of brainwallets back in the day listed in this topic: https://bitcointalk.org/index.php?topic=4768828.0

[NotATether]

Closest thing to what you are looking for is https://github.com/ryancdotorg/brainflayer which searches for known addresses (by using a bloomfilter) and providing a list of words/passphrases to use for generating private keys. That could be a good starting point. But keep in mind you still have to do the confirmation (since bloomfilters can provide false positives) and the lookup for balances yourself.

I'd argue that it's faster to leave the confirmation checks out if the FP rate is very low, because the checks involve performing a network request to bitcoin nodes, each one taking anywhere from a few dozen to a few hundred milliseconds, because nodes' RPCs can only process one address request at a time.

Balance confirmation checks could be more feasible if software was designed that can input several million addresses in one network request, considering how fast internet speeds are today - but no such software currently exists.

[TheArchaeologist]

I'd argue that it's faster to leave the confirmation checks out if the FP rate is very low, because the checks involve performing a network request to bitcoin nodes, each one taking anywhere from a few dozen to a few hundred milliseconds, because nodes' RPCs can only process one address request at a time.

When I did this myself I used my own database to do the lookup. So I didn't use RPC calls to a node or reaching out to an external data source. But I agree, it takes time. That's why I only used this on found addresses to rule out false positives.

Balance confirmation checks could be more feasible if software was designed that can input several million addresses in one network request, considering how fast internet speeds are today - but no such software currently exists.

That would mean you supply every found address to this external service and you either get a balance (including 0.00000000) back per address or a response the address isn't found. That could work if such a service would exist but in that case you are just outsourcing the confirmation of found addresses to this external service. It's an interesting idea, wouldn't be too hard to make, might try do to this myself since I already have a database with all real-time balances.

In conclusion: I was pointing out that when you use brainflayer you can expect (a lot of) false positives so one way or another you should have a confirmation in place that at least checks if the address is used on the blockchain before and preferable if the answer is yes also checks the current balance. This confirmation can be done in several ways, it all depends on which tooling and data you have available.

[franky1]

if you have a full node you can just get the UTXO set and then compare that you your list of keys.

most fullnode software strips a bitcoin address down to its base minimum RIPEMD160 format
so when doing your privatekey to public key to sha to ripemd160. you then dont need to then add on the version bits and checksum or the convertion to base58 or beck32

you can just compare your seeds ripemd160 to the utxoset ripemd160 in your nodes UTXOset to see if funds exist

..
the flaws of a seed is that the 12 words represent only 12 of of 2048 words
if you do the math. 2048¹²

5,444,517,900,000,000,000,000,000,000,000,000,000,000
vs                                                                  80,000,000

thats like 8 needles in 544517900000000000000000000000000 haystacks

and to add to that
your
5,444,517,900,000,000,000,000,000,000,000,000,000,000
haystacks which you are searching through. are in a single small seed barn
compared to the entire private key land scape of hay
11,579,209,000,000,000,000,000,0000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000


meaning there are  
21,267,647,958,325,200,000,000,000,000,000,000,000 barns full of the same amount as your seed barn.. and you are not looking in any of those barns

finding 80mill addresses in a single barn of millenia of searchs. when you are missing out the point that there are eons of barns of the barn your searching in..
you soon realise its not a needle in a haystack
its a needle in a haystack of a barn. of all the barns on earth, of all the planets in the univervers

...
but goodluck

if you want to just play it luck y hoping to find a phrase some someone uses because its a common term. really good luck. idiots using common phrases like 'to be or not to be that is the question quote william shapespear"
then they deserve their funds snatched

by the way the numbers are so huge i dont even have to be 0.00000000001% correct to the amount. for it to still be more numbers than someone can even contimplate

but hey.
if you think you can brute all
5,444,517,900,000,000,000,000,000,000,000,000,000,000

then i hope your great great great great great grandkids are willing to help keep the project going in that single barn. and your descendants to the millionth generation might just, might start on a second barn of haystacks.



so heres a hint. before going deep into the project.
work out a health search per second value
how many private key conversions and ripemd160 comparisons can yo do a second
..
then calculate how many searches a monute, hour,day, year, decade, century, millenia
and see if you even come close to your haystack barn total

EG. lets go crazy 1 trillion keys a second(more then most pc's can do)
1,000,000,000,000,000per sec
60,000,000,000,000,000per min
3,600,000,000,000,000,000per hour
86,400,000,000,000,000,000per day
31,536,000,000,000,000,000,000per year
315,360,000,000,000,000,000,000per decade
3,153,600,000,000,000,000,000,000 per century

yep thats
3,153,600,000,000,000,000,000,000 per century
vs
5,444,517,900,000,000,000,000,000,000,000,000,000,000 hey stacks

yep thats right
1,726,445,300,608,830,000 centuries to entirely bruteforce just the seed word haystackbarn
let alone all the barns in the universe

[a.a]

Well I found already some needles in the hastack...

[WanderingPhilospher]

EG. lets go crazy 1 trillion keys a second(more then most pc's can do)

With one GPU (RTX 2070), with a limited test run, I can get 61864.26 TH/s, or 62 Petahashes per second.  That means that every second my GPU can search and compare that many h160 combos.

I get your point, it's still a long time and a lot of haystacks.

[franky1]

EG. lets go crazy 1 trillion keys a second(more then most pc's can do)

With one GPU (RTX 2070), with a limited test run, I can get 61864.26 TH/s, or 62 Petahashes per second.  That means that every second my GPU can search and compare that many h160 combos.

I get your point, it's still a long time and a lot of haystacks.

a specialised ASIC with more chips than a GPU where each chip is programmed purely to do hashes.
can only do 110 TH

the RTX 2070 can do  35mh on ethereum or maybe 61mhash overclocked

which is basically 61million.. hashes

i found it funny how anyone can think a GPU can do more then an asic..
its as if they didnt do their research,

oh and remember..
hashs are just doing a accumulating number of existing data and SHA'ing it.

but this topic is about private-public-compare to file:
so first convert a private key to public key(ecdsa)
then sha
then ripemd160
then compare to file

which as you can see is more complicated than block hashing

so lets presume a 15mh(15mill priv-pub-compares) per second using the GPU you mentioned

but yea. i allowed for a crazy number of 1 trillion.

[WanderingPhilospher]

EG. lets go crazy 1 trillion keys a second(more then most pc's can do)

With one GPU (RTX 2070), with a limited test run, I can get 61864.26 TH/s, or 62 Petahashes per second.  That means that every second my GPU can search and compare that many h160 combos.

I get your point, it's still a long time and a lot of haystacks.

a specialised ASIC with more chips than a GPU where each chip is programmed purely to do hashes.
can only do 110 TH

the RTX 2070 can do  35mh on ethereum or maybe 61mhash overclocked

which is basically 61million.. hashes

i found it funny how anyone can think a GPU can do more then an asic..
its as if they didnt do their research,

oh and remember..
hashs are just doing a accumulating number of existing data and SHA'ing it.

but this topic is about private-public-compare to file:
so first convert a private key to public key(ecdsa)
then sha
then ripemd160
then compare to file

which as you can see is more complicated than block hashing

so lets presume a 15mh(15mill priv-pub-compares) per second using the GPU you mentioned

but yea. i allowed for a crazy number of 1 trillion.

I don't think you can compare mining hashes to a what I am considering a hash (what I consider a hash here is taking a private key and comparing it to a list of h160s) and what you eluded to:

how many private key conversions and ripemd160 comparisons can yo do a second

So that is what my hashrate/speed is based on.

My 2070 can compare and check, 61864.26 TH/s, or 62 Petahashes, private key conversions and ripemd160 comparisons per second.  That was a limited test, it probably could go higher.

Before you repine, here is the math you can agree or disagree with.

If you have 1,000,000 h160s in a file and your GPU is checking/converting/comparing priv key to h160 at a rate of 500,000,000 per second, what is the speed?

1,000,000*500,000,000 = 500,000,000,000,000, now multiply that by 2 because it's checking both compressed and uncompressed keys.
So that is a total of 1,000,000,000,000,000 private key conversions and ripemd160 comparison per second, agreed?

[franky1]

if you only have 1million public keys in a file

and your GPU doing 500m converting/checking of priv to pubs

then you are only doing 500, convertion and checks a second.. as you first admit
as for the 1m*500m math at the end. thats meaningless

im sorry but there are more computations to create and compare a priv-pub to a files pub
than there is to just generate a blockchash

so if you really think that your GPU can out perform an ASIC on basic computational 'flops'
then you have miscounted your maths somewhere... which i think i just explained where

even doing 500m seems acceptable but a lil on the top end.
but trying to say its 1mill * 500m.. is a kind of a joke.


but anyway even with your exaggeration numbers(lets just call it you 'lets go crazy').. your still gonna need your descendants a few millenia in the future to keep the project going.

[yoyodapro]

I am currently able to process 2^54.75 Keys/second using a program I've been writing that combines the best of Bitcrack with BSGS using GPU's, at the moment I'm only capable of getting these speeds while searching public keys, while searching public address compressed I'm still getting about 2^38.127 Keys/second. I will be discussing this program more and maybe releasing a copy for public use after I find the 64 address!

[WanderingPhilospher]

if you only have 1million public keys in a file

and your GPU doing 500m converting/checking of priv to pubs

then you are only doing 500, convertion and checks a second.. as you first admit
as for the 1m*500m math at the end. thats meaningless

im sorry but there are more computations to create and compare a priv-pub to a files pub
than there is to just generate a blockchash

so if you really think that your GPU can out perform an ASIC on basic computational 'flops'
then you have miscounted your maths somewhere... which i think i just explained where

even doing 500m seems acceptable but a lil on the top end.
but trying to say its 1mill * 500m.. is a kind of a joke.


but anyway even with your exaggeration numbers(lets just call it you 'lets go crazy').. your still gonna need your descendants a few millenia in the future to keep the project going.

I hear ya.  Have you not used any programs out there?  Take vanitysearch alone, the 2070 does around 2,000 million keys per second. yes, 2,000,000,000 keys per second.

I am not saying a GPU is faster than an asic.

My original post to you was saying that computers/gpus can get more than what you are saying they can.  

How is it not 1 mill * 500 mill??  Each time a private key is converted to pub key and h160, the program checks all 1 million addresses for a match.  So if the program checks and converts one private key, it checks the result against all 1 million loaded in the input file.  So if the program is checking/converting 500 million private keys per second, it is checking each 500 million results against the 1 million loaded in the input file.

[bigvito19]

if you only have 1million public keys in a file

and your GPU doing 500m converting/checking of priv to pubs

then you are only doing 500, convertion and checks a second.. as you first admit
as for the 1m*500m math at the end. thats meaningless

im sorry but there are more computations to create and compare a priv-pub to a files pub
than there is to just generate a blockchash

so if you really think that your GPU can out perform an ASIC on basic computational 'flops'
then you have miscounted your maths somewhere... which i think i just explained where

even doing 500m seems acceptable but a lil on the top end.
but trying to say its 1mill * 500m.. is a kind of a joke.


but anyway even with your exaggeration numbers(lets just call it you 'lets go crazy').. your still gonna need your descendants a few millenia in the future to keep the project going.

I hear ya.  Have you not used any programs out there?  Take vanitysearch alone, the 2070 does around 2,000 million keys per second. yes, 2,000,000,000 keys per second.

I am not saying a GPU is faster than an asic.

My original post to you was saying that computers/gpus can get more than what you are saying they can.  

How is it not 1 mill * 500 mill??  Each time a private key is converted to pub key and h160, the program checks all 1 million addresses for a match.  So if the program checks and converts one private key, it checks the result against all 1 million loaded in the input file.  So if the program is checking/converting 500 million private keys per second, it is checking each 500 million results against the 1 million loaded in the input file.

Most likely he doesn't know about that modified program you use to get that speed.

[franky1]

firstly.
if you knew how search algo's work. they never actually search through all 100m
secondly the search is not 1m *500m
its more like 500m GPU processes+1mill CPU search cycles
meaning more like 501mill

after all it does not do 500m. look at first file record. do 500m look at second file record
its 500m then look at upto 1m file records.
so 500m+1m is more accurate based on your numbers

anyway now we are just knitpicking numbers when the whole point is.. goodluck asking your 1000th generation descendants to carry on the project

by that point all the current 80m UTXO would have been spent. lost or converted to new UTXO using a different algo

but keep it up. only a few millenia to go