Topic: 2^256 Deep Space Vagabond - page 9. (Read 38663 times)
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
... 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 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.
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
... 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 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.
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
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.
- ......
- 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
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).
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.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
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.
Interesting patch. Will it be in the next release?
Also, even seeing those numbers doesn't make you want to contribute in a somewhat more useful way?
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
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
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?
So the screensaver version... what does the G mean?
How do I tell how much is in each wallet? Im guessing // means none?
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).
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
Thank You
I'm glad you got the idea behind the DSV "pet project" perfectly! And thanks a bunch for your nice words.
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.
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).
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).
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
Thank You
So the screensaver version... what does the G mean?
How do I tell how much is in each wallet? Im guessing // means none?
How do I tell how much is in each wallet? Im guessing // means none?
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 - 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.
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.
did anyone find an adress yet? ^^
Not yet... better ask again in 10000 years
did anyone find an adress yet? ^^
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'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.
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... 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.
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'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.
Jump to: