Does anyone disagree with the following? - 8713 will not be updated in time to take effect for this NomCom's selection process. - The text of 8713 specifies a process that, if followed, means a delay of at least one week, and perhaps at least two weeks. "Picking next one the list" is the process recommended by at least the last half-dozen NomCom chairs, and followed by at least one of them (me); perhaps more than one. Yes, this can be gamed. So what; security is about trade-offs and saving time is more important for now. Some folks might want to review the errata at https://www.rfc-editor.org/errata/rfc8713. I have no idea where discussions of that should happen. It wasn't clear to me if Rob was proposing an interpretation of 8713, or providing input to a revision. I had to disqualify one potential volunteer. They said yes, and then I was unable to interact with them for the next three days (it was the weekend). One day is not enough. And weekends aren't the same globally, once you allow for timezones or countries that observe the classic Sabbath.
I actually disagree.
4.16 requires that you announce the list and the selection method
ahead of time. It does not require that for each and every
iteration except that "The method must depend on random data whose
value is not known or available until the date on which the random
selection will occur.".
The phrase that you might be giving more weight to that necessary
is "The announcement should be made at least one week prior to the
date on which the random selection will occur." - note the
"should" vs a must. In any event, you could consider that a
requirement for the initial roll, but as long as you meet the
requirement that the random data is unknown in advance you could
announce a re-roll to occur in a half hour, as long as the
announcement makes it to the list prior to the roll. See below
for an example.
Requiring a re-roll is necessary in certain circumstances: "A
method is unbiased if no one can influence its outcome in favor of
a specific outcome." I think that applies in all circumstances if
someone needs to be replaced because the outcome of the
replacement can be predicted.
Example using the league of randomness. I'm proposing to use
round 2909292 of the first chain (8990...b2ce) as the randomness
for a future roll.
>>>
| 0 | "8990e7a9aaed2ffed73dbd7092123d6f289930540d7651336225dc172e51b2ce" |
| 1 | "dbd506d6ef76e5f386f41c651dcb808c5bcbd75471cc4eafa3f4df7ad4e4c493" |
https://api3.drand.sh/8990e7a9aaed2ffed73dbd7092123d6f289930540d7651336225dc172e51b2ce/info
>>>
| public_key | "868f005eb8e6e4ca0a47c8a77ceaa5309a47978a7c71bc5cce96366b5d7a569937c529eeda66c7293784a9402801af31" |
| period | 30 --- 2 rounds per minute |
| genesis_time | 1595431050 |
| hash | "8990e7a9aaed2ffed73dbd7092123d6f289930540d7651336225dc172e51b2ce" |
| groupHash | "176f93498eac9ca337150b46d21dd58673ea4e3581185f869672e59fa4cb390a" |
| schemeID | "pedersen-bls-chained" |
| metadata | |
| beaconID | "default" |
>>> Current round
https://api3.drand.sh/8990e7a9aaed2ffed73dbd7092123d6f289930540d7651336225dc172e51b2ce/public/latest
| round | 2909232 |
| randomness | "1303dd35336091d56d95dff1c21acb11a25a4c1be66593dd8392a147a19ea231" |
| signature | "b80ebdab37f95217694beb2d45b172f003f66bf027556b8ff09dc5faff68715727dfa12364d9e912366a95ceb8b2ab01161ebbf93f59631a4be3c17193e1012a4e15d704eda2ab37dd28947b8036ec9a9e9ae21d08ded75e1cb3fe168e85b465" |
| previous_signature | "99b23a8e422dbaab411db82b18cd23ffaa944c6a76d5792e09367505c2f763b9570e15ecb0248ae751bb87539823a863108f8fa30538fef397b753131d3b87e465d621d1f5dc1324791a565ce55d1ae0a4e6c0180b33c483449715b17548e8fd" |
Current round was at (2909232 * 30) + 1595431050 -> 1,682,708,010 Fri Apr 28 2023 14:53:30 GMT-0400 (Eastern Daylight Time)
>>> Target round (30 minutes) = 60 + 2909232 => 2909292
Not available as of the time I'm writing this note - server appears to wait until it is.
Mike
