Topic: 2^256 Deep Space Vagabond - page 3. (Read 38659 times)

I like this game!

Alright, so we all know imagining massive numbers is almost an impossible task. We can barely get our mind wrapped around numbers reaching the billions, let alone anything larger than that. With that in mind and feasibility aside, let's break this down financially instead.

Following BurtW's thinking:

And following Hyena's quote:

Let's say that, hypothetically, you had access to futuristic solid state SAS drives, granting you a full terabyte (1024 usable gigabytes) per 2.5" drive, only consuming 0.1W of power, and costing $100 each.
But let's take it a step further and say that you've got some supreme hardware/software compression capabilities that bring that 32 byte space requirement per address pair down to 16. At 16 bytes per address pair, each drive could hold a bit over 68,700,000,000 generated pairs (2⁴⁰ / 2⁴).

To hold the 1 quadrillion pairs you've mentioned, though, you'll need 14,552 drives.

Those drives would have an initial upfront cost of $1,455,200, but you'd need to use them somehow. What about a handy 4U 60-bay JBOD enclosure? That should work...though you'll need almost 243 of them, tacking on an additional $2,428,785 (before shipping, $9,995 each).

What about space? At 10 enclosures per 42U rack, those 243 4U units will take up at least 25 racks before additional equipment (servers, switches, firewalls, PDUs, etc). That's some expensive hosting.

Thankfully, the power consumption is negligible at this point. Ignoring the enclosure (which has a 1200W PSU), the drives alone will consume 1,456W. Don't worry though, the magical datacenter that stores all this equipment only charges $0.02 per kWh, so you'll only be paying $0.70 per day for all of them. Include the enclosures and you're probably sitting at somewhere between $30-$70 a day. Pocket change for what you've paid already.

So now you're at an initial cost of $3,883,985 just to be able to store the quadrillion addresses.

But let's say you've done it. You've put in the time, effort, and financing to secure the space needed to hold the addresses you've generate. As you look over the 25 racks of humming hardware, you begin to realize that you're now the owner of only 0.00000000000000000000000000000000000000000000000000000000000000000000000000011 579% of the total number of Bitcoin addresses that can ever possibly be generated ((2²⁵⁶ - 2⁵⁰) / 100). Congratulations on your achievement, and one can only hope you manage to win a lottery bigger than BTC3.3 for your efforts.

As I understand it the idea is to have "a lot of people" continuously monitor "a lot of addresses" just in case one of them gets used in the future then, bam, take the poor saps money.

Now that I think this through a bit more, to do this they would have to store every private key they generate (so they can steal the money) plus every public key generated (to match to the incoming transactions in the blockchain) on the very off chance that one of them gets used in the future.  So, the storage requirement is not just the Bitcoin address or public key, it is at least all 256 bits of the private key + the public key(s) for pattern matching.

There's no reason to start a new thread. This one has a fair number of subscribers all interested in DSV's goals. AFAIK, DSV is abandoned ATM. I doubt OP cares so long as chatter is relevant to the implicit mission statement.

I'd suggest the biggest indication of dysfunctional "address trolling" is that you need a lot of disk space. Why bother keeping addresses -- you'd just want to check them for coin or if they're likely to be active, yeah? If you have a backlog of 1.18PB, the software, I'd argue, is dysfunctional. The addresses should be checked as discovered to determine if they're active or hold coins, or both. In cases where coins are found, they should immediately be sent to the thief's address, but then they shouldn't be stored in memory since the legit owner knows it's compromised. In cases where the address is found to be active, it should be stored on file, but suggesting you need 1.18PB in storage for this is ridiculous. You've found 5 addresses with coins, right? Why store the other 1.18PB of them? Why are we even talking about storage space with an effort like this? You want to prove a government could monitor all these addresses, but this can be proven theoretically -- we know they could store a significant number of all addresses, but the trouble is in generating all of them and checking them, yeah?

If you're a thief, why release the software publicly? You sound like a white hat trying to pretend your a black hat (a "hyena"), so maybe just very humble -- one of those hardasses with a heart of gold. The alternative would be that you're full of shit and have dysfunctional software unable to achieve its goals. I doubt you, but don't mean to come off as hostile... I don't hold many coins but am definitely interested in objectively learning about progression in this field. All the best!

I will use 32 bytes per address (2⁵ bytes per address) in my response.  Storage of addresses will actually take more than that so rounding to 2⁵ is in your favor.  I will also give you binary megabytes, terabytes and petabytes of storage which also works in your favor but makes the math easier.

Just an empty claim until you prove it.

1 binary PB = 2⁵⁰, 2⁵⁰ bytes / 2⁵ bytes per address = 2^50-5 = 2⁴⁵ addresses, 2¹⁶⁰/2⁴⁵ = 2^160-45 = 2¹¹⁵

Which means that for every one of your 2⁴⁵ addresses you have generated there are 2¹¹⁵ addresses you have not.

Multiplication and division, adding and subtracting of exponents is very basic math.

Not exactly sure what you meant by "a few thousand people" or a few quadrillion addresses so how about 4,096 people each with 16 binary quadrillion addresses?

2¹² x 2⁵⁴ = 2¹²⁺⁵⁴ = 2⁶⁶, 2¹⁶⁰/2⁶⁶ = 2^160-66 = 2⁹⁴

So for every one of the 2⁶⁶ addresses you have generated there are still 2⁹⁴ addresses you have not.

You will never get even close to 1%, lets call it 2¹⁶⁰/2⁷ = 2^160-7 = 2¹⁵³ addresses, never.

No the fed has not done this.

Faulty random number generation is bad, very bad.  However it is faulty random number generation, not a flaw in Bitcoin itself.  If true (that many addresses were generated using a faulty random number generator) then thanks for pointing that out.  I use hardware random number generation so I feel pretty good about it.

Very comfortable, due to the math showing that is a very small amount of the total address space.

I am working on a 40TB drive, so what?  Still nothing compared to the entire 2¹⁶⁰ address space.

No, I am an engineer using a hardware random number generator who understands and can do basic math.

Can't wait for your WHOLE story.  Can't wait for you to prove you have moved 3.3 BTC with your method.

Sure, I am a developer with 30 years experience working on hard disk drive firmware.  Send me your information packet and I will take a look at it.

Question:  why not start a new thread now?  What is stopping you?

We just wanted to add,

We can have this discussion on another thread soon, we do not want this to hijack DSV's thread. we just wanted to make a quick announcement in a place where interested parties were hanging out. If you feel you have some trolling to do, message it to us for now you can copy/paste it in a few days when we get our own thread up and running. Lets let the OP keep his thread clean and on topic.

Or better, just over 1 PB worth of data storage and we managed to nab a few transactions from the blockchain already. Next, it has nothing to do with basic math, there is nothing basic about the math behind any cryptographic function. Lastly, who needs 50% of the addresses? if a few thousand people had a few quadrillion addresses each it makes up a large enough percentage that a person is no longer chasing a moving target. It also means that every time you move your bitcoins, you have to wonder...... Has someone got the key for this address?

Ask yourself, how many bitcoin supporters are going to feel comfortable with their investment knowing that 15%, 10%, 5%, hell eve 1% of all bitcoin addresses are indexed and monitored. (the fed has already done this, that is where this project stemmed from)

Imagine everyone involved in crypto currency to date had the ability to randomly generate addresses using the same faulted PSRNG system that 80% of wallets use and fill even 100 gigs of space on a hard drive. How comfortable do you feel with your investment then?

Imagine as hard drives and storage become cheaper, As is we are already buying 6TB drives for $190usd. You can already go make a $70 investment and buy a 1TB external. With our software's it would take maybe a week for you to fill it and monitor it in real time. take that multiplied by even a thousand, and growing daily. How comfortable are you with your investment then?

Imagine next year when Segate launches its first 10TB 5,200rpm HDD for only $350. (already in the works) Thats pocket change for most of us here....... You get the point. How comfortable are you with your investment then?

If you can honestly say that you still have no worries about your bitcoin after taking all that into consideration, then you sir are an idiot with no common sense.

Granted we are not giving you the WHOLE story yet, waiting on a few final developments that will make it all more platform neutral and basic user friendly so we are not just talking about it but letting everyone do it. But in summary, about a year ago, we were where you are now. In the very recent past, we have hijacked about 3.3BTC from a total of 5 addresses.

Developers who want to join the team and help spread awareness get the source now pending their contributions as well as a basic overview of how it works. The rest will have a beta platform within the next month or so to start cataloging their outputs, in a few months anyone who has some hard drive space that wants to catalog some bitcoin addresses has a chance to play along.

Final disclaimer,

Yes, if we find bitcoins we are taking them but this is not about being thieves. its about making people aware that 75% of the hype about bitcoin security is FALSE, even by the admission of some of the current bitcoin core developers. A direct quote from one of them in a recent interview "It is scary how many people have invested so much money in such a young technology that is filled with security flaws". We ourselves could not possibly steal enough bitcoin to make a difference, but as a community (full of thieves anyways) we could chip away at it and tally up enough hijacked coins over time to force the hand of the developers to assess the important and most prominent security flaws NOW before it drives bitcoin into the ground.

If you want to troll, go for it, we all love a good laugh and 80% of us on this forum are only here to see the dumb stuff anyways. Otherwise, just hang on and we will get you software soon so you can participate and put some of those old no longer used hard drives to good use.

BTW: Yes Hyena's laugh, ever wonder why? THEY ARE THE BIGGEST THIEVES IN THE ANIMAL KINGDOM

Hyena?  Do you mean Laughing Hyena as in this is a total joke Hyena?  Or, worse yet you are serious and just not very good at basic math?

Is your plan, by any chance, to generate enough addresses to own a majority, or to own enough that there might be a slight possibility someone might accidentally send coins to the wrong address and end up in one of the billions you've created?

At roughly 38 bytes of uncompressed space per generated address through vanitygen (in text format), you're looking at somewhere close to 11.5 septillion petabytes of storage needed for only 2¹²⁸ addresses that could be generated...or 1.6 quadrillion petabytes for every man, woman, and child on this planet.

Amazing to see the community pulling together to finally point out a serious weakness in Bitcoin. We. the Hash Hyena's have been hiding in the shadows for a long time for developers to put their talents to use in forcing hard fixes to some of these weaknesses.

Thank you to all of you developers for your efforts. We do not care how much a misinformed community may laugh at the probabilities, and big numbers like they mean impossibility. Its real, it has happened, and it will continue to happen.

For any developer that would like the proof, and like to join forces with the Hash Hyena's on the "Hash Hyena" project to further development on our new platform that we intend to open source and soon release to the world please message us directly through BitcoinTalk.

For the rest of you, If you want to get leaps and bounds ahead of everyone else in the game when we officially launch the Hash Hyena software do these two things.

1: start stocking up on hard drives. The more storage space the better. ( we currently have 1.18PB and growing )

2: run the line of code below in vanitygen, make tons and tons of output files and start storing them, we will soon release the program that converts them into .csv files that we use for importing. The more files you have when we launch the further you are ahead of everyone else when this all goes public in a few short weeks or months.


We will be releasing a batch file for those of you with high performance CPU's to run multiple outputs at a time in a nice little packaged .rar download. We will be starting our own thread soon

anywhere to download?

Link to flatfly's google code page for deep space vagabond. https://code.google.com/p/win-electrum/downloads/detail?name=dsv-1457.scr

The 2^256 Deep Space Vagabond program does use your CPU and yes it works like vanity address finder accept in continually creates more and more addresses and checks them against a known list of lost Bitcoin addresses that have bitcoins on them, but like everyone has said in this thread the possibility of finding a single one is so infinitely small it would not be worth even trying.

The likelihood is so small that if you put every single computer on the entire earth that has ever been produced, took all of the individual computer parts that are not in computers and built computers from them, added in all of the super computers and servers, cell phones, iPads, tablets, nooks, kindles, gaming consoles, and every other digital device that could ever possibly calculate a Bitcoin ECDSA key pair and perform SHA256/RIPEMD160 functions on the keys, it would take longer than the universe has been around to generate all of the possible keys.

Well considering all of the letters except npw are capitalized I would say that  the regex is something along the lines of

EDIT: Forgot the $ at the end lol.

EDIT2: It seems the regex done by vanitygen is actually different than regex done by Ruby or PHP. The above regex or even the below regex both only match patterns like your address when done in Ruby or PHP but VanityGen seems to return strings with lowercase letters other than npw even though its not allowed by the regex.


In ruby/php out of these addresses, address 1 and 3 are found and address 5, 6, and 7 are addresses that were found by vanitygen but are not matched when added to the ruby/php list to check.

Thanks for the offer, but I'm interested in much more difficult regexs than '1abcde'. See if you can figure out the regex I used in the address I posted above.

My GPU can run through 2.78 Mkeys/second if you can generate a ECDSA public/private key pair and PM me the public key and the vanity address you would like (up to about 5 or 6 characters (including the 1 prefix)) I'd be willing to generate a public/private key pair that comes out to your preferred prefix. The way it works is

Your Private Key -> Your Public Key

Generated Private Key -> Generated Public Key

Your Public Key + Generated Public Key -> converted to Bitcoin Address with your preferred prefix.

I send you the Private/public keys -> you add Your Private Key to the Private Key I send you and then import that into your wallet.

the vanitygen programs are setup to accept this type of setup and by doing so your still protecting your address because only you have the private key that generated the public key you give me to generate your vanity address. I'd be willing to do it free of charge but tips are always welcome

EDIT : If you are interested you would need to get the vanitygen program (if you don't already have it) https://bitcointalksearch.org/topic/vanitygen-vanity-bitcoin-address-generatorminer-v022-25804
Then run from a command prompt
This will give you a private and public key, of which you would only need to send me the Public Key (Hash) which would look something like

If I was able to get 2 mega-addresses per second, I'd have an absolutely awesome personalised address. Even this address took weeks of CPU power:

1QC2KE4GZ4SZ8AnpwVT483D2E97SLHTGCG

I've noticed it will pull/show that it is "finding" ~ 0.404% of the addresses generated when searching for the prefix of "1" or 0.389% when searching with 1[2-9A-P]. I did some more testing as well and found 1[1-9A-Za-z] found at ~0.399%, but 12 found at ~0.402% so I'm pretty sure that vanitygen is finding more than what is being reported (especially when using the prefix of just 1) and that the maximum addresses it can output when hashing is around 0.4% of the hashes generated, I might take a look at the vanitygen source tomorrow and see if I can find a way to have it output all found addresses to a text file instead of only the hashes it finds and possibly update oclvanitygen to include regex searching, if I can I would be able to have oclvanity generate about 2 million addresses per second (maybe less considering the regex) and my PHP script is able to check about 2 million/second as is. That would equate out to be about

120 million addresses per minute
7.2 billion addresses per hour
172.8 billion addresses per day
1.2 trillion addresses per week
62.9 trillion addresses per year (or 62,899,200,000,000 per year using a AMD Athlon II x4 760k, 4GB of 1600mhz RAM, and a nvidia GT 440).

as earlier discussed in this thread because of log(58^34) / log(2) ~= 200 a single bitcoin private key is actually only about 200 bits not 256 bits, following this 2^200 is ~= 1.606938e+60 or 1,606,938,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000

1.606938e+60 / 62.9 trillion = 2.554783e+46 years to generate the entire bitcoin keyspace so its still unreasonable to believe that I will ever find an address that contains bitcoins.

Still, I am going to continue to run and continue to develop the script mainly because its fun and challenging and a great learning experience learning how the keys are actually created, the checksum and learning about ECDSA encryption which I have not personally dealt with before now.

Only difficult part tomorrow is if I do get oclvanitygen modified and rebuilt and it does produce 2Mkey/s output to a text file... I'm going to run out of harddrive space on my 2nd partition which is running the program in approx 98.304 seconds (@ 100MB/800K keys) so I may have to break out one of the 1TB drives for this project lol (although even 1TB will fill up in ~ 69 minutes).


EDIT - I did just realize I have only been using vanitygen not vanitygen64. With vanitygen64 I am still only "finding" ~ 0.4% of the generated addresses but I am generating at a faster rate and "finding" ~ 750 addresses per second.

500 addresses per second is pretty good, I found a python generator which could only do about 100 per second. It'd be nice to know why vanitygen is so slow at generating real addresses.

Is it still slow if you define the first two characters instead of just "1" ?

I don't believe I am slowing down the generation process because as seen in my original post vanitygen can only "find" so many addresses per second, even using a prefix of 1 (all bitcoin addresses) it still only "finds" ~ 0.4% of the addresses generated. I believe I am going to have to implement address generation directly within PHP using something along the lines of Zamgo's PHPCoinAddress.php https://github.com/zamgo/PHPCoinAddress/blob/master/PHPCoinAddress.php and see if I can't speed up the process of address generation that way. Even if I can get it to iterate at about 500 address per second it would be generating faster than vanitygen can "find" addresses.