This is, for the record, exactly the scam that prompted me to make my recent proposal regarding Messy Statements. I believe that under the current version, it's impossible to get a win with a scam like this that relies on infinite recursion.
However, I believe you messed it up anyway, first because cashing conditions are required to be "true and determinate", so the scam cannot be exploited with cashing conditions, and second because your condition is not actually paradoxical. A promise cannot be cashed directly from the Tree, so the condition is equivalent to "false", so the promise cannot be cashed or transferred. The fact that the condition is true at a time when it cannot be cashed anyway is irrelevant. Sent from my iPhone On May 19, 2013, at 4:16 PM, Kerim Aydin <[email protected]> wrote: > > > [My apologies if this was done before and I missed it!] > > > I submit the following Promise, 'DOA', to the Tree: > > Text: Hello, World. > Conditions for Cashing: There is a copy (i.e. fungible instance) > of this Promise in possession of the tree. > > > I CFJ on: Wes CAN transfer the DOA promise to emself. > > Arguments: > Rule 2338 reads "If a promise is possessed by the Tree, any > player except the promise's author CAN transfer it to emself by > announcement, if e cashes the promise in the same message in > which e transfers it to emself." > > This is a classic retroactive conditional, to wit, the success > of the first action (the transfer) is conditional on the success > of the necessarily later action. > > Basically, Wes CAN transfer it to emself if e CAN cash it, which > e CAN when e transfers it to emself, but then e CANNOT, so e > doesn't transfer it to emself, upon which e CAN... etc. > > This differs from a couple of previous precedents: > 1. This does not deal with the ownership, but rather the ability > to cash, so this doesn't end up in the LF&D. > 2. This part of R2338 does not apply: > If cashing a promise would lead, through its own actions or > actions directly caused by its cashing, to a value being > indeterminate an instant after the promise is cashed, then > (other provisions of this or other rules notwithstanding) it > CANNOT be cashed. > as we're not talking about outright ability to cash (which is > possible at the outset here), but rather the ability to transfer > which leads up to cashing. > > -G. > > > > > > > > > >
