Address and key format

MultiChain addresses and private keys are similar to those in bitcoin

The format of addresses and private keys in MultiChain is similar to that of bitcoin addresses and private keys. However there are some differences, which ensure that addresses and keys created on one MultiChain blockchain are extremely unlikely to be valid on a second chain. This in turn prevents a developer error from accidentally performing an operation on one chain which was intended for another.

On a technical level, bitcoin’s scheme uses a single version byte for addresses, meaning that it can only define 256 separate address spaces. By contrast, MultiChain’s scheme uses up to 4 version bytes and an additional 4-byte value which modifies a checksum. This allows 264 or over 1019 separate address spaces to be defined for different blockchains. In MultiChain these byte values are generated randomly when a new chain is created and represented by the address-pubkeyhash-version and address-checksum-value values in the blockchain parameters. There are also address-scripthash-version and private-key-version parameters which define the version bytes for pay-to-scripthash addresses and the exporting of private keys. These *-version parameters can be between 1 and 4 bytes in length, but they must all be the same length.

If you want MultiChain’s addresses and private keys to be fully compatible with bitcoin’s, set the following values in the blockchain parameters after the blockchain is created but before its genesis block is created:

address-pubkeyhash-version=00
address-scripthash-version=05
private-key-version=80
address-checksum-value=00000000

How to create a MultiChain address

Steps which differ from the corresponding bitcoin address calculations are indicated below. Note that all input data for hash calculations should be in raw binary format, not the hexadecimal strings shown here.

  1. Start with a raw private ECDSA key:
    283D01856115B7970B622EAA6DAFF2B9ECE30F1B66927592F6EA70325929102B
  2. Take the corresponding public key generated with it, which can be in compressed or uncompressed format. The uncompressed version contains 65 bytes, consisting of 0x04, 32 bytes for the X coordinate and 32 bytes for the Y coordinate. The compressed version contains 33 bytes, consisting of 0x02 (Y is even) or 0x03 (Y is odd), followed by 32 bytes for the X coordinate. Below is a compressed example:
    0284E5235E299AF81EBE1653AC5F06B60E13A3A81F918018CBD10CE695095B3E24
  3. Calculate the SHA-256 hash of the binary public key:
    1C72D90868DBCD0252A54EFFB25FB535B4C89B67D57B75FD88465C5F173DCAB5
  4. Calculate the RIPEMD-160 hash of this SHA-256 hash:
    EC00B99365A09B6E26C732378CD0C6257F7012BC
  5. Different from bitcoin: Add the first version byte from the address-pubkeyhash-version blockchain parameter to the start of the RIPEMD-160 hash. If it is more than one byte long, insert each subsequent byte of it after every floor(20/len(address-pubkeyhash-version)) bytes of the hash. For example with 00AFEA21:
    00EC00B99365AFA09B6E26C7EA32378CD0C621257F7012BC
  6. Calculate the SHA-256 of the extended RIPEMD-160 result:
    EB04567F3EAA7DF652AEF6CF00F37BFBDE4C4848C257ADF6EE5CE3EA16B8FCAD
  7. Calculate the SHA-256 hash of the previous SHA-256 hash:
    9087E7F4C7A298F66B68954C85A0DFEA3B939AC8604B22424F95C446E763DF73
  8. Take the first 4 bytes of the most recent SHA-256 hash. This is the address checksum:
    9087E7F4
  9. Different from bitcoin: XOR this checksum with the address-checksum-value blockchain parameter. For example with 953ABC69:
    05BD5B9D
  10. Add the 4-byte checksum (after XORing) at the end of extended RIPEMD-160 hash. This is the 28-byte (for a 4-byte version) binary address:
    00EC00B99365AFA09B6E26C7EA32378CD0C621257F7012BC05BD5B9D
  11. Convert the result to a string using bitcoin base58 encoding. This gives the commonly used address format:
    1Yu2BuptuZSiBWfr2Qy4aic6qEVnwPWrdkHPEc

How to create a MultiChain private key

Steps which differ from the corresponding bitcoin address calculations are indicated below. Note that all input data for hash calculations should be in raw binary format, not the hexadecimal strings shown here.

  1. Start with a raw private ECDSA key:
    B69CA8FFAE36F11AD445625E35BF6AC57D6642DDBE470DD3E7934291B2000D78
  2. Add 0x01 at the end if this private key corresponds to a compressed public key:
    B69CA8FFAE36F11AD445625E35BF6AC57D6642DDBE470DD3E7934291B2000D7801
  3. Different from bitcoin: Add the first version byte from the private-key-version blockchain parameter to the start of the private key. If it is more than one byte long, insert each subsequent byte of it after every floor(33/len(private-key-version)) bytes of the key. For example with 8025B89E:
    80B69CA8FFAE36F11A25D445625E35BF6AC5B87D6642DDBE470DD39EE7934291B2000D7801
  4. Calculate the SHA-256 of the extended private key:
    742D5B3C59BB25F077AACB33D5770AAE22FD5639E8F9A7742BADEF84BCDFB4CC
  5. Calculate the SHA-256 hash of the previous SHA-256 hash:
    4FBB9708A0B5F2F5AC384CAC22C69CCE3F7DCE6166DE63B5AFE35E5D59767F18
  6. Take the first 4 bytes of the most recent SHA-256 hash. This is the address checksum:
    4FBB9708
  7. Different from bitcoin: XOR this checksum with the address-checksum-value blockchain parameter. For example with 7B7AEF76:
    34C1787E
  8. Add the 4-byte checksum (after XORing) at the end of extended extended private key. This is the 41-byte (for a 4-byte version) key:
    80B69CA8FFAE36F11A25D445625E35BF6AC5B87D6642DDBE470DD39EE7934291B2000D780134C1787E
  9. Convert the result to a string using bitcoin base58 encoding. This gives the commonly used private key format:
    VEEWgYhDhqWnNnDCXXjirJYXGDFPjH1B8v6hmcnj1kLXrkpxArmz7xXw