BLS Specs rewrite for IETF clarity

[CarlBeek]

This PR is an alternate proposal to @kirk-baird's #1398.

It is based on two ideas:

0. If something is defined in the IETF specs, it should not be redefined in the eth2-specs. This reduces the scope for errors and reflects the workflow of integrating with an IETF spec-compliant BLS implementation.

1. tag replaces domain. Confusion can arise due to the name collision of domain in the eth2 specifications and those of the IETF. tag is an alternative that implies also separation and is unique to the eth2-specs.

PS: The diff appears large here, but most of that is due to tag replacing domain. The substantive changes are (almost entirely) limited to specs/bls_signature.md

[djrtwo]

Awesome! I think this is the way to go.

I made some suggestions, nothing major. then ready to merge

[djrtwo]

Is there no public interface in the BLS standard to aggregate pubkeys?
I can't immediately think of a need to aggregate it independently and have the resulting aggregate pubkey, but interesting none the less.

[CarlBeek]

No there isn't. It is a strange absence.

[djrtwo]

Oh shit, I just noticed the merge conflict here. I'll have a stab at it

[djrtwo]

Merge conflicts resolved

[kirk-baird]

I like the way you've presented it here and I agree that it's much better to not redefine things that are already defined in the IETFs. So I too think this is the way forward, I'm happy to close #1398 when this is merged :)

[JustinDrake]

A few issues (discussed with Carl privately):

1. We need support for uniqueness roots to unify the slashing conditions. See Unified slashing condition for equivocations #1387
2. Application-layer logic specific to Eth2 (namely, the tag as well as the uniqueness root) should not go in the BLS spec. Instead, it should go in the "core" Eth2 spec.
3. We should sign over 32-byte messages (hash outputs) as apposed to appending the tag with + tag. The appendage is adhoc and not future proof (for example, does work well with uniqueness roots). The appendage is also ugly 😂

[djrtwo]

Are you suggesting moving the methods like bls_sign out of the bls spec?
Even if using a wrapper object, I think it makes sense to keep these functions in a separate file (like the bls spec) rather than cramming them in the phase 0 doc.

I think it natural to present the functions from the BLS standards, immediately followed by the set of wrapper functions used explicitly throughout the rest of the spec.

This allows for an auditor to quickly see the BLS standards and how we use them all in one place without having to dig through other docs

[JustinDrake]

Are you suggesting moving the methods like bls_sign out of the bls spec?

Yes, that was the suggestion in terms of presentation :) Notice that without that separation of concerns there would be a somewhat circular definition. For example, as the PR stands, the Eth2 spec uses bls_verify defined in the BLS spec, but bls_verify itself uses hash which is defined in the Eth2 spec. The situation becomes worse with the other application-level details involved in wrapping (namely Container, hash_tree_root, tag). Arguably the BLS spec does not need to import the SSZ spec to know what a Container is.

[JustinDrake]

@CarlBeek: I think we're missing bls_aggregate_pubkeys.

[djrtwo]

closing in favor of #1532