Ethereum Stack Exchange is a question and answer site for users of Ethereum, the decentralized application platform and smart contract enabled blockchain. It only takes a minute to sign up.
Sign up to join this community
The ethereum wiki has a specification of basic, direct and indirect ICAP addresses. Where the basic and the direct are well explained here and here, I have trouble to understand how indirect ICAP addresses work?
Can you generate an indirect ICAP address from a raw hex ethereum key? If so, how does that work out?
Or is it meant to be calculated reverse? Like you have the address first and calculate the hex backwards? But how is associated private key generated that way? Is that even possible?
Indirect addresses work together with asset registries.
From the specification:
Indirect
The BBAN for this code when indirect will be 16 characters and will comprise three fields:
Asset identifier, 3-character alphanumeric (< 16-bit); Institution identifier, 4-character alphanumeric (< 21-bit); Institution client identifier, 9-character alphanumeric (< 47-bit); Including the four initial characters, this leads to a final client-account address length of 20 characters, of the form:
XE81ETHXREGGAVOFYORK
Split into:
XE The country code for Ethereum;
81 The checksum;
ETH The asset identifier within the client account - in this case, "ETH" is the only valid asset identifier, since Ethereum's base registry contract supports only this asset;
XREG The institution code for the account - in this case, Ethereum's base registry contract;
GAVOFYORK The client identifier within the institution - in this case, a direct payment with no additional data to whatever primary address is associated with the name "GAVOFYORK" in Ethereum's base registry contract;
When sending a transaction to an Indirect ICAP address, the following will happen:
I do not think this part is fully specified yet, although there is a hint at it in the web3.js sources:
A direct ICAP address is one in which the hex Ethereum address is directly encoded. In other words: given a direct ICAP address, you can do some math on it and end up with the hex address.
An indirect ICAP address does not encode the actual hex address. Instead, a level of indirection (a database lookup, for instance) is required in order to obtain the hex address.
During account creation the hex address is determined cryptographically from an account's private key, so there is no way to start with a desired hex address and create an account for it. Because of this, an organization that wishes to encode data visibly in an account's address in a particular format (as described in @axic's answer) must use the indirect method.
