Topic: Program for searching addresses bitcoin and ethereum based on files with a list (Read 379 times)

noob question. is searching program really a thing when mining?

Haha....again, I never said anything about asics. Check my post in this thread, there really ain't no bitch about it. Period. Zero said against asics.

You do not know how the program works. It stores so it doesn't reread each key visited.

Also, I am not searching for any utxo and a balance.  The test I ran revolved around 1 pubkey and 39 million relatives of that 1 pubkey. It was just a test, a benchmark before trying to get into bloom filter/storing input file elsewhere.

so one final time, pick any math or there lack of that your brain can or cannot conceive and let that be your way of thinking.

I'll refer you to my post, in case you can't scroll up or down or use page buttons:
Notice how I even agreed with you about a lot of haystacks...a long time.

but if you want to make an argument about how I said gpus are dominant over asics, you will lose that too. so just accept that and move on.

well it seems you are doing things the most inefficient way possible.
lets help you save some processes
instead of having a single file of UTXO's and their balance .. where the record is not organised and not indexed...
you could organise them into folder A subfolder AA
                                           folder A subfolder AA
                                           ..           ..
                                           folder 9 subfolder 99
where it organises the utxo into their first 2 hex bits
then instead of having to search all 1mill records. it can just search the file with the same 2 leading hex
meaning only ~3900 searches

you can also then delve into indexes and pointers so that it can then find and specific record without needing to read the whole file of 3900 records. saving you even more search time

if you organise your UTXO database each key creation is 1 UTXO search. at the very most.
there are other ways to decrease this too.. by organising by the first 6 leading hex and disqualifying any results that dont fit thus not even need to search

there is even ways to batch search


as for the math.
you are now being pedantic and knitpicky. whilst missing the point
so one final time

pick any large number your brain can conceive as what you want to pretend that your GPU can handle...
but be semi realistic to the real world
and then realise you will still be seeking your descendants a millenia+ in time to help continue the project

..
but if you want to make an argument about how much your GPU has a hard-on and how asics are limp..
you will lose.
so just accept it and move on

edit to reply to below
goodluck continuing your fantasy of 61000 terrahashes on a GPU.. seems your multiplication is misplaced by atleast 3-6 significant figures

if an asic can do 110terrehash of double sha
and you say your GPU can do 61000 terrahash of ECDSA+sha+ripemd160
then you really cant grasp the numbers

no GPU is hundred of times faster at just the sha part compared to an asic
after all its you that is saying that your GPU can do 61000 terrahashs of single sha operations.

as for your post your numbers change
first its 500m then its 2 or 3 billion..

and 2billion keys you say vanity gen does....
thats 2gigahash.. meaning 0.002 terrahash.... definitely not 61000 terrahash
1,000=1 khash (0.000,000,001 thash)
1,000,000=1 mhash(0.000,001 thash)
1,000,000,000= 1 ghash(0.001 thash)

one last time your GPU using vanitygen does 2Ghash = 0.002 Thash
having to then search records means less than 0.002 thash

That is not how this program works, I'm not talking about any search algo.

The program checks for matches, each time a key is converted. Period.

So in your mind, how does a program work that checks 2,000,000,000 to 3,000,000,000 keys per second for 1 key work?

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

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

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.

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!

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

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?

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.

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.

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

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

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.

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.

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.

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://bitcointalksearch.org/topic/collection-of-18509-found-and-used-brainwallets-4768828

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.

"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

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.