Proof of Possession and BLSVerify clarification

[mratsim]

#17 added the add_validator routine and the first use of bls_proof_of_possession mentioned in at the beginning of the spec: PoW Main changes.

As mentionned on Gitter, either sorting the validator keys or using the bls_proof_of_possession are necessary to avoid rogue public keys attack where an attacker can claim that both he and Bob have signed the message but only Bob did.

Now regarding this part I'd like to confirm the following 2 things:

def add_validator(pubkey, proof_of_possession, withdrawal_shard,
                  withdrawal_address, randao_commitment, current_dynasty):
    # if following assert fails, validator induction failed
    # move on to next validator registration log
    assert BLSVerify(pub=pubkey,
                     msg=sha3(pubkey),
                     sig=proof_of_possession)
    ...

1. Is sha3 the usual keccak256?

2. Is BLSVerify standard ECDSA verify but with BLS curve?

   In Milagro that would be the following:

   /**	@brief ECDSA Signature Verification
   *
     IEEE-1363 ECDSA Signature Verification
     @param h is the hash type
     @param W the input public key
     @param M the input message
     @param c component of the input signature
     @param d component of the input signature
     @return 0 or an error code
   */
   extern int ECP_ZZZ_VP_DSA(int h,octet *W,octet *M,octet *c,octet *d);

   and if we take secp256k1

   /** Verify an ECDSA signature.
   *
   *  Returns: 1: correct signature
   *           0: incorrect or unparseable signature
   *  Args:    ctx:       a secp256k1 context object, initialized for verification.
   *  In:      sig:       the signature being verified (cannot be NULL)
   *           msg32:     the 32-byte message hash being verified (cannot be NULL)
   *           pubkey:    pointer to an initialized public key to verify with (cannot be NULL)
   *
   * To avoid accepting malleable signatures, only ECDSA signatures in lower-S
   * form are accepted.
   *
   * If you need to accept ECDSA signatures from sources that do not obey this
   * rule, apply secp256k1_ecdsa_signature_normalize to the signature prior to
   * validation, but be aware that doing so results in malleable signatures.
   *
   * For details, see the comments for that function.
   */
   SECP256K1_API SECP256K1_WARN_UNUSED_RESULT int secp256k1_ecdsa_verify(
       const secp256k1_context* ctx,
       const secp256k1_ecdsa_signature *sig,
       const unsigned char *msg32,
       const secp256k1_pubkey *pubkey
   ) SECP256K1_ARG_NONNULL(1) SECP256K1_ARG_NONNULL(2) SECP256K1_ARG_NONNULL(3) SECP256K1_ARG_NONNULL(4);

[djrtwo]

Although Vitalik just updated it with hash, I think we will at this point in time define it as hash2, where hash != hash2 and reference keccak256 in the appendix as the likely hash2

[djrtwo]

For (2), I think we do a bls.sign and bls.verify but with bls.hash_to_G2 utilizing the alternate hash.

Getting some clarity on this now

[vbuterin]

Aaah yes you're right, though hash_to_G2 is included in the BLS signing definition already (at least de facto) so there's no need to put it in this part of the spec. For the hash used inside of hash_to_G2, so far I'd say blake2(x)[32:] (ie. the other half of blake2) seems most sensible.

[paulhauner]

It's worth noting that the G1::mapit(h) (map to G1) function in Rust Milagro panics if you supply it < 48 bytes.

We might need to give the function 48 bytes, or specify some padding scheme. I don't understand the full implications of reducing the input space of the map so I can't provide input there.

The beacon_chain impl (and comments in this post) talk about hashing to G2, but from what I can see in the 2003 BLS paper, the message hash should be mapped to G1. Once again, don't have the understanding to make any firm statement on that.

[djrtwo]

This is noted in the spec as a to-do "Use a separate hash function for the proof of possession"

Closing this issue for now