Some comments on BIP text

[pool2win]

Thanks for all the nice work you are putting into this.

Here are some comments I have after reading through the spec. Some
might seem as nits, but I am erring on the side of sharing more than
less.

I have not read through the code, so some questions might be answered
there. However, I hope these comments are helpful.

1. Lack of robustness will be a problem for online services that need
   to make progress in the face of benign or byzantine failures of
   some of the nodes. Services face production issues and online
   services will want to continue making progress. The lack of
   robustness is understandable from a custody wallet perspective, and
   chilldkg suits those use cases really well.

2. a BIP340 Schnorr signature pop on message i with secret key
   a_i[0] to the coordinator.

   Here message i was confusing. I had to stare at it for a while to
   figure out that you mean a message with only the identifier i as
   the content. Just a nit, but might help to restate it.

3. The encryption relies on ephemeral-static ECDH key exchange...

   Is this Noise_KX? If so, might help to highlight it as a footnote
   to make it easier to digest. If it isn't, then I misunderstood this
   and maybe we can add how this is different from Noise_KX.

4. EncPedPop appends to the transcript eq_input of SimplPedPop

   I imagine you mean the entire log of messages received and sent -
   excluding the private messages? Or with cipher text of the secret
   messages sent?

   It is not clear from the BIP text what is the transcript that
   CertEq reaches agreement on.

5. I like the simplicity of CertEq. It seems like it can finish in a
   single round. Is that so?

[jonasnick]

Hi @pool2win. Thanks for your comments and sorry for the late reply.

Lack of robustness will be a problem for online services that need to make progress in the face of benign or byzantine failures of some of the nodes.

In our thinking, if ChillDKG fails to succeed, someone is misbehaving and then you already know that you shouldn't send money to that group of signers. We've just added "identifiable aborts" which, in case of failure, allows determining that either a specific participant i misbehaved or the coordinator misbehaved.

Here message i was confusing.

Changed to message "i". Hope that's more clear.

Is this Noise_KX?

I don't think so.

I imagine you mean the entire log of messages received and sent - excluding the private messages?

No. Some messages in the transcript that are unnecessary for eq_input are excluded. And additionally some transcript messages have been agregated by the coordinator. I agree that calling eq_input "the transcript" is confusing.

It is not clear from the BIP text what is the transcript that CertEq reaches agreement on.

Hm, I think the best place to obtain that information the is the actual python spec.

It seems like it can finish in a single round. Is that so?

I don't see how that would work.

[real-or-random]

4. It is not clear from the BIP text what is the transcript that
CertEq reaches agreement on.

The text says:

The transcript of SimplPedPop, constructed in a variable eq_input, is simply the concatenation (of serializations) of t and the sum_coms vector.

and

EncPedPop appends to the transcript eq_input of SimplPedPop the n public encryption nonces, and also all the n static encryption keys to ensure that the participants agree on their identities.

and

ChillDKG constructs a transcript eq_input by appending to the transcript of EncPedPop the vector enc_secshare.

What remains unclear?