Closed joepetrowski closed 5 years ago
JoshOrndorff
commented
5 years ago When this doc is written, we should link to it from the subkey writeup.
- Address (aka **Public Address**) - An SS58-encoded address based on the public key.
+ Address (aka **Public Address**) - An [SS58-encoded](link here) address based on the public key.@joepetrowski Are the docs you pasted above known to be incorrect? Any pointers on where I can confirm for myself and update them?
joepetrowski
commented
5 years ago Are the docs you pasted above known to be incorrect?
No, but they are quite old so I wouldn't trust them.
JoshOrndorff
commented
5 years ago Looks like a good place to jump in https://github.com/paritytech/substrate/blob/cf4a28a7e707190c44e73451e9da38de6bb160ec/core/primitives/src/crypto.rs#L235
JoshOrndorff
commented
5 years ago Most of the changes from what's written above seem to have happened in https://github.com/paritytech/substrate/pull/1795
JoshOrndorff
commented
5 years ago I've made a draft in #108
JoshOrndorff
commented
5 years ago Seems we should revert to the original article after discussion in riot today
JoshOrndorff
commented
5 years ago JoshOrndorff
commented
5 years ago So here's my question after thinking about this issue for a few days now. Under what circumstances would someone use an address format other than the sr25519 or ed25519 ones that I had written up?
When I wrote my first version, I thought I was answering the question: Given an sr25519 or ed25519 raw public key, how can I calculate the same SS58 address that subkey or Apps gives me?
What is the actual question that I should have been answering?
joepetrowski
commented
5 years ago If this is an address for holding tokens then I don't know of other curves from which one would derive an address. GRANDPA validators use a BLS18-381 key to sign commit messages though so they would be identifiable by their key, although this wouldn't hold funds.
Related to deprecation of the wiki. Need up to date docs on address format. https://github.com/paritytech/wiki/pull/335
Old:
title: External Address Format (SS58)
SS58 is a simple address format designed for Substrate based chains. There's no problem with using other address formats for a chain, but this serves as a robust default. It is heavily based on Bitcoin's Base-58-check format with a few alterations.
The basic idea is a base-58 encoded value which can identify a specific account on the Substrate chain. Different chains have different means of identifying accounts. SS58 is designed to be extensible for this reason.
Basic Format
The basic format conforms to:
That is, the concatenated byte series of address type, address and checksum then passed into a base-58 encoder. The
base58encodefunction is exactly as defined in Bitcoin and IPFS, using the same alphabet as both.Address Type
The
<address-type>is one or more bytes that describe the precise format of the following bytes.Currently, there exist four valid values:
00000000b (0) Polkadot Live (SS58 checksum preimage)
The latter two are "wildcard" addresses that are meant to be equally valid on all Substrate networks that support fixed-length addresses and/or indexed addresses. For production networks, however, a network-specific version may be desirable to help avoid the key-reuse between networks and some of the problems that it can cause. Substrate Node will default to printing keys in address type 42, though alternative Substrate-based node implementations (e.g. Polkadot) may elect to default to some other type.
Address Formats for Substrate
There are 16 different address formats, identified by the length (in bytes) of the total payload (i.e. including the checksum).
3 bytes: 1 byte account index, 1 byte checksum
Checksum types
Several potential checksum strategies exist within Substrate, giving different length and longevity guarantees. There are two types of checksum preimage (known as SS58 and AccountID) and many different checksum lengths (1 to 8 bytes).
In all cases for Substrate, the Blake2-256 hash function is used. The variants simply select the preimage used as the input to the hash function and the number of bytes taken from its output.
The bytes used are always the left most bytes. The input to be used is one of:
SS58: The non-checksum portion of the SS58 byte series used as input to the base-58 function, i.e.
concat( <address-type>, <address> ).The advantage of using more checksum bytes is simply that more bytes provide a greater degree of protection against input errors and index alteration at the cost of widening the textual address by an extra few characters. For the account ID form, this is insignificant and therefore no 1-byte alternative is provided. For the shorter account-index formats, the extra byte represents a far greater portion of the final address and so it is left for further up the stack (though not necessarily the user themself) to determine the best tradeoff for their purposes.
The advantages of using the SS58 preimage format is that the resultant address may be trivially checked for validity, even when offline. However, when combining this with the account-index short-forms, the format doesn't manage the concern that the same index may eventually represent a different underlying address, perhaps one that the original owner doesn't hold. Using the AccountID preimage format means that any change in the underlying account-id must have the same initial portion of hash-output as the original account-id. At lower sizes of checksum, this does little more than prevent accidentally using an old SS58 address. For higher sizes it provides modest, but quantifiable, security against a casual attacker, requiring the attacker to find an address whose Blake2 hash that shares upto 8 bytes with the original.