Expand description
§Aggregation of BLS signatures using proofs-of-possession
In this module, we provide the linear flavor of aggregate BLS signature in which the verifiers has previously checked proofs-of-possession for all public keys. In other words, we simply add up the signatures because the previously checked proofs-of-possession for all signers prevent rogue key attacks. See the security arguments in The Power of Proofs-of-Possession: Securing Multiparty Signatures against Rogue-Key Attacks by Thomas Ristenpart and Scott Yilek at https://eprint.iacr.org/2007/264.pdf
These proof-of-possession are simply self-signed certificates, so a BLS signature by each secret key on its own public key. Importantly, the message for this self-signed certificates must uniquely distinguish the public key for which the signature establishes a proof-of-possession. It follows that each proof-of-possession has a unique message, so distinct message aggregation is optimal for verifying them.
In this vein, we note that aggregation under proofs-of-possession cannot improve performance when signers sign distinct messages, so proofs-of-possession help with aggregating votes in a concensus protocol, but should never be used for accounts on a block chain.
We assume here that users provide their own data structure for
proofs-of-poossession. We provide more structure for users who
one bit per vote in a concensus protocol:
You first verify the proofs-of-possession when building a data
structure that holds the voters’ keys. You implement the
ProofsOfPossession trait for this data strtcuture as well,
so that the BitPoPSignedMessage type provides a signature
data type with reasonable sanity checks.
Structs§
- ProofOfPossion trait which should be implemented by secret