2

With the raw address 0x0000861299624c9a3b52be10762c64bac282b1c02316 the first 4 characters (0000 in this case) represent tz1 and the rest of the string is the raw Tezos address.

From my research it appears that the rest of the bytes, 861299624c9a3b52be10762c64bac282b1c02316 must get hashed before it can be converted to a string with base58 but I am not sure which of the available hashing algorithms I should use to do so.

Which algo should I be using to get these bytes into the pre-base58 hashed byte form? (i.e. the state before converting that data to its final form of XrwX7i9Nzh8e6UmG3VnFkAeoyWdTqDf3U with base58)

Is it blake2b?

1

1 Answer 1

3

It’s not hashed. You simply need to compute the base58 translation with the right prefix.

Proof that it’s not hashed: this process is reversible.

4
  • this is the answer that caused my confusion: tezos.stackexchange.com/a/3069/7981 - does this mean that the answer to that question is misleading?
    – 0x10
    May 26 at 5:33
  • This answer is also correct. KT1 addresses do involve hashing (blake2b if I remember well). However, conversions between byte representation and addresses don’t involve hashing.
    – FFF
    May 27 at 1:12
  • so the raw bytes represent a hash of an address when it is a KT1, but represents an unhashed address when it is a tz addresses?
    – 0x10
    May 27 at 4:30
  • The address is itself a plain regular hash for KT1, whether written KT1…. or in bytes. Those are representations of the same thing. Tz* accounts are related to the underlying keys, no blake2b involved.
    – FFF
    May 27 at 10:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.