Re: DIS: [Proto] Ratification Rewrite
On Sun, Apr 4, 2021 at 3:04 PM Edward Murphy via agora-discussion wrote: > > Aris wrote: > > > Title: Ratification Rewrite > > Adoption index: 3.0 > > Author: Aris > > Co-authors: Jason, G., Murphy > [snip] > > 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. > [snip] > > Amend Rule 2201, "Self-Ratification", by changing it to read in full: > > > >When a public document is defined as self-ratifying by the rules > >remains continuously undoubted for one week, it is ratified > >that the statement became true and correct in all respects > >at its effective date. That should be "document became true and correct". My error. > Apart from R1551 being confusing unless you remember R2201, it may also > be useful to also define "effective date" in the context of a statement > being ratified (e.g. without objection). In particular, if I try to RWO > "Bob had 14 coins at " then that's pretty clear, but if I > try to RWO "Bob has 14 coins", then how should that be interpreted? >a) "Bob had 14 coins when intent was announced" >b) "Bob had 14 coins when resolution was announced" The idea is that the time is resolution by default. I'll think about how to make that more explicit. -Aris
Re: DIS: [Proto] Ratification Rewrite
Aris wrote: Title: Ratification Rewrite Adoption index: 3.0 Author: Aris Co-authors: Jason, G., Murphy [snip] 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. [snip] Amend Rule 2201, "Self-Ratification", by changing it to read in full: When a public document is defined as self-ratifying by the rules remains continuously undoubted for one week, it is ratified that the statement became true and correct in all respects at its effective date. Apart from R1551 being confusing unless you remember R2201, it may also be useful to also define "effective date" in the context of a statement being ratified (e.g. without objection). In particular, if I try to RWO "Bob had 14 coins at " then that's pretty clear, but if I try to RWO "Bob has 14 coins", then how should that be interpreted? a) "Bob had 14 coins when intent was announced" b) "Bob had 14 coins when resolution was announced"
Re: DIS: [Proto] Ratification Rewrite
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
Re: DIS: [Proto] Ratification Rewrite
On Thu, Apr 1, 2021 at 6:14 PM Aris Merchant 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. > [...] > > 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. 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). I'll just add that I'm open to being convinced that something like yours is better. Right now it feels like mine is better, but I'm not as sure of that as I'd like to be. -Aris
Re: DIS: [Proto] Ratification Rewrite
On Sun, Mar 28, 2021 at 1:05 PM Aris Merchant via agora-discussion wrote: > > Wasn't really planning to publish this so soon, as I'm not really done > editing it. On the other hand, Murphy has published eirs, so I'm going > for it. > > -Aris > --- > Title: Ratification Rewrite > Adoption index: 3.0 > Author: Aris > Co-authors: Jason, G. An updated version that removes the confusing special case for ratifying public documents. I also incorporated part of Murphy's proposal (specifically, eir definition of the time of a document's ratification). -Aris --- Title: Ratification Rewrite Adoption index: 3.0 Author: Aris Co-authors: Jason, G., Murphy [Let's face it, the ratification rules are a mess. They're nearly unreadable, full of complicated technical language that is painfully hard to understand. While they deal with an inherently complex problem, that doesn't mean they need to be impossible to read themselves. A while back people suggested some rewrites that came at the problem from different angles, but all of them had their own problems. This proposal maintains the same basic conceptual approach as the current rules, but rewrites the text to make it more readable and adjusts the complex to simplify them. I hope this will lead to cleaner results than we have at present.] 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 was published, unless the document explicitly specifies a different past time as the time it was true, in which case its effective date is that past time. 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. A statement CANNOT be ratified if: 1. it is internally inconsistent; 2. it describes a state of affairs that is impossible for reasons outside its scope; 3. its ratification would make the state of the game indeterminate or inconsistent with the rules. The ratification of a statement does not change the rules, unless the statement (or a public document that it references) explicitly and unambiguously recites either the changes to them or their final properties. Text purportedly about previous instances of ratification is excluded from ratification. Ratification is secured at power 3. Amend Rule 2202, "Ratification Without Objection", by changing it to read in full: A player CAN, without objection, ratify a specified statement. Ratification without objection CANNOT cause rule changes, rules to the contrary notwithstanding. A player SHALL NOT ratify or announce intent to ratify a statement without objection if e knows it is incorrect or indeterminate, unless the general nature of the statement's error and reason for ratifying it is plainly described in the announcement of intent. Doing so is the Class 8 Crime of Endorsing Forgery. Amend Rule 2201, "Self-Ratification", by changing it to read in full: When a public document is defined as self-ratifying by the rules remains continuously undoubted for one week, it is ratified that the statement became true and correct in all respects at its effective date. Any person CAN by announcement submit a claim of error, identifying a document (perhaps implicitly) and explaining the nature of a perceived error in it. For so long as a claim exists against the document, it is doubted. When this happens, the publisher of the original document SHALL (if e was required to publish that document) or SHOULD (otherwise) do one of the following in a timely fashion, in an announcement that clearly cites the claim of error: 1. Deny the claim (causing it to cease to exist). 2. Initiate an inquiry case regarding the truth of the claim (if the subject is actually a matter of law), or cite a relevant existing inquiry case. 3. Publish a revision. If no claim of error is stated, the revision implicitly responds to all claims of error against the document being revised. Amend Rule 107, "Initiating Agoran Decisions", by replacing: A public notice purporting to initiate an Agoran decision is a self-ratifying attestation of the notice's validity. with: A public notice purporting to initiate an Agoran decision contains an implied self-ratifying statement that the notice is valid. Amend Rule 2034, "Vote Protection and Cutoff for Challenges", by replacing: A public message purporting to resolve an Agoran decision is a self-ratifying attestation that with: A public message purporting to resolve an Agoran decision contains an implied self-ratifying statement that
Re: DIS: [Proto] Ratification Rewrite
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. 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).
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...
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. 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? If two rules are conflated
together, which is amended and which is repealed? 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.
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.
Re: DIS: [Proto] Ratification Rewrite
On Sun, Mar 28, 2021 at 01:04:33PM -0700, Aris Merchant via agora-discussion
wrote:
> Wasn't really planning to publish this so soon, as I'm not really done
> editing it. On the other hand, Murphy has published eirs, so I'm going
> for it.
>
> -Aris
> ---
> Title: Ratification Rewrite
> Adoption index: 3.0
> Author: Aris
> Co-authors: Jason, G.
>
>
> [Let's face it, the ratification rules are a mess. They're nearly
> unreadable, full of complicated technical language that is painfully
> hard to understand. While they deal with an inherently complex
> problem, that doesn't mean they need to be impossible to read
> themselves.
>
> A while back people suggested some rewrites that
> came at the problem from different angles, but all of them
> had their own problems. This proposal maintains the
> same basic conceptual approach as the current rules,
> but rewrites the text to make it more readable
> and adjusts the complex to simplify them. I hope this will
> lead to cleaner results than we have at present.]
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".
***
> 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?
--
Falsifian
