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. ==========================================================================