* Update bls_signature_scheme.md with BLS12-381-reversed
* Update DIP3/DIP4 to use BLS operator keys
* Update DIP5 to use BLS keys for user keys
Also add the "Size" column to all serialization specs to align with other DIPs.
* Update BLS primitives serialization size in DIP6/7
* DIP3 - Correct PubKeyOperator type
* DIP4 - Correct PubKeyOperator type
* Remove trailing e from integere
I propose to change DIP3 in a way that splits funds handling and DMN registration.
Pros:
1. no need to move collaterals;
2. no need to update HW wallet firmware to support.
Cons:
1. the logic is going to be slightly more complicated;
2. the process of MN registration is going to be split between using HW wallet and Core;
3. `ProRegTx` payload size is going to be slightly higher (+32 bytes).
This change proposes to remove non-alphanumeric characters for the first mainnet release of DIP 0005 Blockchain Users, with the option to add them in later.
The reasoning is based on securing future compatibility when integrating with global name based systems outside of the Dash protocol:
- Periods (.) are compatible with email but will complicate DNS records using BU names, for example user evan.duffield.xyz.tld requires 2 subdomains for a single BU, whereas evanduffield.xyz.tld requires 1 subdomain per BU
- Underscores (_) are not compatible with DNS. They could be translated to hyphens (-) but this would complicate the implementation and is not a clean solution
- We could implement hyphens (-) but this would break email compatibility
- Adding these non-alphanumeric characters at mainnet release is making assumptions for the benefit of aesthetics (more choice of characters for users) - but I do not believe this outways the benefits to securing future compatibility with global name based systems we probably want to integrate with in future
- It is a lot easier to not launch with these special characters and play safe, and add them in later (via HF) if required. Obviously, BU names are digital assets with a value themselves, so we cannot remove characters later (which would invalidate existing names and essentially seize/liquidate that property)
These fields are used in the pre-publish state, but are redundant for published
DIPs which have already been assigned a DIP number. As an example, DIP1 does
not have this field.