Search content
Sort by
Showing 6 of 6 results by BlueExodus
No, i was asking if theres any kind of way to derive or get a decimal representation of btc address that coresponds to its private key hex
It gets even weirder. Why would you want to compare the decimal representation of an address with the hexadecimal representation of the private key that generated that address? Obviously you cannot do this for the same reason, the hash is not reversible.
Which one would you like to have? Not only in theory but practically you can find at least 1 match for any address after 2**80 operations which consist of private key to public key to SHA-256 to RIPEMD-160, Once you do that you can find the match.
@BlueExodus, is that what you are asking? To find duplicate private keys with the same address? You have not clarified it enough.
Nope imagine like i derive btc address from a number, cause every 256bit number has its private key hex, btc address compressed and uncompressed with their wif private keys and public keys... Like that i derive the 256bit number from that btc address, private key hex is easily not to say derived but convertable to 256bit number since decimal representation is number associated with private key hex in numerical form.
So is there any way to derive or calculate the number representation from btc address that coresponds to its private key hex?
No there is none.Bitcoin addresses like P2PKH represent a hash and hashes are irreversible which means you can not compute the public key used to get that hash.
Even if you had the public key you still wouldn't be able to compute the private key because that is another irreversible function.
What you've seen in the program you found on the internet that uses the term "key range" is a very specific code written to solve a puzzle where the creator of the puzzle intentionally created small keys in a much much smaller range than what should be used so that it can be brute forced by enthusiast who like to waste their computing power.
Yes thats true, i was just asking even if im aware aside that it may not be possible but just wanted to check again cause internet is full of untold secrets where they often promote a boxes and they tell you its a box but they never mention its interior, i think you understand what i mean
And the program that calculates all info is not from the internet, i created it few months ago
So is there any way to derive or calculate the number representation from btc address that coresponds to its private key hex?
Please clarify whether I am understanding your question correctly. Do you want to know if the following equation has a solution?
Code:
hash_function(x) = x
It could have, as no theory that I am aware of can demonstrate that it has no solution. It goes without saying that until you break the hash function, you cannot find the answer.
No, i was asking if theres any kind of way to derive or get a decimal representation of btc address that coresponds to its private key hex, without having to derive private key hex from btc address first, since decimal and private key hex have nearest relationship dec to hex/hex to dec, so only publicly available components are ripemd160 or btc address to get busy with.. .
Its known that private key wif are derived from private key hex and private key hex is derived from 256bit random number which is from 1 to 115792089237316195423570985008687907852837564279074904382605163141518161494336, in ECDSA it all starts from these natural numbers which is the root of all.
Hello guys, i recently made a program few months ago that finds all info from numbers.
Example for number 7...
Enter an integer: 7
Private Key (Hexadecimal): 0000000000000000000000000000000000000000000000000000000000000007
Key Range: 3
WIF Private Key (Compressed): KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU76rnZwVdz
Public Key (Compressed): 025cbdf0646e5db4eaa398f365f2ea7a0e3d419b7e0330e39ce92bddedcac4f9bc
Bitcoin Address (Compressed): 19ZewH8Kk1PDbSNdJ97FP4EiCjTRaZMZQA
Balance (Compressed): 0.00000000 BTC
WIF Private Key (Uncompressed): 5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreBR6zCMU
Public Key (Uncompressed): 045cbdf0646e5db4eaa398f365f2ea7a0e3d419b7e0330e39ce92bddedcac4f9bc6aebca40ba255 960a3178d6d861a54dba813d0b813fde7b5a5082628087264da
Bitcoin Address (Uncompressed): 1BYbgHpSKQCtMrQfwN6b6n5S718EJkEJ41
Balance (Uncompressed): 0.00000000 BTC
These are my early work...
For example address to base10: 14jsRJx8HnKq9jyqfBQKgvvnFy3rNCbc3G
If you run this through decode_base58, you get the following string ( hex representation ):
002903ef7df972ef94adeda53f0ccd24699de872041e4732cf
The first byte ( 00 ) is a bitcoin address version string. On production blockchain, this is 0x00 and on testnet blockchain, this is 0x6f ( or 111 in decimal representation ). We notice that this is a production address.
The last 4 bytes ( 1e4732cf ) is a checksum over the previous data. If you make a typo while manually entering a bitcoin address, you will create an invalid checksum and the bitcoin client will refuse to send money to it. So, we want to convert this hexadecimal representation into decimal representation. Turns out to be very easy in perl:
Code:
use bigint;
print hex '002903ef7df972ef94adeda53f0ccd24699de872041e4732cf';
The result is:
1005694022349920422888116886380815406116626226984035758799
And when i copy the result in decimal 1005694022349920422888116886380815406116626226984035758799 i get the same hex value just with leading zeros that match 64 hex private key 00000000000000002903ef7df972ef94adeda53f0ccd24699de872041e4732cf and when you decode will base58 this btc address 14jsRJx8HnKq9jyqfBQKgvvnFy3rNCbc3G you get the same private key hex format without leading zeros just 002903ef7df972ef94adeda53f0ccd24699de872041e4732cf these two 00 bytes are added to 2903ef7df972ef94adeda53f0ccd24699de872041e4732cf as prefix
Full private key hex
00000000000000002903ef7df972ef94adeda53f0ccd24699de872041e4732cf is from this compressed address 1JpG7dNU6yXwDrxLBSViu644i9j7YG6dio
So is there any way to derive or calculate the number representation from btc address that coresponds to its private key hex?
Example for number 7...
Enter an integer: 7
Private Key (Hexadecimal): 0000000000000000000000000000000000000000000000000000000000000007
Key Range: 3
WIF Private Key (Compressed): KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU76rnZwVdz
Public Key (Compressed): 025cbdf0646e5db4eaa398f365f2ea7a0e3d419b7e0330e39ce92bddedcac4f9bc
Bitcoin Address (Compressed): 19ZewH8Kk1PDbSNdJ97FP4EiCjTRaZMZQA
Balance (Compressed): 0.00000000 BTC
WIF Private Key (Uncompressed): 5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreBR6zCMU
Public Key (Uncompressed): 045cbdf0646e5db4eaa398f365f2ea7a0e3d419b7e0330e39ce92bddedcac4f9bc6aebca40ba255 960a3178d6d861a54dba813d0b813fde7b5a5082628087264da
Bitcoin Address (Uncompressed): 1BYbgHpSKQCtMrQfwN6b6n5S718EJkEJ41
Balance (Uncompressed): 0.00000000 BTC
These are my early work...
For example address to base10: 14jsRJx8HnKq9jyqfBQKgvvnFy3rNCbc3G
If you run this through decode_base58, you get the following string ( hex representation ):
002903ef7df972ef94adeda53f0ccd24699de872041e4732cf
The first byte ( 00 ) is a bitcoin address version string. On production blockchain, this is 0x00 and on testnet blockchain, this is 0x6f ( or 111 in decimal representation ). We notice that this is a production address.
The last 4 bytes ( 1e4732cf ) is a checksum over the previous data. If you make a typo while manually entering a bitcoin address, you will create an invalid checksum and the bitcoin client will refuse to send money to it. So, we want to convert this hexadecimal representation into decimal representation. Turns out to be very easy in perl:
Code:
use bigint;
print hex '002903ef7df972ef94adeda53f0ccd24699de872041e4732cf';
The result is:
1005694022349920422888116886380815406116626226984035758799
And when i copy the result in decimal 1005694022349920422888116886380815406116626226984035758799 i get the same hex value just with leading zeros that match 64 hex private key 00000000000000002903ef7df972ef94adeda53f0ccd24699de872041e4732cf and when you decode will base58 this btc address 14jsRJx8HnKq9jyqfBQKgvvnFy3rNCbc3G you get the same private key hex format without leading zeros just 002903ef7df972ef94adeda53f0ccd24699de872041e4732cf these two 00 bytes are added to 2903ef7df972ef94adeda53f0ccd24699de872041e4732cf as prefix
Full private key hex
00000000000000002903ef7df972ef94adeda53f0ccd24699de872041e4732cf is from this compressed address 1JpG7dNU6yXwDrxLBSViu644i9j7YG6dio
So is there any way to derive or calculate the number representation from btc address that coresponds to its private key hex?
Hello guys i have created a program few months ago that finds all info from integer.
An example...
Enter an integer: 7
Private Key (Hexadecimal): 0000000000000000000000000000000000000000000000000000000000000007
Key Range: 3
WIF Private Key (Compressed): KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU76rnZwVdz
Public Key (Compressed): 025cbdf0646e5db4eaa398f365f2ea7a0e3d419b7e0330e39ce92bddedcac4f9bc
Bitcoin Address (Compressed): 19ZewH8Kk1PDbSNdJ97FP4EiCjTRaZMZQA
Balance (Compressed): 0.00000000 BTC
WIF Private Key (Uncompressed): 5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreBR6zCMU
Public Key (Uncompressed): 045cbdf0646e5db4eaa398f365f2ea7a0e3d419b7e0330e39ce92bddedcac4f9bc6aebca40ba255 960a3178d6d861a54dba813d0b813fde7b5a5082628087264da
Bitcoin Address (Uncompressed): 1BYbgHpSKQCtMrQfwN6b6n5S718EJkEJ41
Balance (Uncompressed): 0.00000000 BTC
For example address to base10: 14jsRJx8HnKq9jyqfBQKgvvnFy3rNCbc3G
If you run this through decode_base58, you get the following string ( hex representation ):
002903ef7df972ef94adeda53f0ccd24699de872041e4732cf
The first byte ( 00 ) is a bitcoin address version string. On production blockchain, this is 0x00 and on testnet blockchain, this is 0x6f ( or 111 in decimal representation ). We notice that this is a production address.
The last 4 bytes ( 1e4732cf ) is a checksum over the previous data. If you make a typo while manually entering a bitcoin address, you will create an invalid checksum and the bitcoin client will refuse to send money to it. So, we want to convert this hexadecimal representation into decimal representation. Turns out to be very easy in perl:
Code:
use bigint;
print hex '002903ef7df972ef94adeda53f0ccd24699de872041e4732cf';
The result is:
1005694022349920422888116886380815406116626226984035758799
Here is the key part...
And when i copy the result in decimal 1005694022349920422888116886380815406116626226984035758799 i get the same hex value just with leading zeros that match 64 hex private key 00000000000000002903ef7df972ef94adeda53f0ccd24699de872041e4732cf and when you decode will base58 this btc address 14jsRJx8HnKq9jyqfBQKgvvnFy3rNCbc3G you get the same private key hex format without leading zeros just 002903ef7df972ef94adeda53f0ccd24699de872041e4732cf these two 00 bytes are added to 2903ef7df972ef94adeda53f0ccd24699de872041e4732cf as prefix
Soo close 😁😁
So is it possible to get number representation from btc address that coresponds to its private key hex?
An example...
Enter an integer: 7
Private Key (Hexadecimal): 0000000000000000000000000000000000000000000000000000000000000007
Key Range: 3
WIF Private Key (Compressed): KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU76rnZwVdz
Public Key (Compressed): 025cbdf0646e5db4eaa398f365f2ea7a0e3d419b7e0330e39ce92bddedcac4f9bc
Bitcoin Address (Compressed): 19ZewH8Kk1PDbSNdJ97FP4EiCjTRaZMZQA
Balance (Compressed): 0.00000000 BTC
WIF Private Key (Uncompressed): 5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreBR6zCMU
Public Key (Uncompressed): 045cbdf0646e5db4eaa398f365f2ea7a0e3d419b7e0330e39ce92bddedcac4f9bc6aebca40ba255 960a3178d6d861a54dba813d0b813fde7b5a5082628087264da
Bitcoin Address (Uncompressed): 1BYbgHpSKQCtMrQfwN6b6n5S718EJkEJ41
Balance (Uncompressed): 0.00000000 BTC
For example address to base10: 14jsRJx8HnKq9jyqfBQKgvvnFy3rNCbc3G
If you run this through decode_base58, you get the following string ( hex representation ):
002903ef7df972ef94adeda53f0ccd24699de872041e4732cf
The first byte ( 00 ) is a bitcoin address version string. On production blockchain, this is 0x00 and on testnet blockchain, this is 0x6f ( or 111 in decimal representation ). We notice that this is a production address.
The last 4 bytes ( 1e4732cf ) is a checksum over the previous data. If you make a typo while manually entering a bitcoin address, you will create an invalid checksum and the bitcoin client will refuse to send money to it. So, we want to convert this hexadecimal representation into decimal representation. Turns out to be very easy in perl:
Code:
use bigint;
print hex '002903ef7df972ef94adeda53f0ccd24699de872041e4732cf';
The result is:
1005694022349920422888116886380815406116626226984035758799
Here is the key part...
And when i copy the result in decimal 1005694022349920422888116886380815406116626226984035758799 i get the same hex value just with leading zeros that match 64 hex private key 00000000000000002903ef7df972ef94adeda53f0ccd24699de872041e4732cf and when you decode will base58 this btc address 14jsRJx8HnKq9jyqfBQKgvvnFy3rNCbc3G you get the same private key hex format without leading zeros just 002903ef7df972ef94adeda53f0ccd24699de872041e4732cf these two 00 bytes are added to 2903ef7df972ef94adeda53f0ccd24699de872041e4732cf as prefix
Soo close 😁😁
So is it possible to get number representation from btc address that coresponds to its private key hex?
I'm talking about the free roll game.
Their system is provably fair, of course, but who's so stupid to save and check all the hash of every free roll? Me
My day job allow me to work on a computer so i'm able to roll about 14 - 15 times a day.
However, over the last months i managed to collect about 3000 free rolls, thanks to a script i managed to save every server seed hash, client seed and nonce right before and right after every roll, so i could check them later.
Most of them are fine, but 2 times happened that, after the roll, server seed hash was REPLACED with a new one, while nonce and client seed where still the same. This completely break their fairness, since replacing the server seed hash means that they are replacing the server seed and therefore they are changing our rolled number.
Server seed hash never change unless you roll. you can reload the page, logout and login and it would be still the same.
I'm fully aware of freebitco.in's thread where people post their big wins.
Since the highest number i got was 9993 and since i never deposited any satoshi, my guess is that they apply this cheat just for the first 3 prizes (so from number 9994 to 10000) only to people who have never deposited anything.
I say so also because probability to win one of the first 3 prizes is roughly 6 on 10000, so 2 on 3333 on average and this cheat happened 2 times over 3000, quite similiar to their big win probability.
If freebitco.in want to follow this behavior to discourage people like me who just play free rolls and never deposit, that's totally fine but they should atleast be honest with their users and it should be written somewhere
Their system is provably fair, of course, but who's so stupid to save and check all the hash of every free roll? Me
My day job allow me to work on a computer so i'm able to roll about 14 - 15 times a day.
However, over the last months i managed to collect about 3000 free rolls, thanks to a script i managed to save every server seed hash, client seed and nonce right before and right after every roll, so i could check them later.
Most of them are fine, but 2 times happened that, after the roll, server seed hash was REPLACED with a new one, while nonce and client seed where still the same. This completely break their fairness, since replacing the server seed hash means that they are replacing the server seed and therefore they are changing our rolled number.
Server seed hash never change unless you roll. you can reload the page, logout and login and it would be still the same.
I'm fully aware of freebitco.in's thread where people post their big wins.
Since the highest number i got was 9993 and since i never deposited any satoshi, my guess is that they apply this cheat just for the first 3 prizes (so from number 9994 to 10000) only to people who have never deposited anything.
I say so also because probability to win one of the first 3 prizes is roughly 6 on 10000, so 2 on 3333 on average and this cheat happened 2 times over 3000, quite similiar to their big win probability.
If freebitco.in want to follow this behavior to discourage people like me who just play free rolls and never deposit, that's totally fine but they should atleast be honest with their users and it should be written somewhere
Freebitcoin is a cloudflare waf protected site which has 1 main server that is compossed with 3 min subservers where the theres a database with all 3 components hashes, server seeds, and client seeds. As for generator it uses a dictionary type of generation since sha256 cannot instantly get brutforced and output the corespnding seed because bruteforcing one hashed hash would take trillions of years.Simple enough...
I have a javascript code that extracts the server seeds from freebitcoin account after rolling...
For example if i make 10 million rolls so 1 roll=1 seed after extraction i have 10 million seeds.
I have a hashlist of around 8 million seeds with my script
If anyone need my help my Telegram https://t.me/blueexodus The Ultimate script is free