LibraryPrivacy2018Design paperCorpus record
Compact Multi-Signatures for Smaller Blockchains
Compact multi-signatures. Dan Boneh, Manu Drijvers and Gregory Neven.
The paper gives a BLS multi-signature that stays compact and blocks the rogue-key attack with a proof of possession of each key.
A reading of the public paper. Not a copy, not a benchmark, and not a claim about any later network.
If a chain aggregates BLS votes, ask where the proof of possession happens. If the answer is nowhere, this paper is the objection.
The five-minute read
The defect
A naive multi-signature either lists every key and every signature, or it can be attacked by a rogue key that cancels someone else's public key.
The proposal
The paper gives a BLS multi-signature that stays compact and blocks the rogue-key attack with a proof of possession of each key.
Aggregation is not the same as a threshold scheme.
A proof of possession is the defence named here.
The bound
This is not MuSig and not FROST. The group is pairing-based.
One action, walked through
- Each signer proves they hold their key.
- Signatures aggregate.
- A verifier checks the set of keys and one signature.
- What is the domain separation string?
The argument, unpacked
What the paper is for
If a chain aggregates BLS votes, ask where the proof of possession happens. If the answer is nowhere, this paper is the objection.
What happened after
Ethereum's later consensus signatures are in this family. The specification, not this paper, sets the domain separation.
What has to be true
- This is not MuSig and not FROST. The group is pairing-based.
- A missing proof of possession reopens the rogue-key attack.
- The paper does not set a validator set.
What happened after the paper
Ethereum's later consensus signatures are in this family. The specification, not this paper, sets the domain separation.
What to check before you use the idea
- Is there a proof of possession?
- What is the domain separation string?
- Is this a multi-signature or a threshold signature?
Terms
- Rogue key
- A key crafted to cancel another signer's key inside an aggregate.
- Proof of possession
- A proof that the registered key has a known secret.
The problem the paper names
A naive multi-signature either lists every key and every signature, or it can be attacked by a rogue key that cancels someone else's public key.
What the design proposes
- Aggregation is not the same as a threshold scheme.
- A proof of possession is the defence named here.
- Verification is one check, which is why the size matters on a chain.
How the mechanism is specified
- Each signer proves they hold their key.
- Signatures aggregate.
- A verifier checks the set of keys and one signature.
What this page does not treat as proven
- This is not MuSig and not FROST. The group is pairing-based.
- A missing proof of possession reopens the rogue-key attack.
- The paper does not set a validator set.
Why a venture studio still reads it
If a chain aggregates BLS votes, ask where the proof of possession happens. If the answer is nowhere, this paper is the objection.
This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.
Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.
