How to find the public key of a Bitcoin address

Hey everyone. Just curious if there's any tool, script, or way to get the uncompressed public key from a Bitcoin address. I heard that if an address has sent money, it might be possible to track it down. Honestly, I'm not sure how to go about finding that info. Appreciate any help!

In essence, bitcoin address is a hash of public key. Given that hash function is a one-way function, there are no methods or tools exist to calculate it "back". When you send your bitcoins, you are signing a message with your private key and also reveal your public key, so that everyone in the network can verify that you actually have a private key, meaning that you have a right to spend coins.

I actually posted[1] about this a few days back I think. So the format of P2PKH sigscript is the signature followed by the public key. So basically, extract the sigscript, identify the signature and there should be a OP_Pushbytes_65 (since we're talking about uncompressed) which is 41 in hex. You should get the public key pertaining to that specific address. You can probably write a script to separate and identify the public key pretty easily. [1] https://bitcointalk.org/index.php?topic=5302887.msg55912788#msg55912788

Any way that's available I just thought that getting it from sigscript was only way possible Ok I get that but the full  public key is 130 characters. Is it the first 65 (X value) [moderator's note: consecutive posts merged]

An address that has never spent any coins hasn't revealed its public key. Public keys are hashed multiple times to get our addresses. Specifically, these are the steps of how we end up with an address: 1) We generate a 256-bit private key. 2) We, then, perform ECDSA to get our public key (compressed): (Compressed means only the x coordinate. We don't have to carry the y since it can be calculated from y2 = x3 + 7. Since y2 returns 2 different values, we use the prefix 02 or 03 in front of the compressed public key to determine if y is odd or even) 3) We hash that compressed public key with SHA-256: 4) After that, we perform RIPEMD-160 hashing to the SHA-256 result: 5) Add version byte in front of RIPEMD-160 hash (00 for Main Network): 6) Again, SHA-256 to the previous result: 7) We hash the SHA-256 result with SHA-256 again: 8) The first 4 bytes of the last SHA-256 result is address' checksum: 9) Extend the RIPEMD-160 hash from part 5 with these 4 bytes: 10) Convert this to base58 and here you go: [from bitcoin.it] Got a little off-topic, but anyway. As far as I know, you can find the uncompressed public key from the scriptSig of a transaction (P2PKH address). You can do it pretty easily here: iancoleman.io/bitcoin-key-compression. You can also convert compressed public keys to uncompressed with the equation I mentioned above.

I am referring to addresses that have spent coins and therefore exposed public key.

I think it'll be easier to represent it in a transaction with an uncompressed public key. Let's inspect this address: 1MsHWS1BnwMc3tLE8G35UXsS58fKipzB7a TXID: 3410bc9f7671d30225678a870f8d695cad1af6f64b0a319a487d3b86540794ab ScriptSig: 48 3045022100a9830934fffb69c597f68a1d5f5b6621a5d384ba4a4c81c316c08f652ed8036202206 cef70d41b95bfd53c6ee3cc0a69ab7c96d9a1ef18ffbf100505851ba53d266b01 - Signature 41 044f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa385b6b1b8ead8 09ca67454d9683fcf2ba03456d6fe2c4abe2b07f0fbdbb2f1c1 - Public key. Yes, you can interpret the last 130 characters (or 65 bytes) of a scriptsig as the public key. Clients generating uncompressed public keys are a rarity nowadays, given bech32 and the inefficiency of uncompressed public keys.

Ok I think I have found how to do that now. How about a method to do the reverse (turn uncompressed public key into address)? So I can verify that the public key I am gathering is correct.

This online tool will do it for you: https://gobittest.appspot.com/Address Just ignore the box labelled "0 - Private ECDSA Key"... and put the public key in the box labelled "1 - Public ECDSA Key" and then press "Send"... it'll show you the step by step guides and the address at the bottom... but the method is basically the same as BlackHatCoiner posted above: 1 - Public ECDSA Key 2 - SHA-256 hash of 1 3 - RIPEMD-160 Hash of 2 4 - Adding network bytes to 3 5 - SHA-256 hash of 4 6 - SHA-256 hash of 5 7 - First four bytes of 6 8 - Adding 7 at the end of 4 9 - Base58 encoding of 8

A full public key is 130 hexadecimal characters, which corresponds to 520 bits. This is composed of the following three things concatenated (joined) together: A compressed public key is 66 hexadecimal characters, which corresponds to 264 bits. This is composed of the following two things concatenated together: Because of the nature of the elliptic curve that bitcoin uses, each x coordinate can produce two valid y coordinates, one of which will be even and one of which will be odd. Knowing the x coordinate and whether y is even or odd allows you to calculate the correct y coordinate. If you don't care about the steps and just want the final result, then the link BlackHatCoiner shared above - https://iancoleman.io/bitcoin-key-compression/ - might be better, since it will automatically compress or uncompress your public key and provide both addresses.

Thanks that helps. The issue I am still having is that when a address sends btc and I look at the scriptsig and extract the last 130 hex characters and enter it it the tools suggested in this thread it doesn't have any relation to the address or it's an invalid public key.

Are you sure that it's an uncompressed key? Is it a bech32 or other forms of address type? Most of the keys are compressed public keys and you'll be looking at 66 hex characters or 33 bytes. Could you give an example of the transaction in question?

You will continue being confused and will face new problems any time you see a different transaction from the last one you saw when you jump in at the middle instead of starting at the beginning! You should start by first understanding the structure of a transaction (https://developer.bitcoin.org/reference/transactions.html#raw-transaction-format) then follow it up by learning how bitcoin scripts work (https://en.bitcoin.it/wiki/Script) and finally start looking at transactions to try and find the public keys in them.

As a worked example... have a look at this recent tranasction: https://www.blockchain.com/btc/tx/bee2768770f68a31543eda6fd40da75e4432f434cf8c3312497cdeebb4a2ac6c If we look at the sigscript: Firstly we try the final 130 chars: Doesn't begin with "04", so it's not an uncompressed key... not surprising, given that it is a relatively recent transaction and most legacy addresses used today will be using "compressed" keys. Then we try the final 66: "02", so it's likely a compressed public key... if we put that into the Address tool I listed earlier, we can see it outputs: Which matches the bitcoin address from the transaction: NOTE: This tool was not designed for "compressed" keys... it will complain that it has an "invalid public key length": But it will still generate the correct address. Now, let's look at this much older transaction: https://www.blockchain.com/btc/tx/b9d69463c500b81dc2ff600d0b528b15fb816c4dab11e424151de0bcbea7f26f The sigscript of the first input is: The last 130 chars are: Starts with 04... quite likely an uncompressed public key... So, feeding that into the tool: And we can see the address checks out:

thanks for your response. if we have a transaction like this : https://www.blockchain.com/explorer/addresses/btc/13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so then we have just input in this wallet address but we do not see any output from wallet, so we can not gain any 130 or 66 character pubkey from sigscript. we have only pkscript like this : Pkscript OP_DUP OP_HASH160 20d45a6a762535700ce9e0b216e31994335db8a5 OP_EQUALVERIFY OP_CHECKSIG i want to ask you ,  if we have only HASH160 then How to findout publickey (comprssd or uncomprssd) for that address ??

Well, a bite that big might choke you, first you need to grow some teeth before starting to chew. 😉 If you haven't figured out how these puzzles and in general Bitcoin works, whatever you are attempting is not going to work. Now to answer your question, if an address has any output( sending out) then you can derive the public key by going to this site called Bitcointools.site in there you can insert address and if that address has any spent transaction recorded on block chain, it will show it to you. Technically though, the only way to find that address's public key aka puzzle #66, you either brute force to find the private key or you'd try to break 2 hash functions to get the "public key". To reverse 2 hash functions, you'd need to at least brute force 2^81 different  hashes, but brute forcing for private key would only take a maximum 2^66 key generation processes. If by any chance you are from middle east, you might find your native language topic here : https://bitcointalk.org/index.php?board=11.0

Since hash algorithms are irreversible, it is not possible to compute the message (public key in case of the output script you posted) from the hash digest.

ok. brute forcing private keys of a btc ddress may take less than public keys but some codes need to work with pubkeys... for example , keyhunt in bsgs mode, works faster than other tools in this case. so this tool has an input file or single pubkey to work on it and find the privatekey . Now for these puzzles (that have no output transactions) we have no pubkeys and we can not use bgsg mode of keyhunt. is this correct ??

Well all I can see is just talking, if you have a tool efficient in finding collisions then share it so we can judge it's performance, though I wonder why would you increase your search range like that? You'd probably never find a collision but searching in 66 bit range you will definitely find the key. All the low range keys such as 65, 70, 75, 80, 85, 90 could be found fairly easily, e.g, if you had the public key for #66, it would take a minute considering you had a good gear using kangaroo, that's why they are all solved, now the  biggest challenge next in line is #130, which will be solved probably in a few month from now. Also note that when you are brute forcing to find rmd160, you are performing a sha256 + an rmd160 hashing with each iteration, so you'd get much less speed, but when you have a public key you can search much faster.  But none of the existing tools are good enough, they are practically useless for high ranges. Kangaroo and bsgs only work with public keys, both useless now. Bitcrack vanitygen can search for address/rmd160, both useless now. Don't waste time on addresses/rmd160, instead work on public key division.😉

ok. thank you for your response. i will take a look if you share the source.