Bitcoin Forum

Hi there

I'm started today to put my self concept of dormant address mining on the way.  ;D

After search for some solutions (like vanitygen), I realized that all existant tools are very slow to do what I want.
Vanitygen for example tests something like 30Mh/s (depend on your hardware), but realize that this speed is just to test "vanity addresses" against a match. when you try to generate random addresses, the speed falls to something like 200kh/s (Already tested the variants like Vanity Plus or Super Vanity Gen).

Another challenge is to test all that generated addresses to find some with balance.  :-\

Actually with some dirt and quick self solutions I can Generate and test 1 Million of addresses per minute against a 42k dormant address database, and optionaly I have one huge file (~1 Gb) with +20 Millions Addresses with some balance (random balances from 1 sat or more :P).

I started today and left it on a (free) online server to run 24/7/365.  8)
Another point is that I don't generate random keys, I'm generating sequential from one to 2^96.
At the time of this post I've generated and tested out of 2.071.000.000 key pairs.

My question is what the chances to find one match ? (Yes, I know that exists 2^160 possible addresses), I just want to know the probality, and maybe turns it an online project to use more powerfull processing power (pool).

Sorry for any typos/bad english

Some clarification and tips are welcome.

If I understand correctly you are trying to find a collision address.

I think if you had the processing power necessary to brute force in this manner and find a collision, it would be many many times more profitable for you to mine bitcoins than to try to hack it.

The probability of success is 0.

the biggest reason is that there is a competing endeavor, which also started searching from 0.
So basically you are searching through the exact same addresses that LBC (Large Bitcoin Collider) has already gone through. And you are a lot slower too.
Here is a link: https://lbc.cryptoguru.org/about

Sounds like a fun project  :) I wont discourage you more.

While the addresses technically has the SHA256 hashing during the generation, the speed isn't measured by the hash but rather by the number of keys it generates.

Zero. By the logic of birthday paradox, the least number of addresses you have to generate is 3.65x10^47 out of 1.46x10^48. Even if you can generate 7.92x10^28 of the keys, you are unlikely to find any keys that has actually been used before. No matter how powerful your computer(s) is, you are unlikely to even generate 1% of the total keys that can be generated (2^256).

Assuming that the keys were generated with sufficient randomness.

Yes, collision addresses. like Large Bitcoin Collider Project.

Ins't about profit, but about luck. You are correct, mining is more efective and profitable.

The advantage of generate sequentially is this. If LBC already just tested 2 Trillion Addresses, then I can start from 3 or 4 Trillion ahead  8)

The total keys that can be generated (2^256) i'ts diferent of total keys that will (maybe) exist on bitcoin enviroment (2^160) assuming the fact that exists only private key for a public address we have 2^96 possible addresses. It's a soooo huge number, this is why I didn't turned it on a serious project, just a type of "weekend brainstorm"  :P

Do you mean seed ? Ins't random, it's sequential.

The point is that I imagine to find a collision using some strategies (rather than processing power) that I'm thinking about, like paralel tasks and ocl string comparisson. cheers.

what's the bigger: the universe or the human imagination ?

The total number of addresses that can be generated is 2^160. There are 2^256 possible private keys. The total number of private keys that could potentially correspond to an address is 2^96.

Neither seeds nor addresses are sequential. If seeds or addresses are sequential, we would have cracked every single addresses used by now.

The human imagination. However, practically the universe would be. If we reach the time where we can bruteforce addresses, we don't really need any imagination (or much) effort to expand the keyspace.

Clever. but projects like Large Bitcoin Collider will prove (I'ts already doing this) that i'ts a matter of a couple of "human time" to find a way to generate address collisions. only for information they already find 8 addresses with balance last year. So ins't impossible. I'll keep this thread updated with my search for it.

In fact, on second thought, what if someone generated a private key in a totally insecure fashion.

For example, let's choose a simple passphrase "test" and perform the SHA-256 hash function it to generate a totally insecure private key.

We can do that online on this website (just enter "test"):

https://passwordsgenerator.net/sha256-hash-generator/

The result is a totally valid but insecure Private Key:

9F86D081884C7D659A2FEAA0C55AD015A3BF4F1B2B0B822CD15D6C15B0F00A08

and it looks random.

Now we import this private key on bitaddress.org --> (Click on "Wallet Details" and enter the above private key)

https://www.bitaddress.org

We have now obtained the corresponding Bitcoin address, which is:

1HKqKTMpBTZZ8H5zcqYEWYBaaWELrDEXeE

If we take this address to blockexplorer:

https://blockexplorer.com/address/1HKqKTMpBTZZ8H5zcqYEWYBaaWELrDEXeE

we can see that this address indeed contained some funds in the past, exactly 0.05634513 BTC (not any more).

What do you think, how likely is it to find some forgotten, unspent bitcoins in this totally crazy way?

One could extend this by searching passphrases that are more complicated.

The main assumption, of course, is that people generated private keys like this, just for fun, and then indeed sent some coins to them, which is not very likely.

If you go deeply on this you will start to lose your faith on bitcoin's math challenge, recently I found this interesting post (https://pastebin.com/jCDFcESz) of a guy that have found some addresses with balances that were generated on sha-256 by using a block hash or tx id, in fact this still exists and happen every day. So we have some things that aren't soooo random as they appears.

If you're talking about these addresses, its totally possible. Addresses are not meant to be generated using methods which has low entropy. There are still some people who generate these addresses, mostly as a joke. The possibility of finding one of these that is being used as an address to transact is fairly low.

You would be better off testing brainwallet out. The possibility of finding coins there is way higher.

Yes, the chances exists.
But my point is check if any of those dormant addresses from the past were generated using any of this methods, like brainwallets, sha-256 over a tx id, merkle root or block hashes.
It's just more a proof of concept than a "brute force" attempt.

Interesting read. Thanks for the link. No, the math is perfectly solid and unshakable, and, yes, Bitcoin's network is perfectly secure. And there's nothing to be afraid as long as you generate your private keys the way they are supposed to. But then again, people seem to do all sorts of crazy things, everywhere, not only with regard to cryptocurrencies.

This is what makes me wonder. theres no hidden things, just a big number that is away from human comprehension and (nowadays)  achievement. :o

What is your (and the Huge Bitcoin Collider's) goal by doing this?

Why don't you just use that huge computing power to mine a suitable algorithm to earn Altcoins, convert it to Bitcoins...
and voala! Same results.

SHA
brainwallet is easy, there 'were' about 2,000 addresses from the holy-grail 60gb dictionary that can be found that at one time were high-value, but sadly all those coins are now depleted, I have ran countless advanced brain-flayer on steroids using 100+GB dictionarys and frequently find new coin, but the money is always gone.

U must remember that those 2,000 golden addresses like sha(satoshi1), or sha(cat), they're all search 24/7 by bots and if somebody uses those addresses their money is swept in one second, just stating a fact,

Thus 'searching' address space using sha or any hash algo dictionary is a dead-end, then only real end is going after the high-value public-keys, using high speed advanced methods

***

If I didn't hate amazon so much, I would just setup up a huge AW2 system to search, but I hate giving them money, or using google, or facebook, don't want to feed the bastards

China has cheap, small light-weight GPU cards ( bitmain ) has some, once price goes to a few dollars we should be able to do 100's of billions of keys per second, using pollard-rho algos

***

None of this really matters, once BTC is cracked, they'll just bump from 256 to 512, and then the entire process just repeats; hamsters have been running this cage since cpu's were 1024 bytes of ram

**

U mention merkle, block hash, ... I tried all that stuff years ago, a few morons made keys using 'data', but nobody with real money backed his 'coin' using these techniques;

1.) hashed 'dictionarys' were the early easy gold to be picked off ground, think brainflayer 1.0
2.) using data to be hashed is an urban myth
3.) same for monkey at the keyboard the bible and unix-source will find you nothing, when hashed, I have ran all known text years ago through sha to generate priv's and found nada high value key, not even an empty one

The only real way is smart use of algo's ( pollard-rho, ... etc ), or study how the random keys were generated and use that for a basis of generating test keys for finding priv's

***

U can run gpu-flayers smart, using the 'algos', but the problem is you must let them run, and be very careful about the bloom filter that you put on the cards, as you don't want to deal with false-positives as it slows down the search

I used blooms on the gpu to find worthy keys, then use huge tries to see if they were every used, and if so then use high value tries to filter out the chaff, but when your doing 500 M-keys/sec, even a false positive of 0.0001 generates a lot of garbage to be analyzed

***

I looked at lbc, large bitcoin collider, and the blm filter he gives away and some of his writing and stuff, they're just doing a linear search, and to be honest they don't know what they're doing IMHO; doing a 1  to 10**77 linear search with a dog-shit bloom filter, which means they're just burning electricity; The real problem is in this game is get away from these 512mb toy blooms on brainflayer and jump up to 8gb blooms on on the 1080 class cards, then your good for 1 billion high value addresses and can search fast with low false positives

I have answered this question may times,

there are lots of urban myths rolling around btc, and largely because the majority of user community are math half-wits

btc mining is kindergarten math, breaking btc, .e.g. solving the discrete log problem, is like fermats last theorem, its the holy-grail,

thus IMHO morons mine, and gods solve puzzles

LBC ( large bitcoin collider ) guy is maroon, he's not even a programmer, doesn't have a clue what he's doing, he's doing what we call 'brute force' naive, aka burning electricity, spinning his wheels or other peoples cpu cycles

***

FYI, I do mine, I mine EQUHASH and have written my own gpu software, that out performs ewbf, normally i do zencash; I don't waste my time 'mining' btc, cuz even with at bitmain s9 you don't pay for electricity, do you understand any of this?

Only you will quickly fall behind because you are slower so unless you take compleatly different chunk from the total pool of addresses or manage to do it faster then LBC you will inevitably test addresses that was tested before you

Google "Discrete Log Problem"

There are 1,000's of ways to crack ECDSA ( the bitcoin secp256k1 algo )

Brute force, or linear searching as done by LBC is called the 'naive method', or MORON method in the math world.

I think the focus of your idea should be how to generate the address you want to scan.
Believe me, it doesn't make much sense to scan a library generating from number or a downloading library, because countless people have already done the same thing.
Again, completely random generation does not make much sense, because the sample library is too large.
You should plan your ideas carefully. If you have a creative idea, it makes sense to practice it.

Let's get dirty here on this subject. LBC just goes 1 to N, and uses each 'n' to solve the Q=nP problem, where Q is public key, and n i private key ( 64 hex) and P is the ECDSA 'point' for btc, secp256k.

Now what LBC does is 1*P, then hashes Q and looks in a 'bloom filter' to see if that hash has value, this requires a database ( or bloom filter ) of all known hashes of public-keys, the problem is that the 'funds.blf' bloom filter that LBC uses is garbage long ago I run some high value hash160 values through that blf, and it didn't catch them which tells me that the BLF used by LBC is worthless, which means that even if it hit a high-value hashed-public key, it would flag it!

***

Now let's look at the state of the art in this subject, first lets take 2015 'brain-flayer' which worked, as some 2,000 high-value keys were found and the funds were nabbbed, here what is done is a large dictionary say 14 billion words is hashed one at a time, and that hash is the 'private-key' so a Q is calculated, then 'brainflayer' looks to hash all public-keys near that 'Q' and uses a bloom-filter ( which are bits to mark known hash high value addresses ), if a Q matches the hash, then Brain-Flayer prints out the hash, and private-key(pair), then  anybody can 'sweep' that address and nab the funds.

Problem is that 2012-2014 'brain-wallets' were the rage, by 2015 all funds had been swept, today you can run 'brain-flayer' all you wish on a trillion words, sentences, ... but you will never find a private-key that yields any funds, because there are 100's if not 1000's of people two steps ahead of you.

***

Now state of the ART, there are TWO area's

1.) is the hashed compressed/uncompressed public keys that are used in bitcoin post 2012, earlier they used raw public-keys which are much better to work with,
2.) the raw public-key, this is ideal, because there is less computation, you just generate a private key, and do the Q=n*P multiplication, and then check if that 'Q' has value ( satoshi's coins)

Given that most of the public-keys are still around and some 100k still have value, its a goldmine for people that want to work in that area, and its far better than working with hashed public-keys, as you will find post 2013 in bitcoin blockchain.

***

Something needs to be said about 'bloom-filters' they're bit-arrays that are kept in memory, and say you have 500 million hashed public key compressed addresses we call 'hash160', you can mark your bloom filter to hold info for all these keys, in say a 32 gb bloom filter, and  its a O(1) calc as you compute Hash(Q), and then look to see if that n*P generated your 'gold'

Now the problem of course is 32GB in memory, means you must run a 64GB computer, but nobody said this stuff was easy

If somebody wanted to do the LBC correctly, they would say work with a 512mb bloom filter, which would handle the 50k high-value public keys called 'pristine' from early bitcoin, then using that bloom filter run through the Q=n*P calcs using intelligence.

***

The problem with the 'linear' bullshit as done by LBC, is that there are 10**77 private keys in BITCOIN (ECDSA secp256k1), even though your bloom is 50k, that be 50e3, your still chances of a hit are 1 in 10e74, even if LBC had 4 billion ppl ( all on earth ), his chances would still be 10E60, and remember there are 10e23 atoms to a mole, and we're talking about most of the atoms in the known universe. This is why linear is a waste of time.

People for 300+ years have studied these LARGE prime number, and much is known about factoring these primes, this is how I tackle this problem, by factoring primes, which leads to the search space dropping from 2**256 to 2**40, then using super fast GPU, you can fairly quickly factor a large 'Q' public key, note that the Q has two parts (X,Y), you don't need one or the either, just one, if you know X, you can calc Y, and vice verse, so that drops the search space smaller,

***

The way I tackle this problem is 'FACTOR' all the public-keys known to date by scrubbing the block-chain of all public keys, and then using advanced state the art discrete-log solvers, along the way while I find private-public key pairs that don't match my criteria, I keep them if they match my bloom filters, I might find 10k such pairs a day, which means millions a month,

The search space for known BITCOIN used addresses unlike public keys is 50k versus 500Million, or perhaps as much as 2 billion, while I'm doing say a daily search on all 'lint' pairs, I will use a TRIE which is a 256GB ordered-list of all known hashed addresses ever used having value or not, and look to see if one of my pairs match, if they do, then it goes into another database.

The IDEA here is we're searching for the GOLD by intelligent factoring, but  along the way we're also keeping any gold-dust seen, now there is NO way for LBC to do this cuz, they just use the basic 2015 512mb, that misses all

Another thing is that high-value key-pairs are grouped as familys, so once your 'close' you can find pairs from the same family.

When I do the factoring, I use 1080 GPU class boards, where I can put a 8GB bloom filter, so I can catch say 512MB addresses, which are essentially almost all the addresses ( hashed ) with value, also because the bloom-is done on board gpu, and all the calcs, its easy to get more than 100 Million keys/sec scanned, which is 100X faster than brain-flayer, and ten times faster than super-vanity

***

Another major part of all this is managing addresses hashed, and managing key-pairs found, and looking at the memory-pool updating new addresses, and then scanning those new addresses in the 'found' key-pair database.

I find in general the 'management' problem of all this to be the most over-whelming problem, as once most of the gpu sw is working, its pretty much done, but the database management problem of dozens of 64gb blooms and many 256 gb TRIES means you need to invest in lots of hard-disk ( ssd )

There are two really interesting DefCon talks, regarding this Topic:

https://www.youtube.com/watch?v=foil0hzl4Pg&t=1112s

https://www.youtube.com/watch?v=f2s3_UG9IPU


I thought this might be interresting, for some of you1

Thanks, I actually have not heard of this technique :) great videos.