On Thu, Apr 01, 2021 at 06:14:51PM -0700, Aris Merchant via agora-discussion
wrote:
> This reply is likely longer and more rambly than it needs to be. For
> that, I apologize in advance.
>
> > I'm tempted to bring out my "self-ratifying events" proto again. Were
> > there any particular objections you had?
> >
> > It wasn't complete, but it is possible to implement in stages.
> >
> > Its benefit is to get rid of the "minimally modified" language. It
> > keeps the (arguably confusing) "what it would be if, ..." part, but I'm
> > not sure it makes sense to get rid of that --- see my criticism below
> > of your proto.
> >
> > ***
> > Summary of self-ratifying events: instead of ratifying "{ At time T,
> > Falsifian has 10 Coins }", you ratify an event: "{ At time T, the Coin
> > balance of Falsifian was set to 10 }".
> >
> > If we found we still needed old-style ratification for some reason, we
> > could invoke it explicitly: ratify that "{ At time T, the gamestate is
> > minimally modified so that ... }".
> >
> > To ratify a ruleset, we could explicitly say something like: "at time
> > T, the all rules are simultaneously amended, repealed or (re-)enacted
> > to match what's listed in this document". This might make it easier to
> > reason about whether, for example, the revision numbers changed. The
> > event we ratified in this example doesn't say anything about revision
> > numbers, so we are free to conclude that the revision numbers were
> > affected in the natural way by any changes to rule text. That's a
> > benefit to saying precisely what happens, rather than vaguely saying
> > "this becomes true".
> > ***
>
> I disagreed with your design. The problem wasn't a fundamental
> breakage, but I'm not convinced it works well for modifications beyond
> simple state modifications.
Overall comments:
* I'm not really sure my design would be an improvement. You do raise
some good points! I think I have reasonable counter-arguments to
them, included below, but I'm by no means convinced we should hop
right over to my system.
* I want to make sure I understand the reason behind your proto. Is it
that you think people find the current language of R1551 confusing?
I think R1551 is cool (although I do like complaining about the
"minimally modified" concept). Maybe it is confusing, but I wonder if
rephrasing it would partly solve that? E.g. Murphy's proto would
improve it a bit.
> Take for instance Rule 2034, "Vote
> Protection and Cutoff for Challenges". It describes at length a series
> of properties about the Agoran decision that we want to ratify. If I
> recall correctly, your solution was to ratify into existence a
> decision that did have the correct properties. I don't really think
> that's what we want. It leaves around another decision that could
> potentially be resolved at some point that does something we don't
> want. If we create a matcher that instead modifies a similar decision
> to have the stated properties, we either have to specify how the match
> is determined (adding to rules bloat) or leave it vague (losing the
> benefit of the specificity your architecture was supposed to give us).
Having just found my draft text, it doesn't look like a big problem to
me. I guess there's a notion of "matching" implicit in my proto, just
in the sense that it's written assuming it's clear "which" decision is
being referred to. But is that "matching" any different in nature from
determining which decision(s) the Assessor is resolving when e
publishes one of eir resolution messages?
The bit about quorum could probably be made more precise.
> More generally, I think moving the specification of what's supposed to
> happen to the rule providing for the application of ratification was a
> mistake. There are a few reasons for this:
>
> 1. It removes the ability to make anything self-ratifying easily.
> Instead, one has to specify an algorithm for each new type of
> ratification. This makes it more work to add new ratification rules to
> the ruleset. One might argue that this is justified by the additional
> specificity your model introduces. However...
I don't think it's complicated, except maybe for ratifying decisions
into existence.
> 2. The added specificity isn't actually all that helpful.
> 2a. It introduces another point of potential breakage. Let's take your
> example: "at time T, all rules are simultaneously amended, repealed or
> (re-)enacted to match what's listed in this document". You forgot to
> list retitling and changing power.
I did, but at least the effect is easy to determine now that you've
noticed it: clearly, the power and titles of the rules were not
changed.
Compare that to a situation where it's unclear what the minimal
modification is, or whether "multiple substantially distinct possible
modifications would be equally appropriate".
> Now, I'm aware that this is an off
> the cuff example, and that we'd be more careful when designing the
> actual text. That being said, it's still likely we would sometimes
> fail to specify the changes we want, or that the changes we define
> would fail to match reality.
> 2b. You've only fixed a subset of ambiguities. For instance, if a
> rule's revision number is higher in the ruleset than reality, this
> would arguably introduce some amendments to the rule to knock its real
> revision number up to the value stated in the ruleset? If the revision
> number is lower, does the ratification fail entirely because the rules
> can't be changed to the desired state?
I deliberately left revision numbers out in this example. I would
expect the revision number to change if the text changed.
I suppose we would want to control the revision numbers. In that case,
the event could be rephrased to explicitly say what happens to them.
> If two rules are conflated
> together, which is amended and which is repealed?
That could only happen if ID numbers get messed up, right? How often
does that happen?
And even if it does --- is the situation going to be any worse than (a)
the current "minimally modified" lanugage or (b) your approach, which I
think is to say even less?
I am not sure, but I think all that would happen is that we would take
it as given that *somehow* the rule texts were modified to make it so
that rules with the appropriate ID numbers and texts exist to make the
document true.
> The problem stems
> from the inexactness of your phrasing. "Make changes X, Y, and Z so as
> to accomplish A" admittedly makes sure that you don't end up with
> changes not on that list, but how often is that actually the source of
> our ratification problems? The ambiguities usually come from other
> directions.
In the most recent case, the ambiguity was that it was unclear whether
or not the ratification included the revision numbers, because (at
least in my mind) it was unclear whether the revision numbers should
follow what's in the document (so it becomes "more true") or whether
they should behave like revision numbers (I dunno, to be more
consistent with the rules?).
I think it's easier to reason about if you explicitly list the changes.
The cost is, as you point out, that you might end up with the wrong
changes.
> 2c. Even in the situations where your example does adequately specify
> a change, I'm not sure the change would be different from the one we
> arrived at otherwise. If a rule has different text in the ruleset then
> in reality, what change would one apply other than amending the rule
> to match the desired state?
>
> You way feel that I'm being ridiculously hard on your example. Truth
> be told, I'd actually agree with you. I have picked on every single
> point I can think of. The thing I'm pointing to though, is that I'm
> not sure specifying the changes to be applied is actually helpful in
> the general case. I think it moves us further from the intuitive goal
> of the system, thus introducing more opportunities for problems. To
> explain why, let me look at this problem from another angle.
>
> What is ratification meant to do?
>
> Ratification is, as we describe it to new players, a way of dealing
> with the inevitable errors that accumulate over time. If an error
> isn't caught for long enough, we pretend that the version we thought
> was true was true.
>
> In my mind, the goal of our ratification rules should be to encode our
> intuitions about how ratification is supposed to work. This has
> several advantages. On the one hand, it will make the ratification
> rules easy to read, because their implementation will match their
> intuitive description. On the other hand, it will reduce bugs, because
> the rule text will encode the behavior we want in plain terms,
> allowing the judiciary to use common sense to apply that behavior to
> reality.
>
> Your model unquestionably improves on the mess we currently have.
> However, it fails to describe the intuitive behavior of ratification.
> Intuitively, ratification is a retroactive action; it is us pretending
> that the past is something that it wasn't. My implementation is
> intended to codify this.
>
> The biggest weakness of my model is that it doesn't codify how the
> gamestate is changed. Generally, we don't care, but there are cases
> where the rules depend on how things became the way they are now. I'm
> not sure how to address this weakness. Maybe I need some extra text
> clarifying how those changes are considered to have been applied, or
> maybe it doesn't matter very much usually and we can just special case
> the cases where it does. But, despite this difficulty, I still believe
> that making the ratification match up with the way we intuitively
> perceive it is a good thing.
This weakness does make me nervous.
Suppose on April 3, 2021 at 00:00 UTC, I had 5 Coins, and then later we
ratify:
{ On April 3, 2021 at 00:00 UTC, Falsifian owned exactly 10 Coins. }
And for simplicity suppose I didn't gain or lose any since then.
What's supposed to happen is that now I have 10 Coins, because now I
had 10 Coins on April 3 and I haven't gained or lost any since then.
But is that really what happens? That paints a strange picture: it
means that for some unexplained reason, my coin balance suddenly
shifted from 5 to 10 on April 3.
Here's an alternative, which in my mind is about equally strange: for a
brief instant at 00:00 UTC, my Coin balance was 10 for some unexplained
reason, just to make the document true. But besides that brief
disturbance, my Coin balance was and remains the true 5 Coin amount.
I expect that in practice, a reasonable judge would make sure things
work the way we want them to. But it feels fragile to me.
To be fair, I have similar complaints about the current "minimally
modified" lanugage; see CFJ 3788 (which had a reasonable judge, and so
worked out the way we wanted, but still leaves me nervous about the
whole thing). I'm not sure right now whether I like yours better than
the status quo or not.
> As an aside, I think my system includes yours, the same way you point
> out that your system includes mine. All we'd have to do in my system
> to get the results your system does is to ratify a statement like
> "Change X was applied at time Y." The difference is that mine doesn't
> make that model the default. I believe that most of the time it's not
> what we want, and forcing people to specify how the changes are
> applied will cause more problems than it solves (see the above). On
> the other hand, if there are specific instances we decide that
> behavior is best in, we can still encode that in my system.
Yes, I think I agree it's a matter of defaults. I guess under your
proto if the statement { On April 3, 2021 at 00:00 UTC, Falsifian's
Coin balance was set to 10. } were ratified, I guess it would be
reasonable to assume that stuck.
To me, "make this document true [somehow]" or "(at a past time)
minimally modify the gamestate to make this document true" seems like a
powerful and dangerous magic whose use should be discouraged. I'd like
to make it harder to do, so that laziness will push people toward
ratifying things that are less ambiguous.
> > > Enact a new power 3.0 rule entitled "Documents", with the
> > > following text:
> > >
> > > A document is a body of text. A public document is a document that
> > > is part (possibly all) of a public message.
> > >
> > > A public document's effective date is the time it states, or otherwise
> > > the time of its publication.
> > >
> > > Amend Rule 1551, "Ratification", by changing it to read as follows:
> > >
> > > When a statement is ratified, play proceeds as if the statement has
> > > become true, and the state of the game is updated accordingly.
> >
> > I don't think this deals with dates properly. Consider this timeline:
> >
> > - At time T1 I publish this document: { Falsifian has 10 Coins }, and
> > announce intent to ratify it without objection.
> >
> > - At time T2 I ratify it without objection.
> >
> > So, play proceeds as if { Falsifian has 10 Coins } is now true? Doesn't
> > that mean my Coin balance is reset to 10, regardless of what happened
> > between T1 and T2?
> >
> > That's not what we want, especially if { Falsifian has 10 Coins } is
> > part of the Treasuror's self-ratifying weekly report, causing my Coin
> > balance to reset to 10 seven days after publication.
> >
> > Did I miss something?
>
> You did!
>
> I moved the place where this is handled to the statement layer. The
> statement you would ratify at T2 would be "The document X became true
> and correct in all respects at its effective date." Ratifying a
> document is shorthand for that statement (it's in my version of Rule
> 1551).
Oops, I stand corrected. Sorry about that!
> The advantage here is that I've removed all hypotheticals from the
> ratification rule. Instead, the hypothetical is implied. What we're
> doing is pretending that a statement is true. If it's a statement
> about the past, we pretend the past was the way the statement
> described. No nested virtual realities needed.
Yes, makes sense.
> Incidentally, I'm still not entirely sure whether or not defining the
> shorthand is helpful or not. It risks getting people too used to
> relying on it rather than saying what they want. I'm open to
> suggestions for making things clearer.
>
> -Aris
Practically, I'd expect people to forget the date sometimes. How about
either (a) make RWO default to the publication date, or (b) say RWO
fails if a date isn't explicitly specified?
--
Falsifian
