Bitcoin Forum

This is my new pet/toy project! It's a (mostly) ASCII screensaver, made for those who still don't get how insanely large 2^256 is and want to get a first-hand feel of the sheer size of the Bitcoin keyspace, in a somewhat fun way...

The Deep Space Vagabond will slowly crawl through the 2^256 keyspace for addresses with non-zero balances!  OK, you probably have much better odds finding extraterrestrial life or winning the Powerball 5 times in a row than stumbling upon such an address, but hey, who knows? Why not see if you're the luckiest kid in the universe? And also, this is FREE! :)

https://i.imgur.com/pXbf5.png

Although there is no help file or documentation at this stage, it is extremely easy to use - most stuff is automatic: just watch and hold your breath... :)


Latest release: Version 1.475 for Win 2000/XP/Vista/7 (955KB, February 2013)

Download (http://Download) - VT Scan (https://www.virustotal.com/en/file/1dcaec18882442ab4f318093041a698b0a0b221b61a74f14800744a9c0a08dd5/analysis/1361909806/) - SHA1: 3d05a6979ea6691c52b7461acf724a52beb18ed1



!!A word of warning on downloading Windows executables!!

It's highly recommended not to blindly download random executables from the WWW.
I do guarantee that this app does no malicious things, but my recommendation for optimal security on Windows is to either run new executables in a sandbox (such as Sandboxie) or virtual machine or, for the technically-oriented, compile them from the source code when available.


Source code:

After carefully considering whether to open source it or not, I have decided to only make the source code to the initial Python-based (command-line) prototype freely available to all.
However, the full source code to the current version is available on donation only (amount TBD).


Installation: (Windows-only for now)

Just download and launch. It should run out of the box, there are no particular runtime requirements and no admin rights are needed.


Credits:

Design and coding: flatfly
Startup screen logo: turbomilk
Uses some features of vanitygen by samr7 and curl by Dirk Paehl.
Fetches balance data from the blockchain.info API or a local bitcoind + ABE installation.

[reserved]

just a warning.... don't run random executables linked on this forum...  :o

Sure, sound advice!

I do guarantee that this app does no malicious things, but I agree that
to be on the safe side in general, either run executables in a secure virtual
machine or sandbox (such as Sandboxie) or compile them from the source.

The (real short, exactly 75 lines more like 400 now) source code for this app will be released soon. I need to clean it up a little and make it more readable - it's still a little messy right now.  

[EDIT] see top post

Very cool Project, even though of course it's a bit 'pointless'. What happens when (as in before the sun dies out) you find a non-zero balance? Also- does it support GPU's? :-)

Also- can you export all these Bitcoin addresses and Private keys? IE: can it double as a key pair generator?

When it strikes gold, it will play a nice little sound (and highlight the matching private key) to celebrate the once-in-a-(galactic)-lifetime event!


I don't plan to support GPUs for now as this is just meant to be a toy, and the bottleneck is the networking (balance checking) step anyway. And my goal is not to ddos blockchain.info ;)

Your goal may not be to do that to blockchain.info, but it is still exactly what you are doing.

Ive actually written a similar cmd-line app, but it uses a file with exported addresses that have more than 50btc in them.
ABE is very useful here, albeit slow to import the chain.

Actually I do a *really* slow scan (remember, this is just meant as a toy anyway, nobody should realistically expect actual results from it) so it shouldn't have any significant effect on blockchain.info API resources (less than something like btcbalance for example). I will check with piuk if he's OK with it and modify it if not.

Sure, all addresses along with their private keys are automatically exported to a file on the desktop (the location will be changed to something more sensible in the next release)

From my experience, there were different ways to get the current user's home directory under XP and W7. You'd need to handle that properly.

You should sell this on the darknet as a hack tool. It might get script kiddies' botnets occupied on something less damaging than attacking pools :)

I CANT WAIT TO UNCOVER ONE OF PIRATE'S ADDYS
HERE WE GO



I bet if someone does find an address it will be .000001 bitcoins or something lol

Not unless you have a list with address to look for. The ones I suggest trying to look for are Satoshi's addresses since it's unlikely they will be spent anytime soon, if ever.

2^256 = 0.0012 x visible atoms in universe

We're screwed!  ;D

http://www.wolframalpha.com/share/clip?f=d41d8cd98f00b204e9800998ecf8427emn0uedi8jd

According to this "scientific" theory we indeed are: http://en.wikipedia.org/wiki/Omega_Point_%28Tipler%29#The_Omega_Point

Somehow I doubt that. I am more inclined to believe that a planet has a billion times more atoms than that number, considering a human body has a similar value, according to this article:
http://education.jlab.org/qa/mathatom_04.html

But I am no physicist.

I haven't received a response from piuk yet, but am already considering alternate data sources and make it a user option as to which one to use.

Got a nice response from piuk, so that's cool! He's ok with it as long as I use a custom user agent in my request headers so he can keep an eye on the load.

So I'm going ahead and will develop this a lilttle more!

I envision DSV to eventually double up as a fast address generator, watch-only  balance checker,   dictionary-based brainwallet bruteforcer, and screensaver.

It will also support easy drag-and-drop of custom TXT lists with brainwallet sha256-formatted private keys, or 'interesting' addresses such as satoshi's addresses, top 500 rich addresses, etc :)

As I'm currently travelling, development will not resume immediately, though.

The Deep Space Vagabond is worst than any lottery, any gambling casino, any search for alien life, and gives false hope.  Other than that it is fun. :-)

As hopeless as the seek for a private key with a balance on it is, I applaud the efforts of this program!

It's GPU-accelerated?

It's likely CPU-only.

OK that settles it, I'm in.  
*fires up Beowulf cluster*

If you mine with a CPU you will have a practically inifinite better chance of finding bitcoins than with the DSV.

Can you show me how you calculated that?

Using this calculator, http://www.alloscomp.com/bitcoin/old_calculator.php, at the current difficulty rate it will take on average only 31,145 days to find a block with a CPU which has 4200 kilohashes/second.

I don't have the maths for the DSV, but 2^256 is a lot and a computer that tries to find the private key by brute forcing it will take longer than the age of the universe.

Usually, if money is involved, thus higher motivation anyone can try to find a weakness in whatever algorithm.

So I've decompiled it, and this is what the source looks like:


1. Build the GUI
2. Output a random string of characters for the address
3. Output 0 for the balance
4. Repeat

 :D

Why even bother piuk ;)

FTFY

Not like it will change anything :P

I guess it's just sarcasm, but if not, well I confirm that the app (v1.01)does query blockchain.info for live  address balance data.  Anyway, you can use any network sniffer worth its salt to verify this.    

That said, it's true that the current code is quite trivial and not to be taken too seriously (as announced in the OP).

 Not like it makes a big difference anyway!

Version 1.1 is out, with more intuitive operation, a custom HTTP user agent and cleaned up temporary files.

Also, unlike all those other things, it is free! :)

Do the math again.

Number of atoms in the human body according to your article 2,3*10^28
2^256 ~ 10^77
Number of atoms in the universe ~ 10^80

The greatest shortcoming of the human race is our inability to understand the exponential function.

any news on when the source will be released, or atleast a github?

Before releasing it, I still need to:

 1. clean up the code (Didn't have time for that yet and it's now at it's now at 200-ish lines)

 2. look into how to prevent abuse/malicious usage once the code is public: the
    executable has some built-in throttling to avoid hitting on data sources
    too hard.

In the meantime, I may post the super-short initial Python-based version of the code (version 0.1 which was VERY slow), which was actually using Electrum servers for balance checking. Not sure if people would find that interesting.

BTW, a new feature in 1.1: you can drag and drop a text file containing a list of arbitrary addresses onto the GUI to quickly view their balances. For this to work, make sure each line begins with 8 colons and a space. For instance:

If you release the source code, no one is stopping anyone to remove any throttling.

It can't be that hard to re-make anyways.

Yeah, this is what I'm worrying about. I will probably make the v0.1 code public and the current (more potent) version of the source code available on donation. But I'm not sure yet, need a few more days to think it over. And of course, I welcome any suggestions/feedback.

new version, 1.31:

changes:

 new logo on splash screen
 sped up the keypair export to clipboard procedure
 and drag & drop feature

see OP for download.

New in v1.33:

-  new 'BlitzGen' mode for fast key generation
-  convenient keyboard shortcuts for all buttons

OK, I'm gonna take a little break from this now...

New feature added:
 Instant highlighting of patterns matching non-empty addresses that were last used in 2010
  (extremely likely to be lost coins)


EDIT:
Found a bug that is causing a freeze at startup on Vista & 7.
I've suspended the download until I resolve this (shouldn't be too hard, hopefully)

Version 1.42 has been released!

- Windows Vista/7 startup freeze fixed
- faster address generation
- Now autoconnects to local ABE server if detected!  (thanks, grimd34th)

https://i.imgur.com/JeOWx.png

Hmmm... Got some reports that it's still running slower than it should on Vista/7 (even though it's no longer freezing).

Running it on an XP system results in significantly faster response times.
Not sure why that is - still investigating.

[EDIT]

Version 1.43 is ready!

Fixed a few GUI bugs, and it should be noticeably faster on Vista and 7.

Seems like you're having fun with this and it's pretty nifty, even if useless.

I'd like to suggest one thing though. I think you're doing it backwards. You gen keys and check against blockchain.info and are limited by how fast you can check them.

Instead why don't you make a database of actually used addresses that contains balances, and update it with each block that is created with the blockchain.info getblock api. This means you only get new addresses/balances approx. once every 10 minutes, so minimal ongoing network load. And a small seed db could be shipped with the program.

Then gen your keys max speed and check each on in the local "significant address" db. This db could be an address tree in memory for max speed so you could feasibly run at max GPU speed and check addresses at that speed. And it would work without network access almost as well, as long as you connect and update now and then.

If you want 50btc balances and there is 10 million btc in use then you would only have max 200,000 addresses in your db. You could set a threshold of target balance to raise/lower this. Another thought - make the address search space dependent on some system unique value, perhaps mac address, so that every user is very searching a different region.

Technically it would still be useless but probably a few orders of magnitude less useless.

I don't think it's worth the effort to make something from nearly totally useless to slightly more useful but still nearlly totally useless...

Thanks for your comments - Indeed, I just find this project mildly entertaining and might eventually make a little screensaver out of it ;)

I do agree with your suggestions, though, and am currently testing a new version that searches against a local database of non-empty addresses only. My implementation still has a lot of room for optimization but I'm not sure if it's worth spending more of my time on it.

did anyone find an adress yet? ^^

Not yet... better ask again in 10000 years :)

And here's the screensaver edition!
A few rough edges still, and no configuration options yet, but it should be somewhat usable already :)

Download (http://win-electrum.googlecode.com/files/dsv1455.scr) - VT Scan (https://www.virustotal.com/file/1892a82be7b9a43e19c2623ac84bf60230b0aba06f199074649770229af1545d/analysis/) - SHA1: af4e2b27e6536a10647add148a0e1002b34f394b

Note that it's not a true screensaver in the sense that some pixels are always on. I'll address that in a future release.

sure, gimme the technology to survive 10k years :D

So the screensaver version... what does the G mean?
How do I tell how much is in each wallet? Im guessing // means none?

People are awesome and you all are a pure example of that.. This thread is great, the idea behind it and the scale of the number, and it's not useless it might be with it's target but in reality it's very entertaining and makes you ask yourself greater questions.

Thank You  ;D

http://rm.awarenessnetworks.com/8644722140882922018.jpg

Here (http://bitcoin.sipa.be/addrs.zip) you can find a list of all addresses and their current balance, as of block 207681.

Load them in a nice hash table in your program, and stop hammering blockchain.info or some SQL database.

PS: at 2.5 Taddr/s (about the speed address mining would reach if all Bitcoin's hash power were converted to GPU-optimized address mining code), you have about 0.000000000023% chance of finding one match per 4.54 billion years (age of the earth).

And even if you did, I'm sure any competent jurisdiction would consider it fraud to sign a transaction with the bruteforced key spending money that isn't rightfully yours.

New release! Version 1.457 (minor update) fixes a nasty bug that was causing some matches to be missed, and cleans up the user interface a little.

Download (http://win-electrum.googlecode.com/files/dsv-1457.scr) - VT Scan (https://www.virustotal.com/file/69fb9ccb34692413851cf671412d3c22d2b1cb31197bf374c9e68b1dfc86ec9c/analysis/1352838038/) - SHA1: 3ce34a480fd1f52da3056be0115ee9df8ca40c68

G means the address has been Generated (as opposed to Imported).
To reveal the (live) balance of any address, simply double-click on it.

Starting a few versions ago, DSV's behavior has been modified: it no longer auto-checks each and every balance, but relies on a RAM-loaded "Hotlist" to detect interesting addresses instead. The Hotlist currently contains some of Satoshi's addresss, each containing 50 BTC.

// just means no match was found with any of the Hotlist items.  



Thanks for this list! It'll be very useful. I guess you generated it using znort's tool?

And by the way, see my reply to Mushroomized - I've switched to a local hashtable-like approach (the Hotlist) already :)


I'm glad you got the idea behind the DSV "pet project" perfectly! And thanks a bunch for your nice words.

No, a 10-line patch to the reference client code. It took like half a minute to generate the list.

Also, even seeing those numbers doesn't make you want to contribute in a somewhat more useful way?

ty for the answers. Bye the way, you should add some particle effects to float around the screen (include black ones) to get the pixels on/off

True. However, the odds of this happening are so mind-blowingly remote that I wouldn't worry about this at all(*)... which is actually the point of DSV.

(*) unless a serious bug is found in the core algorithms, in which case bitcoin's value instantly becomes zero anyway



Interesting patch. Will it be in the next release?


Hmmm... I do contribute to other more "serious" Bitcoin projects as well, but try to keep a low profile.

On the other hand, Deep Space Vagabond is meant to be a *fun* project - yet I don't think it's totally useless:

• It makes people think about the size of the keyspace in a fun way - and could make *them* want to contribute as well
• Once it's a bit more polished, it could become a nice (if unusual) promotional tool for bitcoin
• It helps gambling addicts waste less money on stuff like satoshidice, which is negative EV while DSV, surprisingly, is positive EV (as it costs nothing to "play") when you think about it in a strictly mathematical sense :)

No, I think this has Deep Space Vagabond has a negative ev as well. Assuming we ignore computer purchase costs, the cost of electricity to run DSV will be, on average, significantly more than you can expect to earn unless you're extremely lucky extremely something - some other word that means you've had luck beyond human comprehension.

Note: Of, course this is barring the discovery of essentially free energy, or  ~ 10^80th increase of USDBTC exchange rate (depending on mean found amount).

EV calculations for games rarely take into account factors like equipment or electricity costs, so I didn't, either...  But I do agree with your point, obviously.

base 2 (using 1024)

log(2^10) / log(2) = 10

log(1024) / log(2)
6.9314718055994530941723212145818 / 0.69314718055994530941723212145818

... = 10

... which makes sense:

you can define 1024 as a binary 1 followed by 10x zeroes
alternatively, as 1 plus the binary value of the largest 10-bit number (all 1s)
as such, a 10 "bit" number has the first value of "zero" and the highest value you can express is 1023 (the 1024th in the sequence starting with zero)

---

base 10 (using 1 million)

log(10^6) / log(10) = 6

log(1000000) / log(10)
13.815510557964274104107948728106 / 2.3025850929940456840179914546844

... = 6

... which makes sense:

you can define one million as a decimal 1 followed by 6x zeroes
alternatively, as 1 plus the decimal value of the largest 6-digit number (all 9s)
as such, a 6 "digit" number has the first value of "zero" and the highest value you can express is 999999 (the millionth in the sequence starting with zero, discounting negatives, fractions, etc.)

---

34 "digit" (base 58) bitcoin address:

log(58 ^ 34) / log(58) = 34

log(58 ^ 34) / log(58)
log(9.0479831084470077531332721514049e+59) / log(58)
138.05506235857825744441714122988 / 4.0604430105464193366005041538201

... = 34

So how many bits (binary) are required to store that?

bitcoin address can be defined as 34 "digits" of base 58, therefore:

log(58 ^ 34) / log(2) < 200

Wait, really?

log(58 ^ 34) / log(2)
log(9.0479831084470077531332721514049e+59) / log(2)
138.05506235857825744441714122988 / 0.69314718055994530941723212145818

199.17135383433745210447229303735 (round up to 200 bits)

Similar math is used to determine how many bits of entropy exist in a given passowrd pattern.

Bitcoin addresses DO NOT go up to 256 bits. They are basically only 160 bits, plus additional checksum / error-detection padding:
(citation) - Technical background of version 1 Bitcoin addresses (https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses)

... potentially, it is possible to have a collision for which two different private keys (actually 256 bits) match up to the same bitcoin address (34 base 58 "digits" / 160 bits / whatever)

---

Another fun math thing. Earlier, someone was trying to figure out if 2^256 was closer to the number of atoms in the universe (or the visible universe, or a fraction of these atoms, or the atoms in a person)

2^256 atoms?

Well, every "mol" of hydrogen atoms weighs 1 gram:

(cite)  -- Avogadro constant (http://en.wikipedia.org/wiki/Avogadro_constant) so aprox: 6.02214 * 10^23

great!

Now for some math & logic time:

(6.02214 * 10^23)  = number of hydrogen atoms in 1 liter of hydrogen gas at standard temperature / pressure (ideal gas law)

A liter of water weighs approximately 1000 grams (1 kg)

A single water molecule weighs aprox 18 times as much as a single hydrogen atom

Therefore, 55.5 mols of water in a liter (kilogram)

7.806 * 10^26 atoms in 70 kilograms of water. The human body is mostly water.

Assuming we're mostly water, the human body has aprox 2^70 atoms

2^256 hydrogen atoms ... actually I'm just going to stop right now, converting to decimal and bypassing mass calculations:

log(2^256) / log(10) ... you're already much closer to the number of atoms in the visible universe.

... Not to worry though, since there is no point in attempting to exhaust the 256 keyspace:

Only 160 bits worth of hash used to generate bitcoin's 34 "digit" base 58 public key addresses, so you'll VERY likely have many many collisions well before you try a number of keypairs equal to the number of atoms on planet earth.

well done, was too lazy for this :D

@kuzetsa:
Yeah, I even considered renaming the application to 2^160 DSV at first (but stayed with 256 because even though the valid address space is indeed much smaller, the private key space is still 2^256 if I'm not mistaken - and also, the nerd in me kinda likes the number 256 better :) )

But thanks for your post, that's the kind of stuff I like to read!

Version 1.463c is out (see OP), with a fix for a display race condition and a nice ASCII background by hrr :)

... that's what I get for not proofreading sufficiently. NO CLUE where that 2^70 atoms came from. Gonna check my math because I'm suspicious now:

K = 1000 / 18 = 55.55555 (mols of water molecules in 1 kilogram of water)

^ trivial reasoning, so not showing work there.

C = 6.02214 * 10^23 = Atoms in 1 "mol" of anything.

M = K * C = total number of water molecules in a kilogram of water

H = M * 3 * 70 = atoms in a 70 kg human

^water has 3 atoms per molecule, assume 70 KG body mass
(simplified density calculation / calculating with water since humans are mostly water)

---

ok here we go:

H = M * 3 * 70

(K * C) * 3 * 70

18 * (6.02214 * 10^23) * 3 * 70

10839852000000000000000000 * 3 * 70

H = 2276368920000000000000000000

now to binary:

log(H) / log(2)

62.992379105356328965599428828285 / 0.69314718055994530941723212145818

H = 90.87879...

oops, I'm not sure where I got the earlier value of 2^70

... my bad, but either way, still less than 2^256 atoms in a human

This is why they try to it's common to ask students to show their work / prove everything with math.

---

Edited:

ACK!!! ok, this time I used the wrong value for K, here's fixed math:

H = M * 3 * 70

(K * C) * 3 * 70

55.555... * (6.02214 * 10^23) * 3 * 70

33456333333333333333333333.333333 * 3 * 70

H = 7025830000000000000000000000

now to binary:

log(H) / log(2)

64.119390868546136633237958001732 / 0.69314718055994530941723212145818

H = 2^92.5 (most people only know their weight to about 3 significant digits anyway)

These numbers are for preimages on 160-bit addresses. There's no point in trying to match the (almost) 256-bit private keys anyway.

PS: may I ask how many addresses/s your software can do?

The current version is intentionally VERY slow (only 64 addresses at a time, approximately) - just to show that it's not meant to be taken too seriously.  It could easily be made much faster though, as it actually uses lightning-fast Vanitygen address generation routines in the background.

Version 1.469 is out, with better support for different screen resolutions and the Hotlist feature bumped to 52 items. (See OP for download)

So where's the serious version?

ETA: More importantly, why isn't this on my phone, yet?

i have a multiscreen-environment (4 screens). only blacks out one of them.

where's the key file at?

So, does it do anything cool if you do find a match?

It stops, plays a sound, the text turns light blue, and you can double-click the match to see how much BTC is on the address (checks with blockchain.info). You can then import the public/private key.

He says with actual experience....

Eh, I'm Jewish on my father's side.

cool little program, just one question if we do find an address with bitcoins besides for it beeping will it keep it on the screen or something or how else are we supposed to know that we found some bitcoins?

The program pauses with the current list of 64 addresses generated. On the address where a match was found, the program will show "FUZZY MATCH!" (or similar - don't remember). Double-click the address where "FUZZY MATCH!" is displayed, and the program will retrieve the address's current Bitcoin balance from blockchain.info. It then appears where "<Contents>" would otherwise show. Pretty much always, it should update to show 0.00000000 where "<Contents>" was, indicating there are no unspent units on the address.

If the program finds a match, depending on your screen resolution, you may have to scroll down the list with mouse scroll-wheel to find the address with a match.

okay, but do i have to click each link to confirm there isnt a match? And it pauses automatically or i do it manually.Sorry for so many questions just i am probally gona leave it on when i sleep and hope i get lucky

the more you sleep the higher your chance on luck :)

Is it possibke that the programm always stops when it finds an adress beginning with dsv ??
Would also leave it on when i sleep but after 5-10 mins it stops hilighting an adress with 0 balance but dsv after the first 1.
Can i change this?
Thanks

can't it just run forever and put the non-zero-balance privkeys into an ascii file?

https://i.imgur.com/I7bwZ.png

Did I win?

The "dsv" pattern matching was used when testing/debugging the application, and I forgot to remove it in release build. I've just fixed this in the latest version (1.471).
The download links are in the top post.

Unfortunately I don't have very much time available for further improving this application right now, but I might revisit it in a few weeks.

flatfly, can you just tell me if i run the program for fun but also hopeing to win when it finds an address that has more then 0 btc will it notify me or save it or anything. like i will leave it over night and if i win i want to know i won. 

Also im assumming i dont have to click on every single balance to confirm i didnt win anything

u wont, this is just for fun. read the posts before.

The latest one keeps crashing on windows 7 for me/

Hi, if the address is in the Hotlist, the program will automatically stop and notify you. You can then copy the private keys using the alt-K shortcut. Otherwise the application automatically checks every single balance only if ABE is locally installed. But I wouldn't bother with that if I were you. Please read the previous posts to understand how low the odds actually are.

The current Hotlist (hardcoded in the application) contains 51 items - I will post the actual list if someone's interested. Also if anyone wants a build with a custom Hotlist, I can make that possible in exchange for a donation. (I've already spent much more time on this application than I originally planned to.)

That's strange, as the only change in the latest version is one item removed from the Hotlist.
Any error messages or screenshots you can post?

I will make a donation if you can change the app so it does the following

Instead of using abe(or with abe), also try to use bitcoin-qt blocks to check
Save all Privite Keys with balance to .txt file in selectable location
Make the program runable in the background like a bitcoin client

(2) and (3) are feasible but there's no way I could do (1) - it would simply take me way too much time to implement.

It had a runtime error the first two times, however since then I have been unable to replicate it. It was probably something on my end.
The first thing would be a bit insane to do, since it would require the whole blockchain, I think it would be better to just auto find the balance of each key genned, without clicking on it.

Saving the private keys is a good idea though.

I found one I found one!

It scrolled off the screen too fast though.

Do you need my <African accent>banking details??</African accent>

aw hells, yeah.

OK, a minor update (v1.472) is out, which automatically saves all private keys to a text file, as per popular demand...

Also, an 8-bit style ending sequence has been added! If you're curious, you can access a teaser by typing the below code while the application is running:
By the way, I'll throw in a quick little bounty as well, to spice it up a little: 0.256 BTC is yours if you can name the title and author of the ending sequence tune! Contest valid until next Wednesday midnight UTC... Good luck :)

Hahaha that's awesome

Thanks!

Just a little hint because it's not an easy one: The composer is one of the greatest legends of the 8-bit chiptune scene...

Also, another 0.256 BTC bounty will be awarded if you can come up with a nice retro-style logo for DSV. More details later...

Jeroen Tel? dont know the title though

Sorry, I will only accept / reply to full answers (author + title).
Just to be fair to everyone.

https://i.imgur.com/JsS8jdx.png
https://i.imgur.com/tSAlHmf.png
https://i.imgur.com/vzmoeq9.png

Icon- https://i.imgur.com/n4PfK3P.png

Nice!

Here are a few details on the little logo contest:

- the contest will last until February 21. 

- you can submit as many retro-style designs as you like.

- I will pick one winner, based on my personal preference - no precise rules. So don't spend too much time on this, this is mostly for fun (and a chance to get 0.256 btc!)

- I may end up actually using the logo or not.

Good luck!

Well, the tune ID contest is now over and unfortunately, no correct answer was provided.
A few users did find the author but no one got the title right.

The tune is an FT2 module by Jeroen Tel, called "1999", because it's exactly
1999 bytes long - yes, XM really is an amazingly efficient music format!

Youtube link: http://www.youtube.com/watch?v=AbXBOeWwAMg

So far, only Mushroomized has submitted a logo - which would make him the default winner if nobody else enters the contest before the deadline! :)

I rather win for having the prettiest :D

It would be better to save just addresses with a balance >0, even because when the txt file grows too much it crashes the program.
I would like even the option to run it in the background.

And the winner is..... Mushroomized!!

That was an easy one wasn't it? :)

Please post or PM your address so I can pay the 0.256BTC bounty.

1DWgwTzAQ7XNFbs4B2tMjf6JNFBXgzWSVh
yayyy....

lol

Thanks man

New update released (1.475), now using the lost_coins Hotlist by default.
Also, the application can be fully used offline now. Only if you need to query for live balances will it connect to the Internet.

If you download the entire blockchain it is possible to keep a copy of the balance of ALL addresses in a memcache deamon in ram. It allows you to check the balance of any address without using extra bandwidth.

I have seen setups like that to run through dictionaries looking for brain wallets.

It would take a long time to cache them all, I mean, you would need to calculate the balance of the address based on the previous transactions(if any). Then, you'd need to update it at least once per day, this cache list.

You just update the addresses as you parse the block chain, then you can parse the new blocks live as they come in. It takes about the same amount of time as a client catching up to the block chain, it just needs a lot of RAM.

How to add extra address in lost_coins list?  ???

and how to install "local bitcoind + ABE installation" for locally fetching data?

Sandboxie is crap. With default configuration it does not prevent the malware from accessing and reading files on hard drive and doing other things such as stealing wallet file. It only prevents from file creation or system modification. Run any untrusted code in virtual machine such as VMware.

The list is hard-coded in the current implementation. Adding support for custom hotlists is on my to-do list but
not a high priority at this time.

I am willing to make custom builds with a user-defined hotlist hard-coded available to donators.

The support for ABE is no longer working at this time and I don't have enough time/motivation to work on it right now :(

I'm closing this project due to other priorities. Thanks everyone. It was fun!   

Sorry to bump, but...

I GOT ONE!!!!

1DS..........
5J2...........

And the address has no money...

Should have gotten 1DsXxztYCB7EC1rqExZAMNrCYpQhpntx9z ;D

WRONG!!!!!
1DSv3.....

One can only wish............

How did you make this? Do you have and updated version?

Thks.

It's not a myth, it's just facts. 2^256 is a really really really large number.

http://3.bp.blogspot.com/-QEod3ckcQ4Y/TkpKttrJB5I/AAAAAAAAGzo/B8PYotwScpM/s400/What+the+fuck+am+I+reading.jpg


2^160

Assuming 500K addresses which either have funds or will have funds within next three months,
0.0000000000000000000000000000000000000000034211388289180104270598866779539% chance per check.

Assuming average computer can do 250 optimized DSV-like checks per second,
0.00000000000000000000000000000000000000085528470722950260676497166948848% chance per second.

Assuming a "theft pool" is formed, and 500 of these computers averaging the above click/s,
0.00000000000000000000000000000000000042764235361475130338248583474424% chance per second.

Assuming each theft pool is one botnet, and 20 botnets, exactly the same, exist in these theft pools,
0.0000000000000000000000000000000000085528470722950260676497166948848% chance per second.

Per minute,
0.00000000000000000000000000000000051317082433770156405898300169309%

Per hour,
0.000000000000000000000000000000030790249460262093843538980101585%

Per day,
0.00000000000000000000000000000073896598704629025224493552243804%

Per month (30D),
0.000000000000000000000000000022168979611388707567348065673141%

Per year,
0.00000000000000000000000000026972258527189594206940146568988%


Assume worst-case scenario, DSV-like software can check 5000 addresses (10M of which are funded or will be funded within 6 months) per second, and 100 botnets of 50,000 computers each...
Per day,
0.000000000000000000000000014779319740925805044898710448761%

Per month,
0.00000000000000000000000044337959222777415134696131346283%

Per year,
0.0000000000000000000000053944517054379188413880293137978%

Per century,
0.00000000000000000000053944517054379188413880293137978%


Are we done, now? :)


ETA: Worse-than-worst case scenario. NSA can check 1T addresses per second, 1T addresses are funded.
Per century,
0.0000000000000021577806821751675365552117255191%

Per billion centuries,
0.0000021577806821751675365552117255191%

inb4 YOU SEE IT'S A MYTH IT'S NOT 0%!!

Well, I suppose that's true. If you're feeling lucky, I'll bet you $20,000 (would be more, but I'm poor) that you won't roll a 1 on a 9,000,000,000,000,000,000-sided die. Technically, you have a 0.00000000000000000011111111111111111111111111111111% chance of winning... As far as significant numbers go, you would have 0% chance of winning.

So, yes, it's possible, but any rational person would be more than willing to bet a ton of money on those odds.

ETA: By bet, I mean I'll pay out $20k if I lose. If you lose, you don't have to pay anything out. This would be more in line with trusting an address not to be "stumbled upon" with DSV-like software.

2^160 for RIPEMD-160, but 2^256(-secpk256k1 max number thing) for the possible private keys that hashes to an address within the 1^160 address space.

He was talking about address collision
The odds of an address collision is 2^160

That isn't odds.

If you say 1:2^160 then that's odds, or some other calculation, but just saying 2^160 doesn't mean odds.

Hmm
The guy said "0% chance"
That means odds
So I assumed odds

To be exact:

Assume N(t) = the number of Bitcoin addresses that have a positive balance at time t.

The probablity of colliding with one of these N(t) addresses by random chance is:

    Probablity_collision(t) = N(t) / 2¹⁶⁰

The odds of colliding with one of these N(t) addresses by random chance is:

    Odds_collision(t) = N(t) : (2¹⁶⁰ - N(t))

Since N is a function of time the probablity and odds are also a function of time.

Since N(t) is much less than 2¹⁶⁰ these can both be approximated as the static constant values:

    Probablity_collision is about 1 / 2¹⁶⁰

    Odds_collision is about 1 : 2¹⁶⁰

[Lloyd in 'Dumb and Dumber']So you're telling me there's a chance...[/LiD&D]


 ::) Actually when somebody takes the time to do calculations of probability, that's pretty much the definition of 'taking account of luck'.


Sheesh. Fine. Reciprocal odds. Happy now?

I like the idea of eliminating the "0% chance of collision" myth, though.

0.00000000000000000000000000026972258527189594206940146568988% chance per year sounds better.

Though, if we changed it to one of "your" addresses being stumbled upon with needle-in-a-haystack-finders (that's the uhh... technical term), and we'll say you have 100 addresses... without opening calculator again, it'd be more like
0.0000000000000000000000000000000000000000000026972258527189594206940146568988% chance per year.

It'd be a cool April 1st press release from the Bitcoin Foundation posting up some big red "ALERT!!!" blurb on how your Bitcoins aren't safe as there's a .000...% chance of it being stumbled upon.

And then the price of BTC drops to $5 each.

Yeah, right. People aren't that stupid. The way you make it sound, we probably spend tens of billions on bottled water more expensive per gallon than gasoline.

If you're going to probe then you might as well probe 1933phfhK3ZgFQNLGSDXvqCn32k2buXY8a since it has such at a high value.

You're probably right. Although an address collision is in fact impossible by any sensible standard, this statement is also "a traditional story" or bitcoin "ideology in narrative form".

q.e.d. ■

As a special end-of-summer treat, the DSV download link is up again :)

Nice!

Do you need hosting or something? What was holding it back before?

So how long do i need to run this until i get hold of satoshis stash?

Where will it save keys it finds?

It saves all keys in a plaintext file called "dsv_bkp.txt", in the same folder as the executable.

What is the probability (per check) of finding a valid, activated credit card number and selecting the correct CVV, cardholder's name, and expiration date, assuming the expiration date is not beyond five years into the future?

Maybe just for a US Capital One MasterCard credit card, to keep things simple. Uses MOD 10 algorithm. http://en.wikipedia.org/wiki/Mod_10 The first six digits of these cards are 517805. Digits 7-15 are unknown - the account ID #. Digit 16 is the MOD 10 checksum number.

This means there is a total pool of 99,999,999 accounts. Assume 10,000,000 are activated.

Expiration date is simple. Most (all?) aren't valid for more than 5 years. That gives a 1/60 chance of getting only the expiration date correct per check.

Cardholder's name is more of a clusterfuck. Let's assume only looking at "black" and "white" names (we're looking for a US account, remember) gives you 85% of all total active accounts. Let's assume common names make up 60% of all total active accounts, and that there are 50,000 common name combinations.

CVV is easy, and we'll assume we don't know how Capital One comes up with these numbers, so it's a simple 1/999 chance.

So. We need to successfully correct all of them in one go, and we have one ~1/10 chance (account #), one 1/60 chance (exp. date), one ~1/83333 chance (cardholder name), one 1/999 chance (CVV).

I think the per-check probability of all this comes to .000000000020020100300621424707921073926538% (low confidence, someone smart should check this because I originally posted this post as a question but ended up giving enough data where I thought I could solve it).

Keep in mind, per-check chance of finding funded bitcoin address is ~0.0000000000000000000000000000000000000000034211388289180104270598866779539%.

To make the numbers a little easier to grasp, here is %chance of finding bitcoin address if "DSV-like software can check 5000 addresses (10M of which are funded or will be funded within 6 months) per second, and 100 botnets of 50,000 computers each":
Per century,
0.00000000000000000000053944517054379188413880293137978%
If 100 botnets of 50,000 computers could check only 1,000 addresses per second (5x slower than above stats for bitcoin), the chance of correctly guessing info on an activated credit card is:
Per century,
10.01005015031071235396%

ETA: I left out PIN number. Point still stands.

Although I still have tons of ideas to make Deep Space Vagabond more fun, I just don't feel motivated enough for implementing them and maintaining this project anymore. However, I don't want to see it die, so if anyone would like to take it over, let me know. Note that I will consider the online reputation of any interested parties as I wouldn't like this project to fall in the wrong hands.

Sad to here that :(
What is the used language? I may be interested in applying

Glad to see that you're interested!

It's mostly written in AHK (are you familiar with it?), as I wanted to experiment a little bit more with that language, and it allowed for real quick GUI prototyping...  Also, as stated in the original post, the actual address generation is delegated to vanitygen (with samr7's permission).

Could you elaborate on what you would plan to do with it?

AHK? It's been a while I didn't use it
I'd like to: include the address generation inside the code, allow using an own private key or even a file as a starting point, allow chosing the algo privatekey(n) -> privatekey(n+1) (I didn't read all the pages yet, I hope this isn't already done)
Maybe making it python btw, from what I saw it could be possible

No, it currently doesn't have those features implemented.
And yes, I think Python would be a good option as well - actually the very first prototype of Deep Space Vagabond was a quick Python hack done in late 2011. :)

I say start from scratch

I'm very proficient in AHK; I'd be willing to help.

Thanks, I'll wait for a couple more days in case other potential candidates show up. 

I've received 2 additional offers by PM. So, 4 users are currently interested in taking over this project.

As I'm still not sure who to transfer this project to, I will simply transfer it to the highest bidder. Starting bid is 0.3 BTC, minimum increment is 0.05 BTC. I would like to close this a week from now at the latest. If there are no bids at all, I will just transfer it to the candidate with highest activity.

[Edit] I reserve the right to turn down offers from proven scammers.

You couldn't just open-source it?

I don't feel too comfortable doing that. A little concerned about the potential for abuse, even if limited. That's why I'd rather transfer it to a trusted user.

Abuse?

If Bitcoin can't stand up to this program I'd really rather you let her loose now, before I waste further time  :D

Not that kind of abuse... Rather something along the lines of repackaging the app and potentially abusing new gullible users.

They'd do better repackaging Bitcoin-Qt than a screensaver.

That'd be a little trickier to get away with since there's no reason not to download from the official site. You have a modified version of a "address cracker," though, and you could probably get a good number of people. God willing, they're all poor people. Or.... wait, that's worse, isn't it? :D

The Downloadlink doesnt work anymore.
Could you please reupp the latest Version of you tool ?

I would very appreciate it :)

Thank you

Best regards

Google Code started disabling binary downloads recently...

There are a few other possibilities to upload the file  :)
It would be nice.

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.)

I've noticed the same thing - I wanted to use regex with oclvanitygen and thought I could just run a regex script batchwise on the generated files, but as you noticed it's very slow. I can't help you with that, but:


I'm pretty sure this has to do with the probability of those addresses existing rather than the probability of them having a balance != 0. This means that trying them does not increase the time taken to find a balance > 0 since the probabilityof generating these addresses is much lower as well.

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).

http://i60.tinypic.com/juu2qa.jpg

I know what you mean, but if you compare that to a list of the frequency distribution of *all* addresses, I'm betting that the distributions will be very similar - which means you don't gain anything by leaving them out.

And in fact, you're probably slightly slowing the generation process down.

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 (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.

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'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.

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

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

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.

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.

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.

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

33.5 million BTC address have ever had any amount of Bitcoin in them.

2.55e+46/33.5 million = 7.5e+38

That makes it a huge total of 7.5e+38 years to find an address on average that has had any part of a bitcoin in it , ever.

To put this in perspective , if you took 21 million Bitcoins and started sending 1 satoshi per address to random addresses , you would be able to cover only 2.1e+15 addresses , not even being near to the chance of reaching an address.

anywhere to download?

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

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.

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?

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

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.

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?

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!

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.

I like this game! :D

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 (http://www.dataonstorage.com/dataon-products/dns-jbod/dns-1660-4u-60-bay-6g-35inch-sassata-jbod.html)? 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.

The process of Bitcoin address generation is as follows:

1) Generate a cryptographically secure random 256 bit number, if it is too large go to step 1.

     This is the private key "p"

2) Calculate the public key, which is a point on the elliptic curve P = p*G

3) a = hash(hash(hash(P)))

4) add checksum, header byte, etc to the number a

5) Base 58 encode the result in step 4

The point is that statistical analysis of the public key value distribution tells you nothing about the statistical distribution of the random private key values.

Any statistical analysis of the Bitcoin address, especially the encoded Bitcoin address values, tells you even less about the statistical distribution of the random numbers used in the generation of the private keys.

The fitness of the cryptographically secure random number generator can not be tested or inferred from the resulting public key values or the Bitcoin addresses produced.

Food for thought.

More food for thought:

If you analyse all private keys in base 58 encoded format you would find that all private keys start with 5H, 5J or 5K and none of the other possible two character starting sequences (51 ... 59, 5A ... 5G, 5L ... 5Z, 5a ... 5z) ever occur. 

Does that mean that all random number generators are broken?

No, this is simply an artifact of the base 58 encoding process.

Ok, we can keep it going here for now so long as the OP does not get upset over it.

The process in grabbing bitcoin from "collisions" successfully is a little more complicated than even you guys are pointing out now. But you are all on the right track. 95% of the equation is faults in the PSRNG's that almost all wallets or services use. So although that makes it a wallet problem. The wallet problem makes it a Bitcoin security problem as we all know that a computer can never truly generate random numbers.

We will explain how we have had success in a much greater depth in the weeks to come which will make it make a lot more sense. But still the magic is in having others, hopefully some of you with a few TB to spare do it yourselves. Once you do it successfully then the speculation and "i am a genius with big numbers" rhetoric can stop and we can all continue to bash away at the faults in the system forcing change and security. Sadly probably killing the price of BTC for a few months in the process.

It may sound malicious, and in the short term it is, but in the long run, its better to have it happen now while bitcoin is young so it can be fixed then years down the road when an issue like this could kill bitcoin forever. That is the reason we are going to open source the entire project. A few of us could do everything including steal YOUR bitcoin if that chance came up. But no matter what there would be tons of opposition saying that it was staged, faked, or whatever no matter how much you claimed you got ripped off. Let everyone have a chance at doing it themselves, Make a game out of it, track statistics through a web interface, etc. let the world have some fun with it, sooner or later people are going to realize that it is really happening, and change will be forced.

The reason it is taking time to get the platform released publicly is because we ourselves used a very complex Oracle DB which cost a small fortune. Not everyone can afford Oracle licenses, and to be honest, most already existing DB platforms either under perform for this purpose, or over complicate things so the basic user could not work it. So we are developing a way to replicate our platform WITHOUT using and existing DB technology so even the most basic of user can use and understand everything.

Please feel free to continue to speculate, post the fancy statistics and exponents on how impossible this all is as if the math is the only thing that matters. (that is not sarcasm, having all of that on the table when we get the time to show how it is done when we launch will make things easier to understand) and we will do our best to get this all launched as soon as we can.

I the mean time, any developers who want to jump on board to help speed up development for the user friendly platform, please message us, there are about a dozen of us [developers] working on this now, along with a few dozen mathematicians, statisticians, and even a half dozen cryptographers with over 45 years combined education. We are not hostile, in fact we are quite the friendly bunch. Although the process is malicious, the end result could save our precious bitcoin from total failure. It can happen, ask any one of the core developers, there are a lot of faults in BTC that could cause it to die if exploited, they wont list them for you, but the will confirm they exist and it is very possible. We just happened to find one.

Thanks for reading  8)

Wouldn't one of those hardware random number generators solve this?  Could something like http://www.entropykey.co.uk/ be incorporated into a wallet system.

One day, maybe in a few months or a few years, we might slowly migrate over to 512 bits. Suddenly, you're just wasting disk space.

And don't forget about compressed keys.

It is true that faulty random number generation can lead, and in the past has led, to bad things happening including loss of BTC.

If it is true that there is a widely distributed faulty random number generator being used to generate private keys and digital signatures then that needs to be found and fixed as soon as possible.

This all leads to a very interesting side issue:  how can you ever prove you have taken someone else's BTC using this or any other method?  Ideally you would have someone very reputable come forward and say "someone took my BTC in this transaction" and post the transaction.  This could be followed by the party that took them coming forward and signing a message with the private key of the destination address of the transaction in question.

The reputation of the person that lost the BTC in the transaction would have to be beyond reproach as there are many ways to fake this whole "Proof of Theft" scenario.

I believe that your idea of having someone of high reputation run your program, with it they create a verifiable address collision, and then they report the address collision would also work as proof that you are on to something.

You might be interested in the 50 BTC reward offered in the following post.  The offer has expired but you might be able to talk Greg into extending the deadline just for you.

That is not the same thing.  That is reversing a specific key.  This is about the birthday problem where there is a collision and you can't choose the specific address in advance or the statistics are vastly different. 

Very true.  That is why I said "might be" interested.  I expect the 200,000 addresses Greg generated were generated with a very good random number source so those 200,000 addresses would not fall into the net (possible bad private key generation) being cast by the Hyenas.

Yes, to a point. The biggest part of the fault is that the PSRNG's after a period of generation across a large scale tend to cluster outputs, meaning a large part of addresses fall in a small part of the key space. As a temporary solution for added security if you yourself are trying to store any amount of bitcoin long term, we can recommend one of a few methods for now.

1: use vanitygen to generate an address which falls far out of reach of the clustered address space, for example, the odds of your address eventually becoming part of someones catalog if it starts with 11121******************* is 667% more likely to happen then if your address starts with 1iBPq******************* for example.

If you extract a total list of all bitcoin addresses ever used. Then turn them into a line graph based on the first 6 characters of the address then sort them alphabetically and numerically you will see better what we are talking about. A scary large amount of addresses fall within a very small percentage of the total available address space. That in and of itself is roughly 60% of why we have been able to be successful with our project.

2: Use real world high entropy sources, a deck of cards, Hexadecimal dice, numbers and letters pulled from a hat. Myself personally and a few of the guys already on the team for this project we throw darts at a very large dart board that we made that has 0-9, a-f listed about 400 times each in a random pattern on a 4' X 4'  custom dart board we made. The entropy is higher if you are drunk when throwing the darts as your hand eye coordination makes it like trying to hit a moving target  ;)

3: store your bitcoin in multiple addresses to ensure that the prize isn't sitting in one location, myself i have about 40 addresses with positive balances at any given time. Not a single one has more than BTC5 in it, and not a single one has ever been online. I use paperwallets created from a 5 year old laptop with no hard drive or NIC card in it. I use the darts to generate keys, then use an ubuntu live cd to make the paper wallets on my own custom template which folds and then fits inside of a 4 screw acrylic baseball card holder. I then keep the acrylic cases spread between a few separate safety deposit boxes at a few banks. Most of them are left in my will to my wife and daughter.

There are several safer ways to store bitcoin and keep it safe. The security problem is not in finding safe ways to store bitcoin, the problem is in using bitcoin for commerce as those wallet clients and even the bitcoin core itself continue to dump addresses into the clustered regions of the address space. When it becomes a serious problem, retailers will lose faith in it as a payment method and adoption of acceptance will begin to fall.

 
Any disk space spent in the processes of trying to force the hand of the bitcoin core devs to fix a problem is not wasted. Your very narrow minded comment shows you have very little understanding of core address concepts and where security faults lay. 512 bits would just require re-building new data tables and populating them with new data based on the faults in PSRNG's. yes it would now require double the disk space to store them until better compression methods are developed, but it still does not fix the problem.

Your feeble attempt at trolling with such replies only discredits your comments and speaks poorly on your intelligence or ability to understand where the problem lays


This in itself is not an achievable target. If he used true entropy not from software or a computer, these 200k addresses fall across the entire keyspace, the problem is that to date mainly due to commerce and the bitcoin core, a VERY LARGE amount of addresses fall in a very small portion of the space.

The project is not aimed at trying to target a specific address, or even 200k specific addresses, the project is aimed at cataloging those small portions of address space which are heavily over populated with positive balances based on the core PSRNG's faults thus seriously increasing the odds of gettins someones bitcoins. The address is not what is important, the address space is. If that makes any sense.

We greatly feel the same way. hence the reason we are taking to time to re-develop the entire platform to make it basic user friendly on our own dime and then giving it away to the world. We could talk about doing it all day long, but as you said, the proof is in the pudding. Some of the higher reputation members would need to build large catalogs themselves and then find a collision. We are not doing this to troll, not for the thrills of stealing bitcoin, surely not to make a profit as the hard drives and hardware we have had to buy ourselves exceeded a cost that we could ever hope to recover through BTC theft. This is simply to allow easy access to the right people that need to do this in order to "prove" it. We have done it, we can prove it, but not to a level which will satisfy the community, so we are going to allow everyone to take a shot at it in hopes that the right person gets it done.

Hey, I wasn't trolling. I thought you were. I was just answering. I did not realize it at first but you are talking about a possible fault in the PSRNG. I personally use vanitygen because it seemed like a good idea for cold wallets.

The only time I let bitcoin core generate addresses for me was when I was sending bets to satoshidice.... a long time ago.



Since I use vanitygen, then I guess my coins are safe. There's another program out there called paperwallet or paperwal that, to me, seems to use the entire address space. Those generated addresses would probably be secure.

And of course, when I am really bored, I roll 100 dice. (or take random pictures and generate a key out of that.)

Basically, use any other RNG but not the one in bitcoin core. The android client had a big problem some time ago, related to the RNG.

Our apologies for accusing you of trolling,

"any other" RNG does not really solve the problem as we have found through heavy testing that Armory, Electrum, MultiBit, and just about every other wallet client out there has the same problems. The problem really is ANY RNG that is based on software.

Paperwallet is a better source as it uses coordinates of a mouse on the screen so it has i direct input which affects the output. Something like that built into a wallet client would not be feasible as no person is going to sit behind a PC at bitpay and wiggle a mouse every time someone needs a payment address generated.

The bottom line is, computers cannot generate randomness on their own, for it to be truly random it needs human input. The solution will be in the scope of something that requires a 3rd authentication process to spend bitcoins from an address. We ourselves have had many discussions on what a solution would be, but we do not have the answer yet. only ideas. 

here is the Armory discussion:
https://bitcointalk.org/index.php?topic=673035.0;all

Don't modern RNGs regularly get input from mouse, keyboard, hard drive, and other sources? And some of the newer Intel chips have hardware RNGs.

And if you're using bitcoin core on a computer, surely it can be improved by constantly getting randomness from mouse or keyboard input.

I saw this in the armory thread:
http://ubld.it/products/truerng-hardware-random-number-generator/

This is actually something I might consider for my new gaming site. (Provably Fair, of course.)

Any news from Hash Hyena?

Hi Burt,

a lot of progress, and a small amount of BTC claimed already, but nothing we would brand as "news" yet. Poke around the web a bit over the past week and a half and you will start to see a pattern or trend of people asking "did anybody else have their bitcoin stolen"? or things of that nature,  but we have not hit a target big enough, or enough small targets to brand it or make it news worthy as any publication of anything at the moment will result in nothing but a bunch of trolling from the mindless masses of sheeple in the crypto currency space. As time progresses more and more clear patterns emerge where the real source of the missing bitcoins come into question things will become more clear. For now, if you are one of those unlucky few who have become victims. Please maintain the address your BTC was hijacked from as we will be returning it to its rightful owners once enough have been collected to make an impact, all you will need to do is show you can send a transaction from the hijacked address showing you were the original holder of the private keys for that address.

In the interim, anybody wanting copies of some of the tools we are using, and help getting set up so you too can participate, please contact us and we can get you some of the pre-release versions with limited functionality (still enough to start grinding away at claiming BTC). we are aware that there will be people with malicious intents using this software and we can do nothing about that, but we ask that you refrain from doing so and that any BTC you can claim and move is returned to its rightful owners upon proving they were in possession of the keys for that address in the first place

Things you will need beyond our tools.

Either a dedicated Linux machine, or a VM with at least 2gigs of ram.
JRE and JDK
a host machine with fair amount of hard drive space and recommended 4 gigs of ram.

We will gladly walk you through getting everything set up until requests exceed our time limits, please keep in mind we are still working hard at finishing all the tools so everyone can participate so we are limiting our time in "setup assistance"

Alright, I'll bite thanks to my incessant curiosity. PM sent, and I'll put together a review if permitted.

Multisig addressses solves the risks associated with an address controlled by a single private key.

This is an interesting project, but I have some questions as a spectator of it. Do they do it as a hobby in their free time? If not then who is paying the team? Are they on a payroll? What is your budget that you are dedicating to this whole operations? Because you can't do it with 3.3 BTC.

We are a little confused  as to your questions. Are you asking do we get paid to play around with brute forcing and birthday attacking the bitcoin address key space? Or is someone paying us to exploit the PSRNG faults in most wallet clients?

As for budget, we dont have nor need one. The whole project is nothing more than a now large and ever growing collection of people from various aspects that relate to the project in some fashion either writing code, improving methods, researching and calculating various stuff or just dedicating a little computing resources to the project. The core team funds our own hardware ( hard drives, electricity, servers, and massive raw computing power) It is all play money, dedicated to being wasted on having fun with exploiting anything bitcoin we can. Any exploits, faults, issues we find with any wallet client, web service, etc. usually results in a report being sent to the service provider notifying them of the issue. One of the biggest wallet clients in use today had one of the biggest problems that was easy to exploit. within 2 weeks of reporting it with a demonstration to show exactly what was happening they had released the next version which fixed the problems.

^ they wished not to be named to avoid false panic as everyone that downloads the latest release will no longer have the issue.

Hash Hyena, I have a couple of questions / points which I hope you can address. The first is related to your interim key generation recommendations.


Given that vanitygen is just another CSPRNG, and therefore flawed by your reasoning, why would you recommend it over any of the others you mention above (all of which use, exclusively or at least in part, the same OS-provided source of entropy)? In fact, vanitygen intentionally decreases entropy when it throws out generated keys which do not match the predetermined pattern, which would (slightly) decrease the security of the generated keys.


First of all... how did you generate the random pattern of digits on your dartboard to begin with?

Regardless, any single set of random data is of course itself randomly biased, including your dartboard, and re-using it naively like this (I assume you don't create a new dartboard for each throw) combined with human bias will introduce that bias into its output. For example, it's very likely that there exists a hex digit on your dartboard which occurs less frequently on the periphery than it does towards the middle. Since I presume you'd avoid aiming your darts such that they might miss the dartboard, this hex digit is more likely to occur in your generated output.

In fact, a much better approach which would lead to less biased random numbers (assuming that the individual target boxes are small enough) would be to use a regular repeating pattern for the dartboard, where each 4x4 section contains exactly all 16 hex digits. How is it that nobody on your team caught this?

(This is to say nothing of the fact that throwing 64 darts at a dart board is silly-inefficient compared to just shuffling (well) a deck of cards...)


Next, moving back to your assessment of alternative clients:


First it should be noted that all of the clients you mention above (including BitAddress.org, which is I assume the paper wallet to which you refer) begin with the same source of OS-provided entropy (/dev/random on Linux/BSD or CryptGenRandom on Windows). Even though these two sources of entropy are in part provided by deterministic processes, they also use external human-influenced sources to maintain their internal state, e.g. the starting of programs, the initiating of or receiving of network traffic, the timings of writing to or reading from disks, etc. It is inaccurate to claim that the wallet clients you mentioned do not use significant amounts of human-source entropy.

Next, let's move on more specifically to your assertion that "through heavy testing that Armory ... has the same problems." Given that Armory gathers entropy from some of the same sources [github.com] (http://[url=https://github.com/etotheipi/BitcoinArmory/blob/v0.91.2-rc1/ArmoryQt.py#L806) as "paperwallet" (in fact it gathers entropy from many more human-influenced sources than "paperwallet"), can you explain why Armory has a flawed CSPRNG, whereas "paperwallet" does not?


Given that you've said
I find it extremely discouraging that you can make such basic errors as those outlined above. The net effect is to make me exceedingly skeptical of not only your overly-broad claims (which cannot be proven nor refuted due to their vague nature), but also of your abilities as mathematicians and cryptographers and even your intentions. Posting your team's professional qualifications (names, degrees, and peer-reviewed publications) would go a long way toward alleviating some of these concerns, even if you choose not to be more specific regarding these alleged vulnerabilities still under investigation.

I also hope that you can specifically address the questions above.

TL/DR

If you can clean it up into a short list of direct questions i can reply, but i am not reading through that entire mess to find the questions.

Thank you.

Cryptography is a complex subject, and cannot always be discussed in 5-word sentences (I even bolded the parts that actually needed addressing). I will try, but you may not like the results.

1. You claim nearly all CSPRNG is flawed. Then, as a workaround, you recommend vanitygen, which uses a.... CSPRNG (a fairly common one, OpenSSL). Can you explain the difference?

2. Your dartboard scheme for creating entropy is slow and biased, the sort of thing no cryptographer would ever come up with. Why did you?

3. You claim that "paperwallets" are superior because they use entropy from a mouse. You cite a bunch of wallet clients you claim to have found "through heavy testing" to be faulty, and yet every one that you cited also uses real-world entropy, just like "paperwallets". Armory, in particular, uses mouse input plus several other sources of real-world entropy. How could a cryptography expert miss this fact?

4. You've made extraordinary claims. If you are unwilling or unable to provide extraordinary proof (which is understandable for a work-in-progress), you will likely be ridiculed unless you can at least provide extraordinary professional credentials for your "few dozen mathematicians, statisticians, and even a half dozen cryptographers with over 45 years combined education." Why have you done neither?

Is that better?

5.  You had said using hardware RNG's would only solve part of the problem.  Why?

Thank you chris, that is much better

1: With vanitygen you add your own entropy by selecting an address with a 1XXXXXXX prefix, there is nothing random about it short of what comes after 1XXXXXX by selecting XXXXXXX you move yourself out of the over used "random" space

2: I wont argue this, instead i issue a challange, 1, Get drunk, i mean tipsy drunk. 2, attach 5 note cards (3X5) to the wall. 3, stand back 20-25 feet from them. 4, try and hit one, then try and hit the same one again. :)    (in short, its fun, and more random than you will get from most other sources)

3: I really dont want to get too much into this one, If your making this claim, i assume you have looked through the entire source code for armory before (prior to their latest 2 releases) so there really is no need for discussion here.

4: Right, and wrong at the same time. We are not making claims nor trying to convince anyone of anything, that would be futile around here to say the least, this is a community filled with sheeple, trolls, and the under educated with a few bright minds mixed in to try and balance it out. We knew this coming in. Instead, we are releasing some of the software we have developed to allow others to do it themselves. As more participate, the "thefts" (hopefully will be returned to their rightful owners upon proving a point) will begin to happen more often, and sooner or later someone will hit something BIG or nail someone of importance and when they speak up, then there will be nothing left to discuss.

 

This is worthless, you never give reasonable answers.

^^ AWWWWW you hurt our feelings  :-*

Stop beating around the Bush, disclose your findings

You're kidding right?

We already did. But let me summarize it for you.

There are a lot of wallet clients in existence that use faulty PSRNG's. The easiest way to find and "prove" this is to parse the blockchain for a list of all addresses ever used. Then group them by the first X characters, (we use X=6 as that is still quite easy to generate using most brute force tools including vanitygen)

Then turn your list into a bar graph, you will find that LARGE amounts of addresses fall in a very small portion of address space.

Because of this, you are cutting out a HUGE portion of the space if you are trying to brute force an address for 1. but most importantly you are opening yourself up to a "birthday attack" of sorts as it is not difficult by any means to compile massive lists of address/private key when your target is only address that start with 1xxxx,1xxxxx,1xxxxx, etc.......

On second thought, we already covered this, i dont feel i need to write it all out again.

The processes is simple, check the address before you database it for a positive balance, then monitor the database in real time for any incoming transactions. (there is a reason satoshi dice is keeping all of its coins in vanity addresses)

Care to comment on the following hardware RNGs?

http://www.entropykey.co.uk/
https://www.tindie.com/products/ubldit/truerng-hardware-random-number-generator/
http://ubld.it/products/truerng-hardware-random-number-generator/

I might buy the last one.

DABS,

THANK YOU. Seriously !!!!!!!!!!!!!!!

Yes, i can comment.

The avalanche effect in a semiconductor junction is probably one of the better known sources of Entropy in terms of hardware. I myself and a few of the team own TrueRNG's.

Not all HWRNG's are created equally, and some are more faulty that PSRNG's when you look at the bitmap analysis. (part of the reason why the bad ones dont show it openly)

In my opinion of course, i would say the TrueRNG is worth the money if you intend on storing any real money in something protected by cryptography.

Some of the better HWRNG's that are more secure use ambient noise at the time of reading to generate entropy as well. Go sit in a crowded coffee shop and generate your keys with it and you are for sure secure. I use to have one myself (super expensive) until i spilled coffee on it.

Good info. Now you alluded to armory having something in its source code that was recently fixed. What was it?

If you want to tip me, you can send me one them cute USB devices. :)

Read the release notes, They dont hide what they do, and when they have errors. Believe that when the armory team finds a problem with their client that involves security, it gets patched IMMEDIATELY before anything else is done. Armory may not have always been the safest, but they are the best from a business standpoint at taking care of their problems, and they are very quickly becoming the most secure wallet client a person can have, although they are not quite there yet.

I'm waiting for them to include support for compressed keys.

I dont know if they ever will, they already support Hex, Base58, and mini keys. Compressed keys are not used too often and i dont believe they are main stream enough.

BTW, i dont know if you have ever heard of Turbid, but since you are looking for solid Entropy, their project is pretty good and open source. you could make one for a decent price.

Here is the paper, you can find more on google by searching Turbid RNG

http://www.av8n.com/turbid/paper/turbid.htm

Its an open source style of the more expensive RNG's that use audio that i mentioned earlier.

Also, we released the first part of many pieces of software to the public tonight for balance fishing on a local machine. ( https://bitcointalk.org/index.php?topic=826097.0 ) for those who are here with legit reasons other than to troll or prove how narrow minded you are. Feel free to grab a copy and try your hand at it. We will be releasing the blockchain parsing application soon that first exports all addresses with positive balances, then groups them so you know which ones to fish for when your generating addresses. We anticipate it will be about 3 weeks before we get that launched fully as we want to test it heavily in house before anyone else tries it on their PC.

They should include compressed keys. Because every Bitcoin Core client uses it since version 0.6.

Download link don't work.