2^256 Deep Space Vagabond

[flatfly]

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.

[1713504548]

1713504548

[1713504548]

1713504548

[flatfly]

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

[flatfly]

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)

[flatfly]

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)

[flatfly]

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.

[BkkCoins]

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.

[🏰 TradeFortress 🏰]

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

[flatfly]

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.

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.

[K1773R]

did anyone find an adress yet? ^^

[flatfly]

did anyone find an adress yet? ^^

Not yet... better ask again in 10000 years

[flatfly]

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

Download - VT Scan - 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.

[K1773R]

did anyone find an adress yet? ^^

Not yet... better ask again in 10000 years

sure, gimme the technology to survive 10k years

[Mushroomized]

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

[2GOOD]

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  

[Pieter Wuille]

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

[Luke-Jr]

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.

[flatfly]

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 - VT Scan - SHA1: 3ce34a480fd1f52da3056be0115ee9df8ca40c68

[flatfly]

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

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.  

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

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

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  

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

[Pieter Wuille]

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

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?

[Mushroomized]

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