On Thu, Nov 7, 2019 at 3:28 PM Jason Cobb <jason.e.c...@gmail.com> wrote: > > On 11/7/19 6:20 PM, Kerim Aydin wrote: > > I was working on a Contract fix back in Sept that I have some > > half-finished language for. It: > > > > - Defines public contracts, and requires contracts to be public in > > order to hold currency or authorize act-on-behalfs or ENABLE anything > > else at all. Was undecided on whether the Notary should be brought > > back to track these. > > > > - Creates private contracts (I called them "deals" in the draft). > > Private contracts don't ENABLE any new abilities, they just say things > > like "Person X will do A and Person Y will do B". Their use is that > > if one party fails to hold up their bargain, it's a crime and the > > other party can seek penalties. > > > > Dunno how exactly this interacts with trades and promises, but if > > we're re-thinking the system we should*definitely* fix the > > public/private issue in contracts too. > > > > -G. > > > Oh, I just remembered a potential issue I saw with the current contracts > a while back. Right now, I don't think it's possible for a contract to > create a requirement that won't be punished as a Class 2 Crime, since > the current enforcement is a simple "SHALL". > > I don't know if that's really an issue or if it would be complicated to > fix, but I just wanted to mention it.
ARIS'S MASTER OBLIGATION PLAN (Each list in this plan uses a different numbering/lettering convention for clarity of reference; sorry if that offends anyone.) Plan for solving the problems mentioned in the thread and making the changes I've proposed (each step is probably a different proposal, to stop excessively complex and hard to review changes from happening at once): 1. Contract patency. A pact is made the same way a contract is made now, but has only the powers suggested by G. To become a contract, a pact is made patent. This can by done with the consent of the parties by publishing the full list of parties and the text. If the pact is made in public, the intent of the parties to make it patent is presumed. A contract (that is, a patent pact) CANNOT have a change to its party list or text that isn't made in public. 2. Covenant introduction. Covenants are a class of entity that have a set of persons who are privy to the covenant and a subset of that set who the covenant is binding upon. A covenant cannot become binding upon a person without their consent. A covenant's properties can generally be changed either i) with the consent of everyone who is privy to that covenant; or ii) without objection. A pact is a covenant, privy to and binding upon its parties. A pledge is a covenant, binding upon its creator and privy to all players. This would probably be a good time to introduce Jason Cobb's crime level changes, since they likely apply to all covenants. This could be done by moving the special case text for pledges to apply to all covenants, in an excellent example of the DRY benefits of a consolidated architecture. 3. Promise introduction. A promise behaves roughly as it did in 2013. A promise is a covenant which is privy to its creator and its owner and becomes binding upon its creator at the time it is cashed. Steps I'm not sure when to do, and which could potentially be merged with any of the above: a) Introduce the Notary to track whichever then exist of contracts, pledges, and promises. b) Revise the general definition of consent. Persons consent to i) whatever they consent to under the current rules; ii) whatever a contract (should this be "public covenant" where that's defined as contract, pledge, or promise?) they are bound by to says they consent to. Contracts consent to whatever their text says they consent to. c) Introduce trades, which depend on b if they're going to work on contracts (because I plan to allow trades by consent). Potential objections: A) Covenants are too complicated. Answer: This is... actually a very fair objection. Generality always means a more complex system. On the other hand, this unifies a bunch of existing systems that have many things in common. Nothing else actually depends on introducing covenants. I like the idea of getting rid of redundancies, and I think it could be done in a way that isn't too complicated. However, it's possible others will disagree. B) Promises can be implemented by contract. Adding them will make the ruleset too complicated. Answer: Firstly, I want the Notary to track them, which means they need to be rule defined. Secondly, having them be defined will make their adoption harder (since it would probably require every message using them to link to the definition, at least initially). Thirdly, it's only ~two rules; maybe I can get it down to one. Fourthly: **They sound so darned fun!8* Like, seriously, there are obvious implementations for both futures and options on top of these. I might even write those out in the proposal somewhere. The added complexity is worth the fun uses when they are used, in my very strong but still humble opinion. Thoughts? -Aris