Wednesday, May 31, 2023

Proposal: [Core] The Birth of an Enactment Star

Withdrawn. Failed by Kevan.

Adminned at 01 Jun 2023 16:48:56 UTC

In the Core rule “Proposals”, in the subrule “Resolution of Proposals”, after this text:

the Admin Enacting it shall update the Gamestate and Ruleset,

add this text:

using the gamestate as it was at the timestamp of the enactment (this timestamp being the one recorded when the Admin edited the Proposal blog post to state that the Proposal is enacted),

Before we forget, let’s fix the issue that hung up the end of the previous metadynasty

Comments

Trapdoorspyder: he/him

31-05-2023 21:19:47 UTC

I wasn’t around last dynasty to see what happened but seems fine to me

Chiiika: she/her

31-05-2023 22:40:17 UTC

don’t think it is “starting”, should be something akin to “working”?

JonathanDark: Publisher he/him

31-05-2023 22:41:45 UTC

Or “using”? Let me try that and see how it looks to everyone…

Trapdoorspyder: he/him

01-06-2023 01:38:43 UTC

for

Bucky:

01-06-2023 01:58:22 UTC

This still triggers the “Once a Votable Matter has been enacted, it can have no further direct effect on the gamestate” deadlock.

JonathanDark: Publisher he/him

01-06-2023 02:15:42 UTC

[Bucky] That was already the case, though, wasn’t it? Is your argument that the act of “enacting” includes changing the gamestate?

Kevan: he/him

01-06-2023 08:17:00 UTC

Would be good to get a summary of what this is fixing and how, for the sake of voters who weren’t present at the end of the last dynasty.

Josh: he/they

01-06-2023 08:30:42 UTC

Sure. Basically the resolving proposal of the dynasty required the enacting admin to make a list of citizens based on the population of each city, randomly select one, and the owner of the selected citizen achieved victory. The making of the list wasn’t tracked anywhere so the argument hinged on when making that list took place, which ended up being definitive as the contents of the list would be changed by a dynastic action that took place 5 seconds after the enactment of the proposal. The ruleset currently has ‘resolution’ of a proposal as being the act of marking the proposal as resolved in the admin form; applying its effect is a separate step, non-atomic, so there is an airgap in which things can happen.

This enshrines that enactment affects the ruleset and gamestate as it was at the moment of enactment. It creates some new problems (what happens now if something happens in the airgap?) but I think it’s worth trying out.

lemon: she/her

01-06-2023 08:39:39 UTC

thanks for the summary! i think the added sentence is a bit clunky, but i can see the point of it. for

Kevan: he/him

01-06-2023 09:12:01 UTC

So this is implicitly endorsing the (I think unwritten) idea that the enactment process is “mark proposal as enacted, then apply its proposed changes”, rather than the other way around?

I’ve always done it the other way around so that another admin won’t start enacting the subsequent proposal as “oldest pending” before I’ve finished applying all the effects of the first one.

How does “using the gamestate as it was” actually shake out, if two admins can exploit the post-marked airgap to apply the effect of two adjacent proposals out of order?

Brendan has 5 points; I mark “double Brendan’s points” as enacted; you then mark “Brendan gains +10 points” as enacted; you process the second proposal and set Brendan’s points to 15; I process the first proposal and set Brendan’s points to 10. Brendan’s points should have been 20 as a result of those two proposals, but are… 10?

Josh: he/they

01-06-2023 09:21:19 UTC

The order is actually currently largely written: we have

A votable matter is resolved by an admin setting its status through use of the “status” field in the blog post editing form

And then

When a Proposal is Enacted, its stated effects are immediately applied in full

Which at the very least implies a strong causality.

You are right that this change leaves potential exploitations in place, and creates new ones.

Kevan: he/him

01-06-2023 09:47:44 UTC

against for creating new exploits, then.

Checking where I might have gotten the process-then-status enactment idea from, the ruleset did previously define enaction as “updating the Ruleset and/or Gamestate to include the specified effects of that Proposal, and then setting that Proposal’s status to Enacted”, until July 2021.

JonathanDark: Publisher he/him

01-06-2023 13:12:22 UTC

[Kevan] Can you explain why the exploit would not be covered under Fair Play?

Kevan: he/him

01-06-2023 13:15:53 UTC

Which part of Fair Play do you mean?

JonathanDark: Publisher he/him

01-06-2023 15:17:23 UTC

A person with administrative, moderation, or other heightened access to the software running or supporting BlogNomic should not take any action using such heightened access for the purpose of causing any Mindjacker or Mindjackers to gain, receive, maintain, or preserve gameplay advantage

In my mind, that should generally prevent the type of exploit described as “if two admins can exploit the post-marked airgap to apply the effect of two adjacent proposals out of order”, shouldn’t it?

Kevan: he/him

01-06-2023 15:26:19 UTC

I don’t think that applies to in-game admin advantage, nor was it intended to, since the rule goes on to say:

...unless any of the following is true:
* Such action is required or explicitly permitted by the rules…

“Administrative” is perhaps an unfortunate choice of word.

Admin advantage is certainly alive and well - Bucky’s “last second growth tick” before enacting a proposal at the end of the last dynasty didn’t appear to get a blink from anyone.

Chiiika: she/her

01-06-2023 16:01:48 UTC

ahh yeah.  against on additional info

Trapdoorspyder: he/him

01-06-2023 16:15:18 UTC

CoV against based on previous discussion

JonathanDark: Publisher he/him

01-06-2023 16:47:46 UTC

against Withdrawn based on a better understanding of the Fair Play rules