# Using Identities for on chain transactions

Why talk about this now? For the new anchor scheme, we want to build an authentication scheme that doesn't rely on `msg.sender`. For this we need to be able to uniquely specify a Centrifuge ID and the key used for the signature. This is when I came up with the idea to use some of the bits we have in the uint256 and shorten Centrifuge ID instead storing two mappings.

See the document on [Pre Commit & Commit](https://hackmd.io/EfvRCxSTR3C2l7-UCt7tlw?both#Signatures)


https://en.wikipedia.org/wiki/Birthday_attack#Mathematics

## Proposal: ID uint256 -> ID: uint48 + uint32 (key) + EmptyRemains

We picked uint256 because it was the biggest value we could easily use to store CentrifugeIDs. When picking a value at random and using it, chances of finding a collision are extremely low. A 256bit uint has 77 digits. Your brain does not work with numbers that big. Ethereum addresses are 160 bit long. I propose we use a smaller number for IDs and use the extra digits to for something useful:

function (centId, key) {
store centId "+" key

}

[xxxxxxxxxxxxxxxxxxxxxx-xxxxxxxxx]
[ Centrifuge ID        - key id  ]

>> If I understand this correctly, a centId will become 128bits long and what the peers will use to pass back and forth will be the ComposedId (CentId+keyId)? I am not sure I understand that yet.
>> I like the idea of simplifying our storage. What do you think about the ComposedId that is passed around changing when rotating keys? And the fact that we have P2P key as well (at the moment is the same, but will want to split that up).
>> I would like to know more on how it will look like in the smart contracts. [name=Miguel Hervas]
>
> I think we can store these separately. The composed ID would just be a way to transmit/store the comnbination of which key was used and what ID it was in a uint256 field.
> You would only need to store a full id if you want to also identify which key it was that was used to sign but this is not always necessary. However it is needed when you want to efficiently verify a signature on chain because if you don't know which key it was signed with, you would have to check against every public key on the identity. [name=Lucas Vogelsang]

We could shorten the cent id to use 128 bits and then use the remaining 128 bits for something else. Things we could use the additional bits for:
* Keys: instead of having multiple mappings that keys are stored in, we could store keys in one mapping map[uint64 => uint256] and append the 64 bits to the cent id to indicate which key this message was signed with (or what wallet it was sent from)
* Multi node: we could use additional bits to store information about what node this was sent form. This could allow us to implement smarter routing when multiple nodes are running for the same cent id.
> > Multi node: In this scenario, we still need a different P2P key per node (to uniquely identify within the p2p network), that is our nodeId. Then we can add some other logic to have one node as a relay of connections by passing the destination in the payload to be routed.
> > I think that node metadata should be treated separately. [name=Miguel Hervas]
>
> I think we can leave 64 bits "empty" for now and define the precise functionality later. I haven't thought too much about the multi node stuff. One node could act as a relay for all keys that it's serving as you mentioned but ideally we would make the resolution happen automatically (i.e. I only want to define the destination cent id not who operates the node that runs it)
> When I meant multi node I didn't think of the multi-tenancy thing we are discussing but more about the scenarios where one entity might have multiple systems acting on behalf of it, one example
> [name=Lucas Vogelsang]

The goal should be that we make sure that everything needed to identify a signature/node etc. we could rely on a value that is never longer than 256 bits.

What tare the potential advantages of this:
1) It is cost saving to only store one mapping[uint256 => xxx] instead of two separate mappings. TODO: find out exactly how much.
2) When an endpoint needs to verify a signature, it's not enough to just know the Centrifuge ID to verify it. If just an ID was given, the code would have to iterate over every key on the account to verify the signature. That would be more expensive.