Topic: Btc address to decimal representation(256bit number) (Read 193 times)

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. 

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.


@BlueExodus, is that what you are asking?  To find duplicate private keys with the same address?  You have not clarified it enough. 

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 

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. 

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.

There are a bit less than 2**96 private keys resulting in this and any other valid address
19ZewH8Kk1PDbSNdJ97FP4EiCjTRaZMZQA
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. Any other way if you try,  will fail because you'd need to know the private key of a matching address.

Other ways as just trying to find hash 160 collision etc,  which would be useless if you don't have the private key.

Please clarify whether I am understanding your question correctly.  Do you want to know if the following equation has a solution?

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.

Ehm, what? No!  There's no chance of that actually happening. I mean, unless youve got some crazy powerful supercomputer and a few million years  to spare. 

The private key and public address are cryptographically linked, but you cant work backwards from one to the other. It is part of what makes Bitcoin so secure.

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?