From 8e8e24f450aefff0565965e21fafc774abf87b8b Mon Sep 17 00:00:00 2001 From: William Banfield <4561443+williambanfield@users.noreply.github.com> Date: Mon, 18 Apr 2022 11:51:46 -0400 Subject: [PATCH] Update docs/rfc/rfc-018-bls-agg-exploration.md Co-authored-by: M. J. Fromberger --- docs/rfc/rfc-018-bls-agg-exploration.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/rfc/rfc-018-bls-agg-exploration.md b/docs/rfc/rfc-018-bls-agg-exploration.md index 4513fc516..8149ee9a5 100644 --- a/docs/rfc/rfc-018-bls-agg-exploration.md +++ b/docs/rfc/rfc-018-bls-agg-exploration.md @@ -207,11 +207,11 @@ instead of the full list of multi-signatures as we have them now. #### Heterogeneous key types cannot be aggregated -Only one type of signature can be aggregated and our legacy signing schemes -cannot be aggregated. In practice, this means that aggregated signatures can -be created over the set of all validators that use BLS signatures and validators -with alternative key types, such as Ed25519 must be included separately in -blocks and votes. +Aggregation requires a specific signature algorithm, and our legacy signing schemes +cannot be aggregated. In practice, this means that aggregated signatures could +be created for a subset of validators using BLS signatures, and validators +with other key types (such as Ed25519) would still have to be be separately +propagated in blocks and votes. #### Many HSMs do not support aggregated signatures