Sequential Address format Discussion

[SergioDemianLerner]

Bitcoin has a Base58 address format that includes a four-byte checksum. An example of a Bitcoin address is "1FXqE2ixnnSB1kvwbMtWma5xQ2bVbkSq3f". The drawback of Bitcoin addresses is that, even if they include a network identifier, it is not obvious. Ethereum proposes the use of IBAN compatible addresses (ICAP addresses). However, there are several limitations with IBAN addresses: scarce space for address, short checksum, additional complexity.

Even if the address space in RSK is 160 bits, the number of effective addresses that will ever be created is much lower, probably not more than 2^30 or 1 billion addresses. One billion active addresses would consume about 100 Gigabytes of ledger state data.

There are at least three options:

1. Use a smart-contract registry of human readable names or words that converts them into raw addresses.

2. Use blockchain smart-contract registry to register new raw addresses obtaining a sequential counter

3. Let the platform increment a counter for every new address created, and maintains a data structure mapping each sequential number to the associated address.

In all cases there is the problem of name squatting, and blockchain reversals could be used to cheat on an association.

I the third case, a 4-byte nonce could be added next to the sequential number as follows: the nonce is chosen as the last 4 digits of the PoW header hash of the block where the account was created. Therefore, a block reversal creates an entry with a different nonce with high probability.

One billion addresses can be identified by a 9 digit number (e.g. 123-456-789), by a 8-char hexa (e.g. 1f085427), 6-char base36 encoding (e.g. 6M81H7) or by 5 or 6-char base58 encoding (e.g. pXzwq). The base58 encoding is the shortest, but it includes both lowercase and uppercase letters in the alphabet, so it is not suitable to be transferred or verified by voice.

The problem with the option 1 is that, as google usernames, it tend to generate longer address strings, many times containing numbers to distinguish from other people having the same names. Such long username-based addresses have several drawbacks:

• they tend to suggest they should be types instead of copy-pasted, incrementing the risk of mistakes,

• they are prone to name squatting

• they allow an attacker to register all one-char typos of a certain address to steal funds in case of a mistake.

• they create an unintended market for short addresses.

• they incentivize the use of personal identification strings which reduce privacy.

• they are not compatible with deterministic address generation

Base36 encoding has the drawback that 0 (zero), and O (capital o) look similar. Therefore we’ll use a base 35 encoding where the O is replaced by Z (the alphabet is therefore "0123456789ABCDEFGHIJKLMNZPQRSTUVWXY"). We’ll call this encoding Base35H.

Proposed Sequential Address Solution

The proposed solution is to create a smart-contract registry of pairs (S,raw-address), where S is a sequential address. Users willing to use sequential addresses must register their raw-addresses in the registry and pay yearly to maintain the record intact.