A proposal for self-describing hashes and signatures to enable upgradability within the status protocol.
Within the status protocol right now if we chose to change either the hashing function used, or signature scheme we require a breaking change. This however should not be the case.
When we move away from whisper, we can assume that there may be a change in the way messages are signed, this should therefore already be accounted for. As we are already breaking compatibility in V1 now is the time to do this.
For hashes this is relatively simple, we move all hashes to be represented as multihashes. For signatures however there are multiple routes we can take here. The multiformats repository has 2 open pull requests for these types of multisignatures:
Thanks for the post, while I agree that it would be an improvement I have some doubts about whether it is a good idea to include in v1.
Given the scope of v1, given the amount of changes we are already introducing and the tight deadlines plus the fact that hash and signature schemes are not the part of the protocol that are most likely subject to change, I would defer the decision until our backlog is cleared.
With any change we introduce the possibility of bugs/security issues, and there will be plenty of uncertainty to deal with already (multiacconut, datasync, etc).
That’s not to say that we should not be doing exploratory work, and add to the nice-to-have list for v1, Issues · status-im/status-protocol-go · GitHub (the task there for example is something that I’d rather have in v1).
Another point is that Multihash is currently being used, so we have implementations we can piggy back, and the effort is relatively low. While “multisig” is not, and we would likely have to write custom code to handle it, and probably best not to write our own crypto in the few weeks that we have before code freeze , so it might make sense to consider them separately.
Keep in mind the multisignature would not actually be any crypto code other than being a format for keys. Other than that I agree with most of your points. I feel like due to the way we have added hashing with data sync we may be able to squeeze multihash into that change already.
I’ll back Andrea, but what are the repercussions of doing this later? Will it have a noticeable impact from the user perspective, e.g. chat incompatibility between v1 and v1.n?
It’s a bit difficult to say with certainty, as we would have to identify each place where we use signatures and hashes.
Of the top of my head, there are a few places (signed bundles, signed messages,group membership signatures), where we can keep compatibility by just adding the new field and not removing the old one (i.e bundlesv2, signaturev2), at the cost of bandwidth/complexity.
Mind though that changing hashing scheme or signature scheme is something that is fairly unlikely to happen, at least in the foreseeable future (we use sha3 and secp256k1, which is standard for the ethereum eco-system).
If there’s the need of having to change it, is either because of some security issues, at which point the whole ecosystem might have been jeopardized, or we are planning some changes that likely are going to be breaking (i.e. moving away from whisper).
, so it might make sense to consider them separately.