It seems as if the concerns about added delay could indeed be eliminated for all practical purposes if we could find a random source that publishes future randomn numbers in short intervals (hourly ?!) - and keeps them published for a sufficient long period for verification. I am not so sure that i would want to trust the independent randomness of some strage URL like https://api3.drand.sh though. Aka: It would also be lovely to pick a random source that we all feel is likely to be around for some decades unchanged. Cheers Toerless On Fri, Apr 28, 2023 at 03:06:13PM -0400, Michael StJohns wrote: > On 4/26/2023 1:49 PM, Salz, Rich wrote: > > 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 athttps://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. > > > https://api3.drand.sh/chains > > >>> > > 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 > > https://api3.drand.sh/8990e7a9aaed2ffed73dbd7092123d6f289930540d7651336225dc172e51b2ce/public/2909292 > > Not available as of the time I'm writing this note - server appears to wait > until it is. > > Mike > > > > -- --- tte@xxxxxxxxx
