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.

Added 545 social reach

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.

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://bitcointalk.org/index.php?topic=25804.0
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

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.

I am going to look at this as innocent until proven guilty.

If you look back at the large wall of red text which I am not going to quote as it just kept going on and on, the address that sent the 13 BTC only received 48 BTC on March 7th and sent 13 BTC 2 hours after launch.

Isn't it quite possible that this escrow service had two wallets, one of which the investor sent his 13 BTC to, and the other that the escrow service used to then send 13 BTC to the PLC address, thereby protecting the identity of this investor who wants to keep themselves anonymous?

To me this proves reasonable doubt and I would not convict CWC as having scammed the other investors, and at this point what's done is done. If you're an investor and you want to make money off of CWC, stop complaining about the coin that you have invested in and instead, promote and get this coin off the ground!

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.

What I mean by it cuts down on the total amount of variables to try and check against my keys script is that I only have vanitygen generating keys that are between 121-19z and 1A1-1Pz, It is generating more keys than that but those are the only keys being output to text file. By doing that I am reducing the number of keys I am checking against my balance list (which contains only addresses between those prefixes with a balance greater than 0).

I took all of the addresses that had a balance greater than 0 and sorted them by prefix and generated the graph below. As you can see vertical axis is the total amount of addresses that begin with each prefix (horizontal axis).

So in my ever expanding curiosity (yes I know it's damn near impossible but I like the challange of scripting new things) I have re-written a few different scripts in PHP-CLI to make calls to vanitygen to generate addresses/privatekeys and check them against an array loaded with keys/balances.

The program currently uses about 450MB of memory per instance of it running and its checking it against a subset of ~1.3 million addresses or so. I did notice that when making the call out to generate a key I was getting about 0.15 secs/key generated using the options in the code box below and the amount of time to actually check the address against the database was so fast the php function microtime was not able to determine the time. I decided to go ahead and instead of calling vanity gen over and over to generate 1 address at a time I would start up vanity gen in one command prompt using options in code box 2 and run the checking script against the output file instead. Now the problem is that the cpu vanity gen only generates about 240 Kkeys/s on my CPU and the PHP script checks 50,000 addresses in less than 2 seconds.

So I decided I would try OCLvanitygen to generate addresses even faster since my GT440 generates around 2.70 Mkeys/s but I'm having an issue with oclvanitygen that maybe one of you might have some insight into. I have noticed when running OCLvanitygen under -q it will list its generating 2.7 Mkey/s but with the prefix set at "1" it states that its finding 1 or 2 keys per second (output in code box 3). Any idea how to get OCLVanitygen to output all 2.7Mkey/s to the output file?

(PS- the reason for the regex is because 93.94% of bitcoin addresses with a balance greater than 0 are between the prefix 121 and 1Pz which cuts down on the total amount of variables to try and check against my keys script.)

After reading that review on the roast and seeing all of those pictures, I just wonder to myself........ Why is it not April 7th yet! That looks absolutely amazing!! I can not wait to get a chance to try a few different cuts.

Hmm, no response from coin creator after logo contest ends?

Op seems like a real poster based on total posts but has not been active in going on 48 hours.

Name:   eightspaces
Posts:   578
Activity:   98
Position:   Member
Date Registered:   November 02, 2013, 08:59:27 AM
Last Active:   March 28, 2014, 03:27:52 PM <- PST (March 30, 2014 9:24AM PST Now)

He said the Deadline is 29 March 2014 at 00:00 ACT.

I can't wait for the pricing etc. to be released. Those steaks look amazing! Hopefully by the time your ready to start taking orders I am quick enough to get an order in and not miss out on first shipments.

Edit: To answer your questions
1:most desired/popular cuts? 
Ground, burgers, short loin, brisket, sirloin.

2: interest in discounts for larger orders
Possibly, depends on when I can buy another freezer to store it all.

3: interest in discounts for a  medley type order with a combination of steaks, roasts, hamburger
Very much yes, I love almost all cuts of beef and a medley package would work out great for my family.

4: interest in custom cuts , this could be arranged through the packing company I am using
Not really but I'm sure others might be.

Submission Numero 2

My antipathetic take on this coin of which could have potential but more likely will either be a troll of a coin or it could become a coin worth hating, although its more likely the former over the latter.

Well considering I loathe posting on forums and detest the cogitation of missing out on a new coin, I regret to inform all of you that I will be mining this coin upon its release.

Along with mining this antipathetic coin I have also decided to begin working on a new logo for BCX Coin as well.

I do hope my aversion has not caused you animosity towards me in the fact of my abhorrence at being one of the first 500 to be locked into this coin.

Edit: Of course this thread has grown and my revulsion grows as I had to edit this now that the first 500 are locked into this new coin.