search

cfrg / draft-irtf-cfrg-bls-signature

32 stars 16 forks source link

Minor cleanups #5

Closed JustinDrake closed 5 years ago

zhenfeizhang commented 5 years ago

Thanks for the pull request!

The change from "aggregated" to "compressed" was a result of the discussion over the CFRG forum, with a purpose to make the draft more developer-friendly. Please see this email.

That said, we are not sure about the best terminology here. For now we are keeping this PR (and the discussion) open, until everyone agrees on the terminology.

JustinDrake commented 5 years ago

The change from "aggregated" to "compressed" was a result of the discussion over the CFRG forum

Ok. Feel free to cherry pick the other fixes if they are valuable :)

protolambda commented 5 years ago

The use of "compressed" is much worse in my opinion, for three reasons:

  1. There is no mention of it being a lossy compression. And it does not fit the standard "all information is stored" meaning either. There is no defined way of retrieving back the inputs. And repeated compression is very different too: there is no side-effect as with other lossy compression.
  2. There is no "de-compression" anywhere in this context, it is always just the effective use on the output that works the same. And which has its own edge-cases. E.g. different messages not being compressed together in the same way.
  3. We already use "compression" to describe the process of formatting a signature in a minimal serialized form.

"aggregation" however fits all of this:

  1. Repeated aggregation is logically the same as one full aggregation. There is no concern about loss in quality, it literally describes a reduction of elements into a single thing.
  2. Un-aggregation is not something you first consider in the same way you would with de-compression. And aggregation implies more so that the type of input is the same. E.g. it is common to refer to something as a <type> aggregation.
  3. The existing "compression" use is preserved, and this is a 2 way thing, unlike the aggregation process here.
kwantam commented 5 years ago

I agree with @protolambda and @JustinDrake that use of the word "aggregate" in place of "compress" is more precise and thus better. Clearly defining the term "aggregate", and perhaps giving some high-level intuition in the intro, should suffice to take care of the comment from the CFRG mailing list, no?

(If we decide to add some intuition early in the document, probably we can make a new issue to track that decision and handle it as a separate PR.)

zhenfeizhang commented 5 years ago

Let's merge this pull request for now. See #7 for further discussions.