I would like to calculate the segwit address of a public address.

First step: 
take the compressed public address:

do a sha256 on that address:

do a ripemd160:

encode with Base58:

There is something wrong since every segwit address should start with "3". Can someone help me which step it is?

My source of how a segwit address is calculated is: How to get legacy address and private key from Segwit P2SH address? Quote:

You have the private key so you can just derive the address from there. Get the corresponding public key, hash it with SHA256 and then that result with RIPEMD160. Then perform Base58Check Encoding on it.


Firstly, it is very dangerous to convert a public address to a different form and then use it, because the owner of that address will not be expecting payments on other forms, and could result in fund loss. Only use addresses which the recipient has asked you to use.

But there is a difference between a compressed public key and an address. Bitcoin addresses starting with 1 are base58 encoded keyhash with a checksum. To get the key hash which is the ripemd/sha256 hash of the public key, you must decode the base58 and ensure the checksum is correct. Then you simply use the keyhash in the redeem script, you don't need to perform any more hashing on it to form the P2WPKH script. Notice that there is no way to know if an address starting with a 1 used a compressed or uncompressed public key before it's spent, so if you tried to convert one which had an uncompressed key, it would be unspendable, very dangerous as I said earlier.

See here for more details: https://bitcoincore.org/en/segwit_wallet_dev/#creation-of-p2sh-p2wpkh-address


Java code doing that was pasted here, but mostly without any explanation, so I'll try to explain.

When I was looking information about it, the best example was found in BIP-49 text. We start from the following line:

// Address derivation
keyhash = HASH160(account0recvPublickKeyHex) = 0x38971f73930f6c141d977ac4fd4a727c854935b3

So we have 20 bytes of public key hash: < keyhash >. If we want to obtain legacy key, we simply prepend < prefixByte > (prefixByte = 0 for BTC main) and get < prefixByte | keyhash > array. Then we should do HASH160(< prefixByte | keyhash >), and take first 4 bytes as checksum. So the resulting address looks like < 0 | keyhash | checksum > - 25 bytes total. It is an address in his hex form. To get a common form we should only base58-encode it.

If we want to obtain a segwit-address, first we want to get < keyhash >. We should decode base58-encoded address to an < addressArray > and check the checksum (that last 4 bytes are equal to HASH160 of first 21). If everything is correct, we should drop first one and last four bytes of < addressArray > to obtain a < keyhash >.

The next step is to get a < scriptSig >, simply prepending 0x0014 bytes to a < keyhash > array:

scriptSig = < 0 < keyhash > > = 0x001438971f73930f6c141d977ac4fd4a727c854935b3

We get segwitBytes hashing < scriptSig >:

segwitBytes = HASH160(scriptSig) = 0x336caa13e08b96080a32b5d818d59b4ab3b36742

And finally, we get an address, prepending p2shHeader (=5 for BTC MainNet, 196 for BTC Testnet) to segwitBytes, and appends their checksum:

// segwitBytes base58check encoded for testnet
address = base58check(p2shHeader | segitBytes) = 2Mww8dCYPUpKHofjgcXcBCEGmniw9CoaiD2 (testnet)

HASH160 is following: first we use SHA256 function to hash and than RIPEMD160 on result. The example implemented in Java can be found for example here (function org.bitcoinj.core.Utils.sha256hash160).

  • 1
    +1 for laying out the steps for this specific case – MeshCollider Dec 31 '17 at 0:13

you may need to use hex values to do the conversion. Bitcoin doesn't work with strings/chars... When I do the calc at the terminal, I get your result (e.g. for the SHA256 to ripemd160):

printf 151de228f6bec7635097f7813786830505d04bf56806f11eb056441fdc917d41 | openssl dgst -ripemd160
(stdin)= 9bbfb2424372d687cf35fd7d1e978f85a11157ca

But this would be the wrong way. You first would need to convert to hex, like this:

$ printf 151de228f6bec7635097f7813786830505d04bf56806f11eb056441fdc917d41 > tmp_sha256.txt
$ printf $( cat tmp_sha256.txt | sed 's/[[:xdigit:]]\{2\}/\\x&/g' ) > tmp_sha256.hex
$ hexdump -C tmp_sha256.hex 
00000000  15 1d e2 28 f6 be c7 63  50 97 f7 81 37 86 83 05  |...(...cP...7...|
00000010  05 d0 4b f5 68 06 f1 1e  b0 56 44 1f dc 91 7d 41  |..K.h....VD...}A|

then you can convert to next step like this:

$ openssl dgst -ripemd160 tmp_sha256.hex 
RIPEMD160(tmp_sha256.hex)= db151e871af66b1323893e3f527e22f7684718af

all in all:

$ printf 1L88S26C5oyjL1gkXsBeYwHHjvGvCcidr9 > adr.txt
$ printf $( cat adr.txt | sed 's/[[:xdigit:]]\{2\}/\\x&/g' ) >adr.hex
$ openssl dgst -sha256 -binary <adr.hex >tmp_sha256.hex
$ hexdump -C tmp_sha256.hex 
$ openssl dgst -ripemd160  <tmp_sha256.hex

returns a string now (56379c7bcd6b41188854e74169f844e8676cf8b8), that is then base58encoded into this address:


  • how did you get 56379c7bcd6b41188854e74169f844e8676cf8b8? – Adam Dec 16 '17 at 18:04
  • 1
    when you don't provide an output file to openssl, and remove the "-binary", then it writes to the console: "openssl dgst -ripemd160 <tmp_sha256.hex". Are you on Windows or Unixoide systems? – pebwindkraft Dec 17 '17 at 8:10
  • No, i'm not on windows. performing the third step returns -bash: svn.hex: No such file or directory – Adam Dec 17 '17 at 16:10
  • 1
    oops, I should stay consistent with my filenames. it must be "openssl dgst -sha256 -binary <adr.hex >tmp_sha256.hex". (I did several tries, and first I used filenames "svn", and then "adr" ...). I just double checked it, it works now. – pebwindkraft Dec 17 '17 at 23:03
  • 2
    This approach is quite wrong, see my answer – MeshCollider Dec 18 '17 at 9:54

Your Answer

