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

Reply via email to