Threshold Key Derivation - Privacy on the IC

Roadmap
,
207

Thanks @andrea, I have a few questions before voting if that’s okay. My understanding is that 2fq7c is currently the backup test key subnet (whereas it used to be the signing subnet, prior to 131449). In prior test key deployments the procedure has been to:

  • Generate the test key on the signing subnet
  • Enable the key afterwards
  • Reshare the key to the backup subnet (using a set of halt, apply CUP, unhalt proposals)

In this case it seems the approach planned is to:

  • Generate the test key on the backup subnet
  • Reshare the key with the signing subnet (using a set of halt, apply CUP, unhalt proposals)
  • Enable the key afterwards (on the signing subnet? Is there a plan to enable and test it on the backup subnet too?)

Have I understood this more or less correctly? If so would you be able to elaborate on the choice to deviate from previous procedure (including resharing to the signing subnet, instead of to the backup subnet, despite the downtime implications).

I’m also curious about a couple of the parameters.

"max_queue_size": 10,
"pre_signatures_to_create_in_advance": 0
  • max_queue_size is 20 for the other 3 keys, on both the signing and the backup subnet. Could I ask what the reasoning is for setting it to 10 in this case?
  • pre_signatures_to_create_in_advance is set to 1 for the other 3 keys on this backup subnet (and 7 on the signing subnet). Can I ask why it’s being initialised with 0 here?

Thanks in advance :slightly_smiling_face:

3 Likes