public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Ryan Grant <bitcoin-dev@rgrant.org>
To: "Russell O'Connor" <roconnor@blockstream.io>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Implementing Covenants with OP_CHECKSIGFROMSTACKVERIFY
Date: Thu, 3 Nov 2016 13:42:22 -0400	[thread overview]
Message-ID: <CAMnpzfork1m1-mnC8ZdJM43opCyxKwMpthEsXDWb5Q+PskDryA@mail.gmail.com> (raw)
In-Reply-To: <CAMZUoKkG0AqwsTE=opTcsD=xqWsoVxqPVCzFbcSz8zJT1wiFPg@mail.gmail.com>

On Wed, Nov 2, 2016 at 1:30 PM, Russell O'Connor via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> I'm interested in collecting and implementing other useful covenants, so if
> people have ideas, please post them.

I know of a good business case that could benefit from two nice
features.

As an example:

  Two parties have initiated a transaction designed with
  counterparty-minimization in mind.  It uses MAST and has many
  different payout distributions.  Both parties enter expecting to
  gain from the transaction, but both take on risk due to external
  factors.

  Because of the risks involved, there exist possible times when one
  party may wish to renegotiate the exit distribution, and might
  threaten to block any exit.  Or, either party might get hit by the
  proverbial bus.  During such times, the other party's eventual exit
  is protected by using a multisig which includes an oracle
  determination.  The oracle's trusted role is bound to this example's
  unstated "external factors" in a very limited sense, and does not
  include broader concerns, such as determining whether a party to the
  transaction is of "sound mind and body".

  The singular term "oracle" hides a set of entities participating in
  m-of-n multisig, which we can name the "oracle-set".

  Transaction terms include a CLTV lasting perhaps several years,
  applied whenever the exit requires the oracle-set's signatures.

  Both parties may mutually select and sign one of the payout
  distributions, to exit early.

The example, as I've described it so far, doesn't need anything other
than MAST.  It isn't a covenant, because it doesn't impose any forward
restrictions when satisfied; despite the contractual complications of
executing the oracle-set's signatures.  As covenant features are
considered across updated instances of what is otherwise a singular
transaction, it's important that none carry into the final payout
distribution, and that this is easy to verify.

Features desired:

  - One party would like to unilaterally sell their participation in
    the transaction, to a previously unknown recipient, before the
    CLTV becomes valid.

    The other originating party's stored MAST should either continue
    to function, or require minimal replacements that can be
    deterministically applied using data visible on the blockchain.
    It should not be necessary to ask permission from - or coordinate
    online communication with - the other originating party.

    (This can also be viewed as a key rotation problem for any
    long-lasting multisig transaction.)

  - Both parties would like to mutually revoke rouge oracle-entities
    from the oracle-set, without exposing each other to any possible
    renegotiation of other terms.

Note that these features affect each other, since if one party sells
their participation after any oracle-entities have been revoked, then
the revocations should not reset, but rather remain in effect, until a
proper payout executes the final agreement in the contract.

Of course, if there's a way to achieve these features with less risk
than evaluating covenant logic, I would very much like to hear how to
do so.


      parent reply	other threads:[~2016-11-03 17:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-02 17:30 [bitcoin-dev] Implementing Covenants with OP_CHECKSIGFROMSTACKVERIFY Russell O'Connor
2016-11-03  3:35 ` Johnson Lau
     [not found] ` <E8BB95A5-09B3-443C-B197-29DA3C4767D8@xbt.hk>
2016-11-03  4:19   ` Russell O'Connor
2016-11-03  7:37     ` Daniel Robinson
2016-11-03 20:02       ` Russell O'Connor
2016-11-04 14:35       ` Tim Ruffing
2016-11-07 19:30         ` Jeremy
2016-11-03 17:42 ` Ryan Grant [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMnpzfork1m1-mnC8ZdJM43opCyxKwMpthEsXDWb5Q+PskDryA@mail.gmail.com \
    --to=bitcoin-dev@rgrant.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=roconnor@blockstream.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox