status: https://faculty.washington.edu/kerim/nomic/cases/#3875
(This document is informational only and contains no game actions).
=============================== CFJ 3875 ===============================
Somewhat Annoying Experiment has exactly 5 coins.
==========================================================================
Caller: Gaelan
Judge: G.
Judgement: FALSE
==========================================================================
History:
Called by Gaelan: 14 Aug 2020 06:17:58
Assigned to G.: 14 Aug 2020 18:35:40
Judged FALSE by G.: 21 Aug 2020 18:32:23
==========================================================================
Caller's Evidence:
On 8/14/2020 03:15 UTC, Gaelan Steele via agora-business wrote:
> I transfer 10 coins to the above contract.
On 8/14/2020 06:17 UTC, Gaelan Steele via agora-business wrote:
> I revoke 5 coins in that contract's possession by announcement.
Contract at time of the revokation announcement, from Notary's Report:
"Somewhat Annoying Experiment" (revision 1)
Parties: Gaelan
----------
The Eligible Revocation can be calculated as follows:
Let x be the lowest positive integer that, represented as a decimal
number in ASCII, has the SHA256 hash
9b722e5d98390e12c7f29dc74d30a52f2c152a35fd47f9614e35f235e025b085.
The Eligible Revocation is x % 10 (where % is the modulo operator).
This contract accepts any transfers of assets.
A party to this contract can, by announcement, revoke a number of coins
in its possession exactly equal to the Eligible Revocation.
Gaelan can, by announcement, transfer assets owned by this contract to
emself.
----------
Caller's Arguments:
Note: The SHA256 hash above is a random 64-bit value. While I believe
there must exist a lowest number with that hash (there is an infinite
number of integers, but a finite number of possible SHA256 hashes), I
don't believe it can be determined other than by brute force. This
follows from a discussion in the Discord about whether or not we have
any limits on computational complexity of contracts.
--------------------------------------------------------------------------
Gratuitous Arguments by shelvacu:
Argument for FALSE:
Rule 1742 says that
"The portion of a contract's provisions that can be interpreted with
reference only to information that is either publicly or generally
available are known as its body; the remainder of the provisions are
known as the annex."
and
"A party to a contract CAN perform any of the following actions as
explicitly and unambiguously permitted by the contract's *body*."
Because the integer x specified in the contract is information that is
not publicly or generally available, all portions that depend on it are
an "annex". Thus, revoking 5 coins was not effective because no part of
the contract's body allowed it.
While the contract states that "The Eligible Revocation can be
calculated as follows", that is simply not true. What is provided is a
way to /verify/ the Eligible Revocation. While theoretically 'x' could
be found via brute force has exactly one correct value, the process of
finding that integer would require resources that are certainly not
publicly or generally available.
Side note: I was going to add "... and does not exist on this earth" in
reference to what resources would be required, but I remembered that
bitcoin exists, and because of it so do large amounts of heavily
optimized ASICs that compute SHA256. I decided to do the calculation to
check. https://www.blockchain.com/charts/hash-rate shows the average
hashrate of the bitcoin network peaked at 126.941 petahashes/s (that's
right, /peta-/). At that rate (that is, if everyone in the world
currently running a bitcoin miner instead switched to finding Gaelan's
number), it would take */145 seconds! /*That's it!
Side note to my side note: I misunderstood Gaelan's note. The hash
itself is completely random, I misread and though it was a hash /of/ a
value between 0 and 2^64-1 (a 64-bit value). As such, brute forcing with
all the world's ASICs would be on the order of 10^60 seconds, or 10^50
centuries.
--------------------------------------------------------------------------
Judge G.'s Arguments:
This judgement applies whenever the rules explicitly grant legal status to
an outside (non-rules) document. For example, it applies when a contract
"permits" something (R1742), when a person "specifies" something in a
by-announement action message (R478), when a non-rules backing document
"specifies" how an asset works (R2166), when a regulation "defines" an
auction method (R2545), when a promise "specifies" conditions for cashing
(R2618), when an ephemeral instrument "specifies" changes that are applied
(R2613), etc. [0]
The important commonality is that, since these are non-rules documents,
they don't fall under R217's "text of the rules takes precedence" clause.
For rules, if there is an ambiguity in the text, that ambiguity still
"takes precedence" and may lead to legally indeterminate or paradoxical
situations if the rules text is unclear. Non-rules texts, on the other
hand, function where the rules are silent. So interpretations fall under
R217 common-sense, etc. (speaking generally, not as a strict fourfold
test). For these texts, if a specification (or permission or definition)
is ambiguous, it generally fails.
Further, we have a long history of allowing conditionals and references
within such documents to be part of the specification (without citing
caselaw, allowing such conditionals is game custom, good common sense,
established in precedent, and generally in the best interests of smooth
running of the game). Such conditionals may depend on outside
information, and in fact usually do (or they wouldn't be conditional on
anything). A simple example is a contract that depends on a certain time
passing to trigger - contracts don't have internal clocks, so the current
time is outside information and not "part of the body" of the contract.
But common sense holds that the current time is easily available
information, so such conditionals generally work. Overall, if there's a
conditional in the body of a contract, then outside information referred
to in a contract's body is in a third document, that's generally
acceptable to count as "as permitted by the contract's body".
However, part of that common sense interpretation is that conditionals
that rely on unclear, paradoxical, or intractable outside information
generally cause the specification to fail, even if the description of the
conditional within the contract is clear. CFJ 1460 has long-been the
guiding precedent here - interpreting such conditionals can't require
"unreasonable effort". Examples of "unreasonable effort" in CFJ 1460 are
precisely applicable here, as they include reliance on knowledge that's
theoretically deterministic and computable but practically impossible to
obtain in a reasonable time frame.
The information required in the current contract clearly fits in that
"really unreasonable" category. So this Court finds FALSE. Leaving it
there, it would be tempting for an Agoran to say "well, that's clearly a
computational infeasible outlier, what about something that takes a day to
code and a week to run?" So to refine this, to balance the workload of
officers who may have to process many transactions with the Agoran "fun"
of making somewhat-complex conditionals, this Court strongly suggests that
"reasonable effort" is limited to what can be known or found out with
fairly minimal effort for the typical informed Agoran - e.g. a few minutes
of looking up a contract and/or referencing some outside information,
perhaps an email or two asking the community for help, with a time delay
no greater than if an officer asks for help at the beginning of processing
eir weekly duties, e can reasonably expect an answer before e finishes eir
duties (i.e. if a contract requires something that takes a week to code,
the parties to the contract have made those calculations already and can
provide results within the scope of an hour or so).
[0] For non-rules texts, a term like "unambiguously specify" is generally
a tautology; i.e., if such a text "specifies" something, it must do so
unambiguously, or it's not a specification (though such adjectives may
influence the tolerance for error in specific situations). So this
judgement doesn't rely on the presence of "clear" or "unambiguous" etc. in
the rules text.
==========================================================================
