Re: DIS: Proto: Transactions

[Aris Merchant]

On Wed, Feb 28, 2018 at 5:56 PM Gaelan Steele  wrote:

> Title: “Transactions”
> AI: not sure, help?
>
> Create a rule titled “Transactions” [power?] with the following text: {
> A set of actions to be performed is a transaction if it is specified as
> such by a rule with power [?] or greater, or the document or message
> describing the actions. If any action in a transaction would be INEFFECTIVE
> or otherwise not occur, none of the actions in the transaction occur.
>
> Unless otherwise specified by the document or message describing the
> actions, the following sets of actions are considered transactions:
> - The full text of a proposal
> - Two actions in the same document or message where one action would only
> succeed if the other occurred.
> }
>
> [This proposal aims to solve two issues: proposals which leave the game in
> an inconsistent state, and situations where a player spends currency on an
> action they do not realize is ineffective. It solves both, I think, but
> maybe is too far-reaching? I considered making transactions opt-in only,
> but I fear people would forget to use them.
>
> Gaelan]

You've got to realize that in many cases partial failure is preferable. For
instance, after Black Cards were found invalid, the proposal that
introduced them stood. Under this, finding out after months of gameplay
that some part of a major reform failed, we would be left with nothing. I
agree that there are cases where this would be preferable, but I'm not
convinced that they're in the majority, and I think they'd need to be a
supermajority of cases for it to be worthwhile. The most common type of
failure is actually things like repeal or amendment of a repealed rule,
which is in practice usually harmless. No comment on the other case as of
yet.


-Aris

DIS: Proto: Transactions

[Gaelan Steele]

Title: “Transactions”
AI: not sure, help?

Create a rule titled “Transactions” [power?] with the following text: {
A set of actions to be performed is a transaction if it is specified as such by 
a rule with power [?] or greater, or the document or message describing the 
actions. If any action in a transaction would be INEFFECTIVE or otherwise not 
occur, none of the actions in the transaction occur.

Unless otherwise specified by the document or message describing the actions, 
the following sets of actions are considered transactions:
- The full text of a proposal
- Two actions in the same document or message where one action would only 
succeed if the other occurred.
}

[This proposal aims to solve two issues: proposals which leave the game in an 
inconsistent state, and situations where a player spends currency on an action 
they do not realize is ineffective. It solves both, I think, but maybe is too 
far-reaching? I considered making transactions opt-in only, but I fear people 
would forget to use them.

Gaelan]

Re: DIS: Proto: Transactions

[Ian Kelly]

On Dec 30, 2007 6:03 PM, Josiah Worcester [EMAIL PROTECTED] wrote:
 From playing B Nomic, I've seen one potentially useful idea: transactions. I'm
 not sure if everyone wants them, but let's see:

 Proto: Transactions (power=3?)
 Create a rule titled Transactions with the following text:
 A transaction is a method of announcing actions, contained entirely
 within BEGIN TRANSACTION and END TRANSACTION. A transaction may have a
 list of assertions and may have a list of actions. If any assertion made
 within the transaction is not true at the time of the transaction or,
 alternatively, the time specified within the assertion, then none of the
 actions in the transaction take effect. If any action made within the
 transaction fails, then none of the actions in the transaction take effect.

I'm not sure about this.  Well designed transactions could be useful,
but poorly designed transactions could be worse than restricting
atomicity to individual actions (i.e., what we do now).  For example,
consider this hypothetical transaction:

BEGIN TRANSACTION
I register.
I sit up.
END TRANSACTION

If this is accepted for several months, at which point somebody
suddenly notices that the game was in emergency session at the time,
then the transaction is invalidated, the registration is annulled, and
every action performed since that moment by or involving that player
is invalidated as well.

-root

Re: DIS: Proto: Transactions

[Josiah Worcester]

On Monday 31 December 2007 10:40:35 Ian Kelly wrote:
 On Dec 30, 2007 6:03 PM, Josiah Worcester [EMAIL PROTECTED] wrote:
  From playing B Nomic, I've seen one potentially useful idea: transactions. 
I'm
  not sure if everyone wants them, but let's see:
 
  Proto: Transactions (power=3?)
  Create a rule titled Transactions with the following text:
  A transaction is a method of announcing actions, contained entirely
  within BEGIN TRANSACTION and END TRANSACTION. A transaction may have a
  list of assertions and may have a list of actions. If any assertion made
  within the transaction is not true at the time of the transaction or,
  alternatively, the time specified within the assertion, then none of the
  actions in the transaction take effect. If any action made within the
  transaction fails, then none of the actions in the transaction take 
effect.
 
 I'm not sure about this.  Well designed transactions could be useful,
 but poorly designed transactions could be worse than restricting
 atomicity to individual actions (i.e., what we do now).  For example,
 consider this hypothetical transaction:
 
 BEGIN TRANSACTION
 I register.
 I sit up.
 END TRANSACTION
 
 If this is accepted for several months, at which point somebody
 suddenly notices that the game was in emergency session at the time,
 then the transaction is invalidated, the registration is annulled, and
 every action performed since that moment by or involving that player
 is invalidated as well.
 
 -root
 

Perhaps have transactions self-ratify? :p

Re: DIS: Proto: Transactions

[Ian Kelly]

On Dec 31, 2007 10:54 AM, Josiah Worcester [EMAIL PROTECTED] wrote:
 Perhaps have transactions self-ratify? :p

It might be reasonable to have the actions self-ratify, but not the
assertions; it would be too much to force recordkeepors to keep track
of what assertions have been made and what their ratification statuses
are.

The problem then is that if the actions self-ratify, but the
assertions don't, the transactions are no longer atomic.

-root

Re: DIS: Proto: Transactions

[Josiah Worcester]

On Monday 31 December 2007 11:01:33 Ian Kelly wrote:
 On Dec 31, 2007 10:54 AM, Josiah Worcester [EMAIL PROTECTED] wrote:
  Perhaps have transactions self-ratify? :p
 
 It might be reasonable to have the actions self-ratify, but not the
 assertions; it would be too much to force recordkeepors to keep track
 of what assertions have been made and what their ratification statuses
 are.
 
 The problem then is that if the actions self-ratify, but the
 assertions don't, the transactions are no longer atomic.
 
 -root
 

Perhaps: An announcement may be made asserting the success or failure of a 
Transaction. This announcement is self-ratifying.?

Re: DIS: Proto: Transactions

[Ian Kelly]

On Dec 31, 2007 11:04 AM, Josiah Worcester [EMAIL PROTECTED] wrote:
 Perhaps: An announcement may be made asserting the success or failure of a
 Transaction. This announcement is self-ratifying.?

We'd have to remember to make the announcement for each transaction.

-root

Re: DIS: Proto: Transactions

[Josiah Worcester]

On Monday 31 December 2007 11:08:56 Ian Kelly wrote:
 On Dec 31, 2007 11:04 AM, Josiah Worcester [EMAIL PROTECTED] wrote:
  Perhaps: An announcement may be made asserting the success or failure of 
a
  Transaction. This announcement is self-ratifying.?
 
 We'd have to remember to make the announcement for each transaction.
 
 -root
 

Hmm. If the transaction's success or failure can't be readily determined, it 
is said to fail. A successful transaction self-ratifies

Re: DIS: Proto: Transactions

[Ed Murphy]

pikhq wrote:


On Monday 31 December 2007 11:08:56 Ian Kelly wrote:

On Dec 31, 2007 11:04 AM, Josiah Worcester [EMAIL PROTECTED] wrote:
Perhaps: An announcement may be made asserting the success or failure of 

a

Transaction. This announcement is self-ratifying.?

We'd have to remember to make the announcement for each transaction.

-root



Hmm. If the transaction's success or failure can't be readily determined, it 
is said to fail. A successful transaction self-ratifies


The point of ratification is to avoid having to look for errors long
after the fact.  Hence the self-ratification of e.g. any message
purporting to be an official report, which covers cases where the
identity of an officer is in question.

Also, overlooking the failure of an attempted registration during an
Emergency Session could happen just as easily without transactions.

I think manual ratification is sufficient.  However, since determining
which officer(s) are responsible for evaluating the success of a given
transaction is non-trivial, how about:

The Database Administrator (DBA) is a low-priority office.  The DBA's
report includes a list of transactions since the last such report (if
any), their success or failure, and the status of the relevant portion
of the gamestate afterward.

DIS: Proto: Transactions

[Josiah Worcester]

From playing B Nomic, I've seen one potentially useful idea: transactions. I'm 
not sure if everyone wants them, but let's see:

Proto: Transactions (power=3?)
Create a rule titled Transactions with the following text:
A transaction is a method of announcing actions, contained entirely 
within BEGIN TRANSACTION and END TRANSACTION. A transaction may have a 
list of assertions and may have a list of actions. If any assertion made 
within the transaction is not true at the time of the transaction or, 
alternatively, the time specified within the assertion, then none of the 
actions in the transaction take effect. If any action made within the 
transaction fails, then none of the actions in the transaction take effect.

Re: DIS: Proto: Transactions

[Ed Murphy]

pikhq wrote:

From playing B Nomic, I've seen one potentially useful idea: transactions. I'm 
not sure if everyone wants them, but let's see:


Proto: Transactions (power=3?)
Create a rule titled Transactions with the following text:
A transaction is a method of announcing actions, contained entirely 
within BEGIN TRANSACTION and END TRANSACTION. A transaction may have a 
list of assertions and may have a list of actions. If any assertion made 
within the transaction is not true at the time of the transaction or, 
alternatively, the time specified within the assertion, then none of the 
actions in the transaction take effect. If any action made within the 
transaction fails, then none of the actions in the transaction take effect.


You're missing this bit:
  If it cannot be determined with finality and certainty whether or
   not a Transaction Succeeds, then the Transaction Fails.
which avoids paradoxes due to asserting e.g. Goldbach's conjecture.

I would also leave out this bit:
  or, alternatively, the time specified within the assertion
and just have assertions specify time periods directly when needed, e.g.
  X was the Y at some point during November 2007.

Re: DIS: Proto: Transactions

[Josiah Worcester]

On Sunday 30 December 2007 18:29:54 Ed Murphy wrote:
 pikhq wrote:
 
  From playing B Nomic, I've seen one potentially useful idea: transactions. 
I'm 
  not sure if everyone wants them, but let's see:
  
  Proto: Transactions (power=3?)
  Create a rule titled Transactions with the following text:
  A transaction is a method of announcing actions, contained entirely 
  within BEGIN TRANSACTION and END TRANSACTION. A transaction may have a 
  list of assertions and may have a list of actions. If any assertion made 
  within the transaction is not true at the time of the transaction or, 
  alternatively, the time specified within the assertion, then none of the 
  actions in the transaction take effect. If any action made within the 
  transaction fails, then none of the actions in the transaction take 
effect.
 
 You're missing this bit:
If it cannot be determined with finality and certainty whether or
 not a Transaction Succeeds, then the Transaction Fails.
 which avoids paradoxes due to asserting e.g. Goldbach's conjecture.
 
 I would also leave out this bit:
or, alternatively, the time specified within the assertion
 and just have assertions specify time periods directly when needed, e.g.
X was the Y at some point during November 2007.
 

I want to be able to say X was the Y at some point during February 2008. Of 
course, that may just be cause to be lynched, so. . . Probably not a good 
idea. :p

Re: DIS: Proto: Transactions

[ihope]

On Dec 30, 2007 8:03 PM, Josiah Worcester [EMAIL PROTECTED] wrote:
 From playing B Nomic, I've seen one potentially useful idea: transactions. I'm
 not sure if everyone wants them, but let's see:

 Proto: Transactions (power=3?)
 Create a rule titled Transactions with the following text:
 A transaction is a method of announcing actions, contained entirely
 within BEGIN TRANSACTION and END TRANSACTION. A transaction may have a
 list of assertions and may have a list of actions. If any assertion made
 within the transaction is not true at the time of the transaction or,
 alternatively, the time specified within the assertion, then none of the
 actions in the transaction take effect. If any action made within the
 transaction fails, then none of the actions in the transaction take effect.

If I remember correctly, in B Nomic, the assertions are allowed to be
mixed in with the actions, so that you can make an assertion as to the
results of an action. It MIGHT be better to make asserting by itself
an action, though really, assertion is only useful in a transaction
and can easily be simulated by a transaction containing only the
assertion.

Also, I suggest that instead of saying that a transaction fails if it
can't be determined whether or not it succeeds, which is kind of
self-contradictory, the rule should say that a transaction fails if it
can't be determined whether one of the individual actions or
assertions succeeds. That still avoids the I vote for this if and
only if P = NP stuff but doesn't have the paradoxes.

--Ivan Hope CXXVII